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 _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
