From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH] vfs: Fix possible NULL pointer dereference in inode_permission() Date: Thu, 9 Jan 2014 22:31:27 +0000 Message-ID: <20140109223127.GM10323@ZenIV.linux.org.uk> References: <20140109162731.12500986@gandalf.local.home> <20140109214239.GD29910@parisc-linux.org> <20140109165012.391db81e@gandalf.local.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthew Wilcox , LKML , linux-fsdevel@vger.kernel.org, Stephen Smalley , Christoph Hellwig , Linus Torvalds , Eric Paris , Theodore Ts'o , Dave Chinner , James Morris , Paul Moore , Andrew Morton , "Paul E. McKenney" , stable To: Steven Rostedt Return-path: Content-Disposition: inline In-Reply-To: <20140109165012.391db81e@gandalf.local.home> Sender: stable-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 09, 2014 at 04:50:12PM -0500, Steven Rostedt wrote: > > We'd then have to get rid of all the call_rcu() invocations in individual > > filesystems' destroy_inode methods, but that doesn't sound like a bad > > thing to me. Check what e.g. XFS is doing... > Which is another reason that I didn't do it, as I didn't know all the > happenings inside the ->destroy_inode() calls. But yeah, I agree with > this. > > Also, can iput() sleep? If not then we are OK. Otherwise, we need to be > careful about any mutex being grabbed in those call backs, as the > rcu_callback can't sleep either. iput() definitely can sleep (that's when actual truncation and inode freeing is done for opened-and-unlinked files - on the final iput() after close()), but that' irrelevant here - fsnotify_delete_inode() grabs a bunch of mutexes, which makes calling it from rcu callback no-go.