On 13-Apr-2000 H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>>
>> Here's a minor patch to autofs4. Most of it is cosmetic (for my
>> convenience), but there's a couple of lines of real substance. The
>> daemon can't initiate a mount with its accesses, so its best not to
>> set
>> AUTOFS_PENDING on dentries which are created by daemon accesses, since
>> this confuses things.
>>
>
> Are you sure that won't open up a race condition if another process
> then tries to access that path?
Good question. I made the change a while ago, and remember being
confident it was correct then. But the code is subtle, so I've just gone
through again to convince myself I know how it works.
So the answer is: Yeah, pretty sure.
I don't think there's a case during mount where the daemon looks up a
name that hasn't already been looked up by something else. The subtle
stuff is dealing with processes being blocked on dentries while the
daemon is in the middle of expiring them. That works by making sure the
expired dentry isn't PENDING, but once the expire is done the dentry is
invalidated, forcing the mount request to retry the lookup and get a new
dentry which *is* pending.
Even more subtle is when the daemon decides the half-done mount can't be
completed and tears everything down again. I suspect it doesn't leave a
-ve dentry around to guard against rapid-fire remount requests (because
of the d_drop in the rmdir). I'll look into that in more detail.
The patch fixes a case where processes could keep blocking on a dentry
after it had already been dropped, so they'd either block forever, or let
the user process see a marooned dentry.
I'm thinking it might all be a lot simpler if dentries are never
invalidated. The -ve ones could be reclaimed by the normal machinery,
but revalidate need never return 0. That way a given name in active use
would only ever have a single dentry associated with it, which makes the
bookkeeping much simpler.
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