[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130322060953.GN21522@ZenIV.linux.org.uk>
Date: Fri, 22 Mar 2013 06:09:53 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [CFT] Re: VFS deadlock ?
On Thu, Mar 21, 2013 at 10:33:27PM -0700, Linus Torvalds wrote:
> Ok, that's kind of ugly, but shouldn't be a correctness issue. It
> should still work - just cycle through inodes quite aggressivelydue to
> no longer re-using them - so I suspect Dave could test it (with the
> extra line removed I pointed out just a moment ago).
>
> And I wonder how big of a deal the aggressive dentry deletion is.
> Maybe it's even ok to allocate/free the inodes all the time. The whole
> "get the inode hash lock and look it up there" can't be all that
> wonderful either. It takes the inode->i_lock for each entry it finds
> on the hash list, which looks horrible. I suspect our slab allocator
> isn't much worse than that, although the RCU freeing of the inodes
> could end up being problematic.
Hell knows... At the very least, I'd expect /proc/self to be fairly hot.
During the boot time - /proc/mounts, /proc/filesystems, /proc/cmdline...
Dunno. Would be interesting to slap a printk into proc_lookup_de() and
see how much (and what) does it hit on a busy system...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists