* first access fails with ENOENT after autofs started @ 2008-01-29 9:36 wengang wang 2008-01-29 15:28 ` Ian Kent 0 siblings, 1 reply; 6+ messages in thread From: wengang wang @ 2008-01-29 9:36 UTC (permalink / raw) To: autofs Hi experts, In RHEL kernel 2.6.18-53 and mainline kernel 2.6.24, 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(). 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? thanks, wengang. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: first access fails with ENOENT after autofs started 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 0 siblings, 1 reply; 6+ messages in thread From: Ian Kent @ 2008-01-29 15:28 UTC (permalink / raw) To: wengang wang; +Cc: autofs 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. I'm not aware of a problem with 2.6.24. > 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. Ian ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: first access fails with ENOENT after autofs started 2008-01-29 15:28 ` Ian Kent @ 2008-01-30 3:32 ` wengang wang 2008-01-30 4:05 ` Ian Kent 0 siblings, 1 reply; 6+ messages in thread From: wengang wang @ 2008-01-30 3:32 UTC (permalink / raw) To: Ian Kent; +Cc: autofs 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: first access fails with ENOENT after autofs started 2008-01-30 3:32 ` wengang wang @ 2008-01-30 4:05 ` Ian Kent 2008-01-30 5:09 ` wengang wang 0 siblings, 1 reply; 6+ messages in thread From: Ian Kent @ 2008-01-30 4:05 UTC (permalink / raw) To: wengang wang; +Cc: autofs 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: first access fails with ENOENT after autofs started 2008-01-30 4:05 ` Ian Kent @ 2008-01-30 5:09 ` wengang wang 2008-02-04 5:25 ` junpyo.kim 0 siblings, 1 reply; 6+ messages in thread From: wengang wang @ 2008-01-30 5:09 UTC (permalink / raw) To: Ian Kent; +Cc: autofs 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: first access fails with ENOENT after autofs started 2008-01-30 5:09 ` wengang wang @ 2008-02-04 5:25 ` junpyo.kim 0 siblings, 0 replies; 6+ messages in thread From: junpyo.kim @ 2008-02-04 5:25 UTC (permalink / raw) To: wengang wang, Ian Kent; +Cc: autofs Dear experts. I have problem transient chdir fails on kernel 2.6.9-67.ELsmp RHEL(WS Version4). I'd been heard patch, have you any patch? Know that update linux kernel, but can't update kernel. Because ECAD Tools(such as synopsys, cadense etc.). Do you have any idea? Thank you. ================================================== JunPyo Kim, CE DT Team junpyo.kim@magnachip.com +82-10-2894-4415 / +82-2-6903-4637 -----Original Message----- From: autofs-bounces@linux.kernel.org [mailto:autofs-bounces@linux.kernel.org] On Behalf Of wengang wang Sent: Wednesday, January 30, 2008 2:09 PM To: Ian Kent Cc: autofs@linux.kernel.org Subject: Re: [autofs] first access fails with ENOENT after autofs started 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 _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-02-04 5:25 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2008-01-30 4:05 ` Ian Kent 2008-01-30 5:09 ` wengang wang 2008-02-04 5:25 ` junpyo.kim
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.