[OpenAFS-devel] afs_linux_dentry_revalidate and d_drop

[Marc Dionne]

On Thu, Mar 13, 2014 at 6:40 PM, Andrew Deason <adeason@sinenomine.net> wrote:
> While testing some of the "linux mountpoint" stuff, I've found some
> concerning behavior that seems to be caused by gerrit 10774/10804. It
> looks to me like we have been depending on the d_drop in there to get
> rid of dentries in some situations, where we have no other way to get
> rid of them.
>
> The way I noticed this was doing something like this (with the current
> head of 1.6.x, 53da61, no extra patches):
>
> [window 1]
>
> $ cd /afs/.localcell/some-mntpt/somedir
>
> [window 2]
>
> $ fs rmm /afs/.localcell/some-mntpt
> $ cd /afs/.localcell/some-mntpt
>
> Surprisingly, I can still access 'some-mntpt', though it does not show
> up if I 'ls' the dir. With 1.6.6 I get a failure, and the cwd in 'window
> 1' says it doesn't exist, I can't 'cd ..', etc, etc.
>
> I haven't looked too closely at this, but I expect that this previously
> worked because after removing the mountpoint, the dentry revalidate
> would fail and we'd d_drop it. We never explicitly d_drop for an 'fs
> rmm' as far as I can tell, so with 1.6.x right now it sticks around and
> Linux I guess keeps using it....?
>
> One possible way of improving this is to maybe d_drop in
> afs_linux_dentry_revalidate if we know that the entry does in fact no
> longer exist (ENOENT), and d_invalidate for all other errors. But I'm
> not sure if that's necessary or at all correct.

See gerrit 10928 which does roughly that.  If we got ENOENT from a
lookup we want to drop the dentry unconditionally, which is consistent
with what we do for other type of "remove" operations that come in
through vfs calls (unlink, rmdir).

Marc