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 [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
