On Tue, 29 Nov 2005, Jeff Moyer wrote:
> ==> Regarding [autofs] [RFC PATCH]autofs4: hang and proposed fix; [EMAIL
> PROTECTED] (Ram Pai) adds:
>
> linuxram> Autofs4 assumes that its ->revalidate() function gets called with
> linuxram> the parent_dentry's_inode_semaphore released. This is true mostly
> linuxram> but not in one particular case.
>
> linuxram> Process P1 calls autofs4's ->lookup(). The lookup finds that the
> linuxram> dentry does not exist. It creates a dentry and adds to the
> linuxram> cache. Releases the parent's inode's semaphore and than calls
> linuxram> ->revalidate().
>
> linuxram> Process P2 meanwhile comes in and cached_lookup() gets called. It
> linuxram> finds the dentry in the cache and finds ->revalidate() function
> linuxram> exists. So it calls ->revalidate() holding the parent's inode's
> linuxram> semaphore.
>
> Can't we simply fix this case? It seems like it should be perfectly safe
> to drop the parent's i_sem before calling revalidate in cached_lookup. In
> fact, there are comments in the NFS code that would lead one to believe
> that revalidate is not supposed to be called with the parent's i_sem held:
>
> static int nfs_lookup_revalidate(struct dentry * dentry, struct nameidata *nd)
> {
> ...
> /*
> * Note: we're not holding inode->i_sem and so may be racing with
> * operations that change the directory. We therefore save the
> * change attribute *before* we do the RPC call.
> */
>
> Can you try out a patch which does this?
Could it be as simple as that?
Food for more thought.
Ian
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
