On Thu, Mar 13, 2014 at 6:40 PM, Andrew Deason <[email protected]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
