From: wengang wang <wen.gang.wang@oracle.com>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org
Subject: Re: first access fails with ENOENT after autofs started
Date: Wed, 30 Jan 2008 11:32:56 +0800 [thread overview]
Message-ID: <479FEFE8.6030800@oracle.com> (raw)
In-Reply-To: <1201620505.3435.6.camel@raven.themaw.net>
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.
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?
> Ian
thanks,
wengang.
next prev parent reply other threads:[~2008-01-30 3:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 9:36 first access fails with ENOENT after autofs started wengang wang
2008-01-29 15:28 ` Ian Kent
2008-01-30 3:32 ` wengang wang [this message]
2008-01-30 4:05 ` Ian Kent
2008-01-30 5:09 ` wengang wang
2008-02-04 5:25 ` junpyo.kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=479FEFE8.6030800@oracle.com \
--to=wen.gang.wang@oracle.com \
--cc=autofs@linux.kernel.org \
--cc=raven@themaw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.