All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nick Piggin <npiggin@kernel.dk>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: fix race in rcu lookup of pruned dentry
Date: Mon, 18 Jul 2011 00:16:10 +0100	[thread overview]
Message-ID: <20110717231610.GR11013@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFw5LhGq-a6mAhgZbGP2FJ+tnV9HRxKoiFuVYbttOo2tNw@mail.gmail.com>

On Sun, Jul 17, 2011 at 03:00:06PM -0700, Linus Torvalds wrote:

> Yes. However, looking at it, I'm not very happy with your patch. It
> doesn't really make sense to me to special-case the NULL inode and
> only do a seq_retry for that case.
> 
> I kind of see why you do it for that particular bug, but at the same
> time, it just makes me go "Eww". If that inode isn't NULL yet, you
> then return the dentry that can get a NULL d_inode later. So the only
> special thing there is that we happen to check for a NULL inode there.
> What protects *later* checks for a NULL d_inode?
> 
> So my gut feel is that we should instead
> 
>  - either remove the -ENOENT return at that point entirely, and move
> it to after we have re-verified the dentry lookup for other reasons.
> That looks pretty involved, though, and those paths do end up
> accessing inode data structures etc, so it looks less than trivial.
> 
> OR
> 
>  - simply just not clear d_inode at all in d_kill(), so that when we
> prune a dentry due to memory pressure, it doesn't actually change the
> state of the dentry.

OR

 - keep part of the patch from Hugh, treating negative in RCU mode as
"need to unlazy".  Leaving everything else as-is.  Normally we'll
confirm that sucker is negative and that'll be it.  Or we'll see that
it's being evicted and fall back to non-lazy mode, which is what we'll
need to do anyway.  IOW, this:

diff --git a/fs/namei.c b/fs/namei.c
index 5c867dd..48a38de 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1171,6 +1171,8 @@ static int do_lookup(struct nameidata *nd, struct qstr *name,
 		path->dentry = dentry;
 		if (unlikely(!__follow_mount_rcu(nd, path, inode)))
 			goto unlazy;
+		if (unlikely(!*inode))
+			goto unlazy;
 		if (unlikely(path->dentry->d_flags & DCACHE_NEED_AUTOMOUNT))
 			goto unlazy;
 		return 0;

  parent reply	other threads:[~2011-07-17 23:16 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-17 21:03 [PATCH] vfs: fix race in rcu lookup of pruned dentry Hugh Dickins
2011-07-17 22:00 ` Linus Torvalds
2011-07-17 22:59   ` Linus Torvalds
2011-07-17 23:26     ` Al Viro
2011-07-17 23:16   ` Al Viro [this message]
2011-07-17 23:38     ` Linus Torvalds
2011-07-17 23:47       ` Hugh Dickins
2011-07-18  0:25         ` Al Viro
2011-07-18  1:13           ` Hugh Dickins
2011-07-18  2:08             ` Al Viro
2011-07-18  6:31               ` Linus Torvalds
2011-07-18  6:31                 ` Linus Torvalds
2011-07-18 14:41                 ` Hugh Dickins
2011-07-18 18:11                 ` Linus Torvalds
2011-07-18 18:20                   ` Al Viro
2011-07-18 19:08                     ` Linus Torvalds
2011-07-18 19:20                       ` Al Viro
2011-07-18 19:23                         ` Al Viro
2011-07-18 19:34                         ` Linus Torvalds
2011-07-18 19:04                   ` Hugh Dickins
2011-07-18 19:33                     ` Linus Torvalds
2011-07-18 19:47                       ` Al Viro
2011-07-18 20:24                         ` Linus Torvalds
2011-07-18 21:19                           ` Hugh Dickins
2011-07-18 21:42                             ` Linus Torvalds
2011-07-18 22:43                               ` Hugh Dickins
2011-07-18 23:17                                 ` Al Viro
2011-07-18 23:21                                   ` Al Viro
2011-07-18 23:27                                     ` Linus Torvalds
2011-07-18 23:40                                       ` Al Viro
2011-07-19  2:07                                         ` Hugh Dickins
2011-07-19  2:14                                           ` Linus Torvalds
2011-07-19  2:14                                             ` Linus Torvalds
2011-07-19  2:17                                             ` Linus Torvalds
2011-07-19  2:23                                               ` Al Viro
2011-07-19  2:37                                                 ` Chris Ball
2011-07-19  4:41                                                 ` Nicolas Pitre
2011-07-19  2:21                                           ` Al Viro
2011-07-19 23:45                               ` Al Viro
2011-07-19 23:52                                 ` Al Viro
2011-07-19 23:55                                   ` Al Viro
2011-07-20  0:47                                     ` NeilBrown
2011-07-20  1:40                                       ` Al Viro
2011-07-20  4:52                                         ` Linus Torvalds
2011-07-20  4:52                                           ` Linus Torvalds
2011-07-19 23:56                                 ` Linus Torvalds
2011-07-20  0:04                                   ` Al Viro
2011-07-17 23:53       ` Al Viro
2011-07-17 23:31   ` Hugh Dickins
2011-07-17 23:52     ` 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=20110717231610.GR11013@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@kernel.dk \
    --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.