On 13-Apr-2000 H. Peter Anvin wrote:
> Now how do you deal with the following case:
>
> Process 1 does a lookup on /foo/bar, triggers daemon response
> The daemon mkdirs /foo/bar
> Process 2 accesses /foo/bar (no lookup happens, because the dentry
> exists)
> The daemon fails to mount /foo/bar, does an rmdir()
> The kernel releases process 1 and 2.
>
> Process 1 is still OK, because it's in lookup, which can fail normally.
> Process 2 is not so lucky.
Process 2 is blocked in revalidate->try_to_fill_dentry. Revalidate
returns 1 (valid), but it's a -ve unhashed (because of rmdir) dentry.
Because its -ve, process 2 gets ENOENT. Later lookups generate a new
dentry and mount attempt. Unfortunately this loses the rate-limiting
property for this kind of failed mount (it will still work when the
failure happens early, before daemon starts creating mount-points).
If dentries were never invalidated or dropped it would be much easier to
keep track of them for things like rate-limiting failed mounts.
> In autofs v3 this was buggy for a *long* time after dentries were
> introduced: process 2 would end up in a phantom empty directory which
> didn't really exist.
That's precisely the problem this patch fixes, but it was a corner case
subtle for me to remember without reproducing. It mostly worked before
then.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:22 EST