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

[Will Taber <wtaber@us.ibm.com>]

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.

Regards,
Will


Will