Re: [autofs] [RFC PATCH]autofs4: hang and proposed fix

[Ian Kent <raven@themaw.net>]

On Fri, 18 Nov 2005, William H. Taber wrote:

> Ian Kent wrote:
> > On Fri, 18 Nov 2005, William H. Taber wrote:
> > > 
> > > No, it is actually a little more subtle than that.  The problem is that
> > > since
> > > you can be called from two code paths, one of which get's the lock and one
> > > of
> > > them doesn't, you are stuck if you find that the lock is held because you
> > > don't know who holds it.  The danger is that some innocent third party is
> > > holding the lock and counting on being protected by it. If you release the
> > > lock, then you can be creating the potential for a race in their code and
> > > there would be no way to detect it.  Their code path would look correct
> > > because it is.  Not only that but the lock itself could get confused
> > > because
> > > it would have more unlocks than locks, because presumably the process that
> > > thinks it has the lock would eventually unlock as well.  I don't know how
> > > the
> > > semaphores are implemented on all architectures so I don't know if that
> > > would
> > > be an actual problem or not but it I would be surprised if they all
> > > handled
> > > that case gracefully.
> > 
> > 
> > Yes. Thinking about it I hadn't considered the third process.
> > 
> > How can we get advice on this?
> > 
> > Ian
> > 
> Hey, I'm new here. I came here looking for advice. :^)

Ha. It's probably wearing a bit thin for me to say I'm new here but my 
patch is quite small and I've got a lot to learn and I'm lovin' it.

> However, if there is no way to fix this in the autofs code then the only
> alternative is to fix the locking in the VFS.  So VFS folks, which is the
> better solution.  Should all callers to d_revalidate get the parent's i_sem
> lock or should d_revalidate never be called with the parent i_sem lock and so
> we need to change lookup_one_len so that it does not expect the parent i_sem
> lock to be held?

Maybe. See next post.

Ian