From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [CFT] Re: VFS deadlock ?
Date: Fri, 22 Mar 2013 06:09:53 +0000 [thread overview]
Message-ID: <20130322060953.GN21522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFzbV81KQh_f0=wti9=_6=PXu37z0+NJymhDvzv13GgpuA@mail.gmail.com>
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...
next prev parent reply other threads:[~2013-03-22 6:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 19:06 VFS deadlock ? Dave Jones
2013-03-21 19:21 ` Al Viro
2013-03-21 20:31 ` Dave Jones
2013-03-21 19:29 ` Al Viro
2013-03-21 20:15 ` Linus Torvalds
2013-03-21 20:26 ` Dave Jones
2013-03-21 20:32 ` Linus Torvalds
2013-03-21 20:36 ` Dave Jones
2013-03-21 20:47 ` Al Viro
2013-03-21 21:02 ` Dave Jones
2013-03-21 21:18 ` Linus Torvalds
2013-03-21 21:26 ` Al Viro
2013-03-21 21:41 ` Dave Jones
2013-03-21 21:47 ` Linus Torvalds
2013-03-21 21:55 ` Al Viro
2013-03-21 21:57 ` Linus Torvalds
2013-03-21 22:03 ` Al Viro
2013-03-21 21:52 ` Al Viro
2013-03-21 22:12 ` Dave Jones
2013-03-21 22:29 ` Dave Jones
2013-03-21 22:53 ` Linus Torvalds
2013-03-21 23:07 ` Dave Jones
2013-03-21 23:36 ` Al Viro
2013-03-21 23:58 ` Linus Torvalds
2013-03-22 0:01 ` Linus Torvalds
2013-03-22 0:12 ` Al Viro
2013-03-22 0:20 ` Al Viro
2013-03-22 0:22 ` Linus Torvalds
2013-03-22 1:22 ` Al Viro
2013-03-22 1:33 ` Linus Torvalds
2013-03-22 1:40 ` Al Viro
2013-03-22 4:37 ` [CFT] " Al Viro
2013-03-22 4:55 ` Linus Torvalds
2013-03-22 5:18 ` Al Viro
2013-03-22 5:33 ` Linus Torvalds
2013-03-22 6:09 ` Al Viro [this message]
2013-03-22 6:22 ` Al Viro
2013-03-22 16:23 ` Dave Jones
2013-03-22 19:43 ` Linus Torvalds
2013-03-22 21:28 ` Al Viro
2013-03-22 22:57 ` Eric W. Biederman
2013-03-22 5:19 ` Linus Torvalds
2013-03-22 0:08 ` Al Viro
2013-03-22 0:15 ` Linus Torvalds
2013-03-22 0:19 ` Linus Torvalds
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=20130322060953.GN21522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=davej@redhat.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--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.