On Thu, 13 Mar 2014 17:40:34 -0500 Andrew Deason <[email protected]> wrote:
> 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....? I think (it has been a while) that the pioctl() happens, a callback from the fileserver occurs, and the version number for the afs inode and dentry no longer match for the containing directory forcing a revalidate of the directory's contents. It does feel like there could be a race in there as well. > 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. This might be a candidate for sillyrename. Something is in use but hasn't lost all references just yet. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
