From: Al Viro <viro@ZenIV.linux.org.uk>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: "<linux-fsdevel@vger.kernel.org>" <linux-fsdevel@vger.kernel.org>,
Trond Myklebust <trondmy@primarydata.com>,
List Linux NFS Mailing <linux-nfs@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: Revalidate failure leads to unmount
Date: Tue, 6 Dec 2016 06:17:47 +0000 [thread overview]
Message-ID: <20161206061747.GN1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <D061B89E-EFC7-49F8-86C0-C60FDF269D3C@linuxhacker.ru>
On Tue, Dec 06, 2016 at 12:45:11AM -0500, Oleg Drokin wrote:
> Well, certainly if d_splice_alias was working like that so that even non-directory
> dentry would find an alias (not necessarily unhashed even) for that same inode and use that instead, that would make ll_splice_alias/ll_find_alias unnecessary.
>
> We still retain the weird d_compare() that rejects otherwise perfectly valid aliases
> if the lock guarding them is gone, triggering relookup (and necessiating the
> above logic to pick up just rejected alias again now that we have the lock again).
Why not have ->d_revalidate() kick them, instead? _IF_ we have a way to
do unhash-and-trigger-lookup that way, do you really need those games with
->d_compare()?
next prev parent reply other threads:[~2016-12-06 6:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-05 16:45 Mountpoints disappearing from namespace unexpectedly Oleg Drokin
2016-09-20 1:44 ` Revalidate failure leads to unmount (was: Mountpoints disappearing from namespace unexpectedly.) Oleg Drokin
2016-12-06 1:39 ` Revalidate failure leads to unmount Oleg Drokin
2016-12-06 2:00 ` Al Viro
2016-12-06 2:03 ` Al Viro
2016-12-06 2:22 ` Oleg Drokin
2016-12-06 5:02 ` Al Viro
2016-12-06 5:45 ` Oleg Drokin
2016-12-06 6:17 ` Al Viro [this message]
2016-12-06 6:46 ` Oleg Drokin
2016-12-08 5:01 ` Oleg Drokin
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=20161206061747.GN1555@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ebiederm@xmission.com \
--cc=green@linuxhacker.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@primarydata.com \
/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.