[OpenAFS-devel] afs_linux_dentry_revalidate and d_drop

[Andrew Deason]

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.

I'm not really sure what's happening, but I'm a little focused elsewhere
at the moment, so I thought maybe others could maybe look into it, if
anyone is so motivated.

-- 
Andrew Deason
adeason@sinenomine.net