Re: first access fails with ENOENT after autofs started

[wengang wang <wen.gang.wang@oracle.com>]

Hi Ian,

I checked the patch for 53.1.4,  and my patch is the same as that one:)
will use 53.1.4 if there is no special patches on the under using version.

thanks,
wengang.

Ian Kent wrote:
> On Wed, 2008-01-30 at 11:32 +0800, wengang wang wrote:
>   
>> Thanks Ian for your reply.
>>
>> Ian Kent wrote:
>>     
>>> On Tue, 2008-01-29 at 17:36 +0800, wengang wang wrote:
>>>   
>>>       
>>>> Hi experts,
>>>>
>>>> In RHEL kernel 2.6.18-53 and mainline kernel 2.6.24,
>>>>     
>>>>         
>>> This was a known problem due to a couple of missing patches in the
>>> RHEL-5 kernel revision 53.
>>>
>>>   
>>>       
>> yes.
>>     
>>> I'm not aware of a problem with 2.6.24.
>>>
>>>   
>>>       
>> yes, there is no problem with 2.6.24. 
>> By involving it, I just want to say the code
>> d_instantiate(); //not d_add()
>> is the same.
>>     
>>>> in function autofs4_lookup() in fs/autofs4/root.c,
>>>> if dentry is not found in function autofs4_lookup_unhashed(),
>>>> a d_instantiate() is done on the dentry passed as parameter instead of 
>>>> d_add().
>>>>     
>>>>         
>>> d_instantiate is used to delay hashing the dentry until the following
>>> mkdir as this prevents a potential deadlock.
>>>
>>>   
>>>       
>>>> seems this cause a problem that the first access just after autofs 
>>>> started to
>>>> /path/to/<autofsMountPoint>/<nfsMountPoint> fail with the error ENOENT.
>>>>
>>>> If I rolled back to use d_add(), there is no such problem.
>>>> Is this a bug or I omitted something?
>>>>     
>>>>         
>>> Considering there's virtually no information to go on here I have no
>>> idea but this hasn't been seen to be a problem other than in the RHEL
>>> kernel above.
>>>
>>> You will need to provide a lot more information than this if you want me
>>> to investigate.
>>>
>>>   
>>>       
>> detail for this problem is:
>> 1)  adding a line in /etc/auto.master
>>      /topdir   /etc/auto.topdir
>> 2) in auto.topdir
>>     subdir   -fstype=nfs   hostname:/path/to/exported/directory
>> 3) /etc/init.d/autofs restart
>> 4) ll /topdir/subdir
>>     got NO SUCH DIRECTORY here. 
>>     by strace, lstat returned ENOENT.
>>
>> according to your
>>
>> This was a known problem due to a couple of missing patches in the
>> RHEL-5 kernel revision 53.
>>
>> I made a patch by comparing RHEL-5 53 kernel with 2.6.24.  and seems it 
>> solves the problem.
>>     
>
> Why, an updated kernel is available for RHEL-5 and has been for some
> time. Try revision 53.1.4.
>
> I started on getting this fixed as soon as I noticed the patches
> missing.
>
>   
>> the patch is as below:
>> ----------------------------------------------------------------------------------------------------
>> --- ./fs/autofs4/root.c.orig    2008-01-29 22:20:18.000000000 -0500
>> +++ ./fs/autofs4/root.c 2008-01-29 22:20:47.000000000 -0500
>> @@ -662,10 +662,18 @@
>>          * doesn't do the right thing for all system calls, but it should
>>          * be OK for the operations we permit from an autofs.
>>          */
>> -       if (dentry->d_inode && d_unhashed(dentry)) {
>> +       if (!oz_mode && d_unhashed(dentry)) {
>> +               struct dentry *parent = dentry->d_parent;
>> +               struct dentry *new = d_lookup(parent, &dentry->d_name);
>> +               if (new != NULL)
>> +                       dentry = new;
>> +               else
>> +                       dentry = ERR_PTR(-ENOENT);
>> +
>>                 if (unhashed)
>>                         dput(unhashed);
>> -               return ERR_PTR(-ENOENT);
>> +
>> +               return dentry;
>>         }
>>  
>>         if (unhashed)
>> ----------------------------------------------------------------------------------------------------
>>
>> is this patch ok and enough for RHEL-5 kernel revision 53?
>>     
>
> Can't remember now but it's the dentry->d_inode -> !oz_mode change that
> is needed for the d_add -> d_instantiate deadlock fix and yes we also
> need to check if someone beat us to the mount with the d_lookup.
>
> However, you really should use the supported updates.
>
> Ian
>
>
>   

-- 
Wengang Wang
Member of Technical Staff
Oracle Asia R&D Center
Open Source Technologies Development

Tel:      +86 10 8278 6265
Mobile:   +86 13381078925