On Fri, Oct 04, 2013 at 01:49:13PM -0700, Linus Torvalds wrote: > That would get ugly. > > However, I don't think we actually really need to do that. We had a > similar situation with d_revalidate() passing inode pointers etc > totally unnecessarily. Yes, the filesystem needs to use ACCESS_ONCE() > and care about NULL, but it doesn't need anything more than that. And > we really do have that already.
Not for ->getattr()... BTW, ->permission() for btrfs in that series relies on not getting a MAY_WRITE | MAY_NOT_BLOCK combination, and if you are serious about access(2), we'll need to lazy-delay freeing struct btrfs_root. Besides, we'll need to audit all ->permission() instances for places that do not check for MAY_NOT_BLOCK on such branches... > And we already have dentry->d_sb - which is supposed to be valid. > Again, we already use it under RCU for d_revalidate() and for name > hashing. So the super-block had better already be ok with RCU. Umm... Right you are, so we really need to make freeing these suckers delayed. Fixed and pushed. BTW, I wonder how much does removal of s_files (next-to-last commit in #experimental) affect scalability on open/close... Anybody with perf setup and reasonable amount of previous data? BTW^2: what's the FM2R for perf testing of that kind? E.g. how much is testable under KVM, etc.? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
