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