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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
