From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
mgorman@suse.de, gregkh@suse.de, akpm@linux-foundation.org
Subject: Re: [RFC PATCH] shrink_dcache_parent() deadlock
Date: Mon, 9 Jan 2012 21:26:55 +0000 [thread overview]
Message-ID: <20120109212654.GY23916@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120109205907.GE4198@dastard>
On Tue, Jan 10, 2012 at 07:59:07AM +1100, Dave Chinner wrote:
> > Comments?
>
> Looks OK to me.
OK, grabbed. And there's *more* fixes for obvious shite - by now I'm
really sick and tired of what people are doing with failure exits;
this morning catch just from looking through d_alloc_root() callers:
isofs - inode leak
ext4 - dentry leak + completely bogus handling of ext4_mb_init()
failure (stuff that hadn't been allocated gets freed, stuff that was
allocated isn't)
ceph - d_alloc_root() can fail. NULL pointer derefs galore...
)
Frankly, d_alloc_root() had been a bad API; it should've been doing
iput() on allocation failure. I've added a trivial helper in the
local tree (d_make_root(inode) - same as d_alloc_root(inode) and do
iput(inode) if result turns out to be NULL). Looks like *all* callers
of d_alloc_root() either turn out to be buggy or trivially convert to
d_make_root(). With a lot of boilerplate crap removed...
Hell knows... Originally I thought about leaving both side-by-side, but
it really starts looking as if there's no reason to keep d_alloc_root()
at all... I still have a couple of callers to check, though.
next prev parent reply other threads:[~2012-01-09 21:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 10:58 [RFC PATCH] shrink_dcache_parent() deadlock Miklos Szeredi
2012-01-09 16:43 ` Linus Torvalds
2012-01-09 17:05 ` Miklos Szeredi
2012-01-09 17:05 ` Miklos Szeredi
2012-01-09 17:16 ` Greg KH
2012-01-09 17:16 ` Greg KH
2012-01-09 17:16 ` Christoph Hellwig
2012-01-09 17:30 ` Al Viro
2012-01-09 18:30 ` Linus Torvalds
2012-01-09 18:46 ` Linus Torvalds
2012-01-09 19:04 ` Christoph Hellwig
2012-01-09 19:18 ` Linus Torvalds
2012-01-09 20:59 ` Dave Chinner
2012-01-09 21:21 ` Linus Torvalds
2012-01-10 1:34 ` Al Viro
2012-01-10 2:02 ` Linus Torvalds
2012-01-10 10:05 ` Miklos Szeredi
2012-01-10 16:00 ` Linus Torvalds
2012-01-10 16:15 ` Al Viro
2012-01-10 16:22 ` Miklos Szeredi
2012-01-10 16:22 ` Miklos Szeredi
2012-01-10 16:33 ` Linus Torvalds
2012-01-10 16:50 ` Miklos Szeredi
2012-01-10 18:04 ` Al Viro
2012-01-10 21:52 ` Dave Chinner
2012-01-10 21:52 ` Dave Chinner
2012-01-09 21:26 ` Al Viro [this message]
2012-01-09 17:27 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120109212654.GY23916@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=gregkh@suse.de \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=miklos@szeredi.hu \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.