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

[Ian Kent <raven@themaw.net>]

On Fri, 2 Dec 2005, Will Taber wrote:

> Ian Kent wrote:
> 
> > 
> > Good call. A single example is sufficient to refute my assertion.
> > 
> > But to focus the discussion, the goal is to identify that the calling
> > process is the one that holds the semaphore to justify releasing it. For
> > lookup it's easy as it's always called with it held. lookup_hash will always
> > call revalidate or lookup with the nameidata struct NULL and so can be used
> > to identify the semaphore ownership similar to the devfs code Will
> > mentioned. I don't think the other tests there are relevant to autofs. The
> > patch will require some rework but still the same general idea.
> > 
> > Can you think of an example code path where __lookup_hash is called with a
> > non null nameidata struct which leads to autofs4 revalidate or lookup.
> > 
> 
> It looks as though __lookup_hash is called from open_namei with the lock held
> and a nameidata structure.  It also looks as though LOOKUP_OPEN is set in the
> nameidata->flags so you should be able to identify this case.  No, that's not
> because lookup_open does a path_walk to get the parent without the lock.  So
> it looks as though if you have a nameidata structure and the flags have
> LOOKUP_OPEN and LOOKUP_CREATE set but not LOOKUP_PARENT, then you are holding
> the i_sem lock.  The devfs code ignores LOOKUP_OPEN.  I have to go right now
> and I am not sure if the checks are equivalent so I will leave that as an
> exercise for the reader.

The create case is not used by autofs. Shouldn't need to be considered.

Ian