From: Ian Kent <raven@themaw.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
David Howells <dhowells@redhat.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
npiggin@gmail.com
Subject: Re: [PATCH 0/3] Fixes for vfs-scale and vfs-automount
Date: Thu, 24 Feb 2011 14:34:20 +0800 [thread overview]
Message-ID: <1298529260.2916.91.camel@perseus> (raw)
In-Reply-To: <20110224035836.GS22723@ZenIV.linux.org.uk>
On Thu, 2011-02-24 at 03:58 +0000, Al Viro wrote:
>
> Anyway, I wonder why you care about __d_lookup_rcu() and ->d_inode stability;
> d_mountpoint() _is_ stable at that point (we hold vfsmount_lock) and you
> don't seem to look at ->d_inode at all in RCU case. Note that ->d_automount()
> is never called in RCU case at all; nor is ->lookup() and friends, so you
> really only have ->d_manage() to cope with, what with autofs4 having no
> ->d_revalidate() anymore.
It does now but it doesn't do a whole lot, just checks for a negative
dentry, returning false, and drops out of RCU mode when the dentry isn't
selected or being checked for expiry yet.
Indeed, I shouldn't need to care about it and checking for it doesn't
seem to do a whole lot.
I've seen walks fail with a dentry that has gone away (ie. I'm walking
in a tree that is being expired, they seem to be trees with no actual
mount at their base), which should be because I'm not catching the block
request at a higher level dentry. Unfortunately, including a check for
the base dentry in __follow_mount_rcu(), regardless of it being a
mountpoint, doesn't always catch the need to block either. That the tree
is being selected for expire is probably because the expire can't detect
a walk within the mount tree when the walker is between the
__d_lookup_rcu() and __follow_mount_rcu() calls. Jumping out of rcu-walk
mode in an added revalidate reduces the possibility of this happening
(assuming walks are sneaking in between dropping and acquiring the
vfsmount_lock) but doesn't eliminate it.
At this point I loop back to the trying to work out why a reference gets
picked up and the cycle repeats with various small changes to the
overall approach.
Actually, it's not just the root of a mount that is getting an extra
reference either. When I notice a root dentry has picked up a reference
(from a printk) and SIGKILL everything and start umounting manually I
get to a point in the tree where I need to umount autofs mounts twice,
which usually means nothing more than a get/put mismatch somewhere, but
in that case I normally don't see a root dentry pick up a reference.
That's confusing me too.
>
> BTW, Nick has moved to kernel.dk; whether he's still reachable there is
> a question, though - he seems to have disappeared since mid-January.
Yeah, I've forwarded a couple of messages where I forgot to change the
email. A few emails back Nick said he was following the thread anyway.
Ian
WARNING: multiple messages have this Message-ID (diff)
From: Ian Kent <raven-PKsaG3nR2I+sTnJN9+BGXg@public.gmane.org>
To: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Cc: Trond Myklebust
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>,
David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-fsdevel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Linux NFS Mailing List
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH 0/3] Fixes for vfs-scale and vfs-automount
Date: Thu, 24 Feb 2011 14:34:20 +0800 [thread overview]
Message-ID: <1298529260.2916.91.camel@perseus> (raw)
In-Reply-To: <20110224035836.GS22723-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Thu, 2011-02-24 at 03:58 +0000, Al Viro wrote:
>
> Anyway, I wonder why you care about __d_lookup_rcu() and ->d_inode stability;
> d_mountpoint() _is_ stable at that point (we hold vfsmount_lock) and you
> don't seem to look at ->d_inode at all in RCU case. Note that ->d_automount()
> is never called in RCU case at all; nor is ->lookup() and friends, so you
> really only have ->d_manage() to cope with, what with autofs4 having no
> ->d_revalidate() anymore.
It does now but it doesn't do a whole lot, just checks for a negative
dentry, returning false, and drops out of RCU mode when the dentry isn't
selected or being checked for expiry yet.
Indeed, I shouldn't need to care about it and checking for it doesn't
seem to do a whole lot.
I've seen walks fail with a dentry that has gone away (ie. I'm walking
in a tree that is being expired, they seem to be trees with no actual
mount at their base), which should be because I'm not catching the block
request at a higher level dentry. Unfortunately, including a check for
the base dentry in __follow_mount_rcu(), regardless of it being a
mountpoint, doesn't always catch the need to block either. That the tree
is being selected for expire is probably because the expire can't detect
a walk within the mount tree when the walker is between the
__d_lookup_rcu() and __follow_mount_rcu() calls. Jumping out of rcu-walk
mode in an added revalidate reduces the possibility of this happening
(assuming walks are sneaking in between dropping and acquiring the
vfsmount_lock) but doesn't eliminate it.
At this point I loop back to the trying to work out why a reference gets
picked up and the cycle repeats with various small changes to the
overall approach.
Actually, it's not just the root of a mount that is getting an extra
reference either. When I notice a root dentry has picked up a reference
(from a printk) and SIGKILL everything and start umounting manually I
get to a point in the tree where I need to umount autofs mounts twice,
which usually means nothing more than a get/put mismatch somewhere, but
in that case I normally don't see a root dentry pick up a reference.
That's confusing me too.
>
> BTW, Nick has moved to kernel.dk; whether he's still reachable there is
> a question, though - he seems to have disappeared since mid-January.
Yeah, I've forwarded a couple of messages where I forgot to change the
email. A few emails back Nick said he was following the thread anyway.
Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-02-24 6:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-18 4:05 [PATCH 0/3] Fixes for vfs-scale and vfs-automount Ian Kent
2011-01-18 4:06 ` [PATCH 1/3] autofs4 - fix get_next_positive_dentry() Ian Kent
2011-01-18 4:06 ` [PATCH 2/3] vfs - fix dentry ref count in do_lookup() Ian Kent
2011-01-18 4:44 ` Al Viro
2011-01-18 4:06 ` [PATCH 3/3] autofs4 - fix debug print in autofs4_lookup() Ian Kent
2011-01-19 7:06 ` [PATCH 0/3] Fixes for vfs-scale and vfs-automount Ian Kent
2011-02-15 14:25 ` Ian Kent
2011-02-23 7:22 ` Ian Kent
2011-02-23 16:37 ` Linus Torvalds
2011-02-24 1:58 ` Al Viro
2011-02-24 3:03 ` Ian Kent
2011-02-24 3:14 ` Al Viro
2011-02-24 3:28 ` Ian Kent
2011-02-24 3:28 ` Ian Kent
2011-02-24 3:58 ` Al Viro
2011-02-24 5:47 ` Al Viro
2011-02-24 7:23 ` Ian Kent
2011-02-24 6:34 ` Ian Kent [this message]
2011-02-24 6:34 ` Ian Kent
2011-02-24 7:07 ` Al Viro
2011-02-24 10:07 ` Ian Kent
2011-02-24 10:07 ` Ian Kent
2011-02-24 14:59 ` Al Viro
2011-02-24 15:18 ` Al Viro
2011-02-25 3:07 ` Ian Kent
2011-02-24 19:10 ` Al Viro
2011-02-24 19:10 ` Al Viro
2011-02-24 10:21 ` Ian Kent
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=1298529260.2916.91.camel@perseus \
--to=raven@themaw.net \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.