mkdir c ln -s c a f=open("a/",O_RDONLY+O_NOFOLLOW) fails with ELOOP. However, this open should behave like open("a/.") not like open("a") according to path_resolution(7). In kernel version 2.6.32 the open worked as documented. On a higher level this bug makes find a/ to fail.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 5 May 2010 13:01:22 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=15909 > > Summary: open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a > symbolic link to a directory. > Product: File System > Version: 2.5 > Kernel Version: 2.6.34-rc6 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Other > AssignedTo: fs_other@kernel-bugs.osdl.org > ReportedBy: tolzmann@molgen.mpg.de > Regression: No > > > mkdir c > ln -s c a > > f=open("a/",O_RDONLY+O_NOFOLLOW) > > fails with ELOOP. However, this open should behave like open("a/.") not like > open("a") according to path_resolution(7). In kernel version 2.6.32 the open > worked as documented. > > On a higher level this bug makes > > find a/ > > to fail. > It sounds like this 2.6.32->2.6.34-rc6 regression could have pretty serious ramifications for some users. Does anyone know whcih commit might have caused it?
i tested 2 more kernel versions: 2.6.33: behaves OK 2.6.34-rc1: FAILs
kernel 2.6.33.3: also OK.. so it seems that some commit between 2.6.33.3->2.6.34-rc1 caused this. regards.. m.
Andrew Morton <akpm@linux-foundation.org> writes: >> mkdir c >> ln -s c a >> >> f=open("a/",O_RDONLY+O_NOFOLLOW) >> >> fails with ELOOP. However, this open should behave like open("a/.") not like >> open("a") according to path_resolution(7). In kernel version 2.6.32 the open >> worked as documented. >> >> On a higher level this bug makes >> >> find a/ >> >> to fail. >> > > It sounds like this 2.6.32->2.6.34-rc6 regression could have pretty > serious ramifications for some users. Does anyone know whcih commit > might have caused it? This probably is the part of do_last cleanup series. (I was looking this series, but unfortunately I also didn't notice about this bug..) And with quick-look, it seems to be in do_last(): /* trailing slashes? */ if (nd->last.name[nd->last.len]) { if (open_flag & O_CREAT) goto exit; nd->flags |= LOOKUP_DIRECTORY; } Before (i.e. do_path_lookup()), it was doing with LOOKUP_FOLLOW for "trailing slash". Current one, it isn't. If Al or someone don't fix, I'll see more later (it may be next weekend or so, sorry). Thanks.
Handled-By : OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
On Tue 11-05-10 17:48:51, Jan Kara wrote: > On Thu 06-05-10 14:30:02, Andrew Morton wrote: > > > > (switched to email. Please respond via emailed reply-to-all, not via the > > bugzilla web interface). > > > > On Wed, 5 May 2010 13:01:22 GMT > > bugzilla-daemon@bugzilla.kernel.org wrote: > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=15909 > > > > > > Summary: open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a > > > symbolic link to a directory. > > > Product: File System > > > Version: 2.5 > > > Kernel Version: 2.6.34-rc6 > > > Platform: All > > > OS/Version: Linux > > > Tree: Mainline > > > Status: NEW > > > Severity: high > > > Priority: P1 > > > Component: Other > > > AssignedTo: fs_other@kernel-bugs.osdl.org > > > ReportedBy: tolzmann@molgen.mpg.de > > > Regression: No > > > > > > > > > mkdir c > > > ln -s c a > > > > > > f=open("a/",O_RDONLY+O_NOFOLLOW) > > > > > > fails with ELOOP. However, this open should behave like open("a/.") not > like > > > open("a") according to path_resolution(7). In kernel version 2.6.32 the > open > > > worked as documented. > > > > > > On a higher level this bug makes > > > > > > find a/ > > > > > > to fail. > > > > > > > It sounds like this 2.6.32->2.6.34-rc6 regression could have pretty > > serious ramifications for some users. Does anyone know whcih commit > > might have caused it? > The patch below fixes the issue for me but someone should have a look > at it because I'm not really an expert in that code and the code paths are so > twisted that my mind is currently tied into a knot ;). > > Honza > --- > > From d53d3cc6488d9135bb69c3ff7e034b3b624866ed Mon Sep 17 00:00:00 2001 > From: Jan Kara <jack@suse.cz> > Date: Tue, 11 May 2010 16:34:25 +0200 > Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes > > According to specification > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) > should return success but currently it did return ELOOP. Fix the code to > ignore > O_NOFOLLOW in case the provided path has trailing slashes. This is a > regression > caused by path lookup cleanup patch series. > > CC: stable@kernel.org > Signed-off-by: Jan Kara <jack@suse.cz> ... BTW: It might be worthwhile to add the attached testcase to LTP? Honza
On Thu 06-05-10 14:30:02, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Wed, 5 May 2010 13:01:22 GMT > bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=15909 > > > > Summary: open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a > > symbolic link to a directory. > > Product: File System > > Version: 2.5 > > Kernel Version: 2.6.34-rc6 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: high > > Priority: P1 > > Component: Other > > AssignedTo: fs_other@kernel-bugs.osdl.org > > ReportedBy: tolzmann@molgen.mpg.de > > Regression: No > > > > > > mkdir c > > ln -s c a > > > > f=open("a/",O_RDONLY+O_NOFOLLOW) > > > > fails with ELOOP. However, this open should behave like open("a/.") not > like > > open("a") according to path_resolution(7). In kernel version 2.6.32 the > open > > worked as documented. > > > > On a higher level this bug makes > > > > find a/ > > > > to fail. > > > > It sounds like this 2.6.32->2.6.34-rc6 regression could have pretty > serious ramifications for some users. Does anyone know whcih commit > might have caused it? The patch below fixes the issue for me but someone should have a look at it because I'm not really an expert in that code and the code paths are so twisted that my mind is currently tied into a knot ;). Honza --- From d53d3cc6488d9135bb69c3ff7e034b3b624866ed Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Tue, 11 May 2010 16:34:25 +0200 Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes According to specification mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) should return success but currently it did return ELOOP. Fix the code to ignore O_NOFOLLOW in case the provided path has trailing slashes. This is a regression caused by path lookup cleanup patch series. CC: stable@kernel.org Signed-off-by: Jan Kara <jack@suse.cz> --- fs/namei.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index a7dce91..4cc7fbc 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1641,7 +1641,7 @@ static struct file *do_last(struct nameidata *nd, struct path *path, if (nd->last.name[nd->last.len]) { if (open_flag & O_CREAT) goto exit; - nd->flags |= LOOKUP_DIRECTORY; + nd->flags |= LOOKUP_DIRECTORY | LOOKUP_FOLLOW; } /* just plain open? */ @@ -1722,7 +1722,7 @@ static struct file *do_last(struct nameidata *nd, struct path *path, if (__follow_mount(path)) { error = -ELOOP; - if (open_flag & O_NOFOLLOW) + if (!(nd->flags & LOOKUP_FOLLOW)) goto exit_dput; } @@ -1830,6 +1830,8 @@ reval: } if (open_flag & O_DIRECTORY) nd.flags |= LOOKUP_DIRECTORY; + if (!(open_flag & O_NOFOLLOW)) + nd.flags |= LOOKUP_FOLLOW; filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname); while (unlikely(!filp)) { /* trailing symlink */ struct path holder; @@ -1837,7 +1839,7 @@ reval: void *cookie; error = -ELOOP; /* S_ISDIR part is a temporary automount kludge */ - if ((open_flag & O_NOFOLLOW) && !S_ISDIR(inode->i_mode)) + if (!(nd.flags & LOOKUP_FOLLOW) && !S_ISDIR(inode->i_mode)) goto exit_dput; if (count++ == 32) goto exit_dput;
On Tue 11-05-10 17:48:51, Jan Kara wrote: > From d53d3cc6488d9135bb69c3ff7e034b3b624866ed Mon Sep 17 00:00:00 2001 > From: Jan Kara <jack@suse.cz> > Date: Tue, 11 May 2010 16:34:25 +0200 > Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes > > According to specification > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) > should return success but currently it did return ELOOP. Fix the code to > ignore > O_NOFOLLOW in case the provided path has trailing slashes. This is a > regression > caused by path lookup cleanup patch series. > > CC: stable@kernel.org > Signed-off-by: Jan Kara <jack@suse.cz> > --- > fs/namei.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/namei.c b/fs/namei.c > index a7dce91..4cc7fbc 100644 > --- a/fs/namei.c > +++ b/fs/namei.c ... > @@ -1722,7 +1722,7 @@ static struct file *do_last(struct nameidata *nd, > struct path *path, > > if (__follow_mount(path)) { > error = -ELOOP; > - if (open_flag & O_NOFOLLOW) > + if (!(nd->flags & LOOKUP_FOLLOW)) > goto exit_dput; > } Sorry for replying to myself... This change is actually unrelated and as I've checked the same behavior is in older kernels. So although the check currently does not quite make sense to me the fix should probably leave it alone. So below is a patch without the above hunk. --- From 2d4a9e9cca7c4f147aa29256ee25de593bb41540 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Tue, 11 May 2010 16:34:25 +0200 Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes According to specification mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) should return success but currently it did return ELOOP. Fix the code to ignore O_NOFOLLOW in case the provided path has trailing slashes. This is a regression caused by path lookup cleanup patch series. CC: stable@kernel.org Signed-off-by: Jan Kara <jack@suse.cz> --- fs/namei.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index a7dce91..16df727 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1641,7 +1641,7 @@ static struct file *do_last(struct nameidata *nd, struct path *path, if (nd->last.name[nd->last.len]) { if (open_flag & O_CREAT) goto exit; - nd->flags |= LOOKUP_DIRECTORY; + nd->flags |= LOOKUP_DIRECTORY | LOOKUP_FOLLOW; } /* just plain open? */ @@ -1830,6 +1830,8 @@ reval: } if (open_flag & O_DIRECTORY) nd.flags |= LOOKUP_DIRECTORY; + if (!(open_flag & O_NOFOLLOW)) + nd.flags |= LOOKUP_FOLLOW; filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname); while (unlikely(!filp)) { /* trailing symlink */ struct path holder; @@ -1837,7 +1839,7 @@ reval: void *cookie; error = -ELOOP; /* S_ISDIR part is a temporary automount kludge */ - if ((open_flag & O_NOFOLLOW) && !S_ISDIR(inode->i_mode)) + if (!(nd.flags & LOOKUP_FOLLOW) && !S_ISDIR(inode->i_mode)) goto exit_dput; if (count++ == 32) goto exit_dput;
Reply-To: subrata@linux.vnet.ibm.com Hi Jan, On Tue, 2010-05-11 at 18:24 +0200, Jan Kara wrote: > On Tue 11-05-10 17:48:51, Jan Kara wrote: > > On Thu 06-05-10 14:30:02, Andrew Morton wrote: > > > > > > (switched to email. Please respond via emailed reply-to-all, not > via the > > > bugzilla web interface). > > > > > > On Wed, 5 May 2010 13:01:22 GMT > > > bugzilla-daemon@bugzilla.kernel.org wrote: > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=15909 > > > > > > > > Summary: open("a/",O_NOFOLLOW) fails with ELOOP if > "a" is a > > > > symbolic link to a directory. > > > > Product: File System > > > > Version: 2.5 > > > > Kernel Version: 2.6.34-rc6 > > > > Platform: All > > > > OS/Version: Linux > > > > Tree: Mainline > > > > Status: NEW > > > > Severity: high > > > > Priority: P1 > > > > Component: Other > > > > AssignedTo: fs_other@kernel-bugs.osdl.org > > > > ReportedBy: tolzmann@molgen.mpg.de > > > > Regression: No > > > > > > > > > > > > mkdir c > > > > ln -s c a > > > > > > > > f=open("a/",O_RDONLY+O_NOFOLLOW) > > > > > > > > fails with ELOOP. However, this open should behave like > open("a/.") not like > > > > open("a") according to path_resolution(7). In kernel version > 2.6.32 the open > > > > worked as documented. > > > > > > > > On a higher level this bug makes > > > > > > > > find a/ > > > > > > > > to fail. > > > > > > > > > > It sounds like this 2.6.32->2.6.34-rc6 regression could have > pretty > > > serious ramifications for some users. Does anyone know whcih > commit > > > might have caused it? > > The patch below fixes the issue for me but someone should have a > look > > at it because I'm not really an expert in that code and the code > paths are so > > twisted that my mind is currently tied into a knot ;). > > > > Honza > > --- > > > > From d53d3cc6488d9135bb69c3ff7e034b3b624866ed Mon Sep 17 00:00:00 > 2001 > > From: Jan Kara <jack@suse.cz> > > Date: Tue, 11 May 2010 16:34:25 +0200 > > Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with > trailing slashes > > > > According to specification > > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) > > should return success but currently it did return ELOOP. Fix the > code to ignore > > O_NOFOLLOW in case the provided path has trailing slashes. This is a > regression > > caused by path lookup cleanup patch series. > > > > CC: stable@kernel.org > > Signed-off-by: Jan Kara <jack@suse.cz> > ... > BTW: It might be worthwhile to add the attached testcase to LTP? It would be great if you can shoot it in the form of a patch, mentioning 1. The GPL Lincense, 2. The purpose of the test case, 3. Exact location it goes, 4. Which LTPROOT/runtest/<file> executes it Regards-- Subrata :-) > > Honza > -- > Jan Kara <jack@suse.cz> > SUSE Labs, CR > > > > > > > > C++ source code > attachment > (open-follow-test.c) > > #define _GNU_SOURCE > #include <stdio.h> > #include <unistd.h> > #include <fcntl.h> > #include <errno.h> > #include <string.h> > #include <sys/stat.h> > #include <sys/types.h> > > int do_test(char *p) > { > int err; > char path[16]; > > strcpy(path, p); > err = open(path, O_NOFOLLOW | O_RDONLY); > if (err >= 0) { > fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) did not fail! > \n", path); > return 1; > } > strcat(path, "/"); > err = open(path, O_NOFOLLOW | O_RDONLY); > if (err < 0) { > fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) failed with % > d\n", path, errno); > return 1; > } > strcat(path, "."); > err = open(path, O_NOFOLLOW | O_RDONLY); > if (err < 0) { > fprintf(stderr, "open(\"%s\", O_NOFOLLOW | O_RDONLY) failed with % > d\n", path, errno); > return 1; > } > return 0; > } > > int main(void) > { > if (mkdir("d", 0700) < 0) { > perror("mkdir"); > return 1; > } > if (symlink("d", "a") < 0) { > perror("link"); > return 1; > } > if (do_test("a")) > return 1; > return 0; > }
(In reply to comment #8) > --- Comment #8 from Jan Kara <jack@suse.cz> 2010-05-11 16:33:08 --- > > diff --git a/fs/namei.c b/fs/namei.c > index a7dce91..16df727 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -1641,7 +1641,7 @@ static struct file *do_last(struct nameidata *nd, > struct > path *path, > if (nd->last.name[nd->last.len]) { > if (open_flag & O_CREAT) > goto exit; > - nd->flags |= LOOKUP_DIRECTORY; > + nd->flags |= LOOKUP_DIRECTORY | LOOKUP_FOLLOW; > } > > /* just plain open? */ > @@ -1830,6 +1830,8 @@ reval: > } > if (open_flag & O_DIRECTORY) > nd.flags |= LOOKUP_DIRECTORY; > + if (!(open_flag & O_NOFOLLOW)) > + nd.flags |= LOOKUP_FOLLOW; > filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname); > while (unlikely(!filp)) { /* trailing symlink */ > struct path holder; > @@ -1837,7 +1839,7 @@ reval: > void *cookie; > error = -ELOOP; > /* S_ISDIR part is a temporary automount kludge */ > - if ((open_flag & O_NOFOLLOW) && !S_ISDIR(inode->i_mode)) > + if (!(nd.flags & LOOKUP_FOLLOW) && !S_ISDIR(inode->i_mode)) > goto exit_dput; > if (count++ == 32) > goto exit_dput; > Hi.. i tested the patch in comment #8 and it works for me. thank you for fixing this bug.. regard, marius..
On Tue, 11 May 2010, Jan Kara wrote: > >From 2d4a9e9cca7c4f147aa29256ee25de593bb41540 Mon Sep 17 00:00:00 2001 > From: Jan Kara <jack@suse.cz> > Date: Tue, 11 May 2010 16:34:25 +0200 > Subject: [PATCH] vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes > > According to specification > mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY) > should return success but currently it did return ELOOP. Fix the code to > ignore > O_NOFOLLOW in case the provided path has trailing slashes. This is a > regression > caused by path lookup cleanup patch series. > > CC: stable@kernel.org > Signed-off-by: Jan Kara <jack@suse.cz> Acked-by: Miklos Szeredi <mszeredi@suse.cz> > --- > fs/namei.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/fs/namei.c b/fs/namei.c > index a7dce91..16df727 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -1641,7 +1641,7 @@ static struct file *do_last(struct nameidata *nd, > struct path *path, > if (nd->last.name[nd->last.len]) { > if (open_flag & O_CREAT) > goto exit; > - nd->flags |= LOOKUP_DIRECTORY; > + nd->flags |= LOOKUP_DIRECTORY | LOOKUP_FOLLOW; > } > > /* just plain open? */ > @@ -1830,6 +1830,8 @@ reval: > } > if (open_flag & O_DIRECTORY) > nd.flags |= LOOKUP_DIRECTORY; > + if (!(open_flag & O_NOFOLLOW)) > + nd.flags |= LOOKUP_FOLLOW; > filp = do_last(&nd, &path, open_flag, acc_mode, mode, pathname); > while (unlikely(!filp)) { /* trailing symlink */ > struct path holder; > @@ -1837,7 +1839,7 @@ reval: > void *cookie; > error = -ELOOP; > /* S_ISDIR part is a temporary automount kludge */ > - if ((open_flag & O_NOFOLLOW) && !S_ISDIR(inode->i_mode)) > + if (!(nd.flags & LOOKUP_FOLLOW) && !S_ISDIR(inode->i_mode)) > goto exit_dput; > if (count++ == 32) > goto exit_dput; > -- > 1.6.4.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Hi, On Tue 11-05-10 22:05:52, Subrata Modak wrote: > It would be great if you can shoot it in the form of a patch, mentioning > > 1. The GPL Lincense, > 2. The purpose of the test case, > 3. Exact location it goes, > 4. Which LTPROOT/runtest/<file> executes it With a help of Cyril I've created the attached patch and verified that the test fails on 2.6.33 but succeeds on 2.6.32... Honza
Reply-To: subrata@linux.vnet.ibm.com On Wed, 2010-05-12 at 17:59 +0200, Jan Kara wrote: > Hi, > > On Tue 11-05-10 22:05:52, Subrata Modak wrote: > > It would be great if you can shoot it in the form of a patch, mentioning > > > > 1. The GPL Lincense, > > 2. The purpose of the test case, > > 3. Exact location it goes, > > 4. Which LTPROOT/runtest/<file> executes it > With a help of Cyril I've created the attached patch and verified that > the test fails on 2.6.33 but succeeds on 2.6.32... Great. Thanks for the patch. But, it falters on the latest git. Can you please rebase and resend: patching file testcases/kernel/syscalls/open/open07.c Hunk #1 succeeded at 40 with fuzz 1. Hunk #2 FAILED at 73. Hunk #3 FAILED at 136. Hunk #4 succeeded at 173 with fuzz 2 (offset -1 lines). Hunk #5 FAILED at 185. Hunk #6 FAILED at 203. Hunk #7 FAILED at 226. Hunk #8 FAILED at 249. 6 out of 8 hunks FAILED -- saving rejects to file testcases/kernel/syscalls/open/open07.c.rej Regards-- Subrata > > Honza
On Wed 12-05-10 22:16:03, Subrata Modak wrote: > On Wed, 2010-05-12 at 17:59 +0200, Jan Kara wrote: > > Hi, > > > > On Tue 11-05-10 22:05:52, Subrata Modak wrote: > > > It would be great if you can shoot it in the form of a patch, mentioning > > > > > > 1. The GPL Lincense, > > > 2. The purpose of the test case, > > > 3. Exact location it goes, > > > 4. Which LTPROOT/runtest/<file> executes it > > With a help of Cyril I've created the attached patch and verified that > > the test fails on 2.6.33 but succeeds on 2.6.32... > > Great. Thanks for the patch. But, it falters on the latest git. Can you > please rebase and resend: Ah, OK. Sorry for that. Now a patch rediffed against latest git tree of LTP. Hopefully this time I got it right. Honza
Reply-To: subrata@linux.vnet.ibm.com On Thu, 2010-05-13 at 13:29 +0200, Jan Kara wrote: > On Wed 12-05-10 22:16:03, Subrata Modak wrote: > > On Wed, 2010-05-12 at 17:59 +0200, Jan Kara wrote: > > > Hi, > > > > > > On Tue 11-05-10 22:05:52, Subrata Modak wrote: > > > > It would be great if you can shoot it in the form of a patch, > mentioning > > > > > > > > 1. The GPL Lincense, > > > > 2. The purpose of the test case, > > > > 3. Exact location it goes, > > > > 4. Which LTPROOT/runtest/<file> executes it > > > With a help of Cyril I've created the attached patch and verified that > > > the test fails on 2.6.33 but succeeds on 2.6.32... > > > > Great. Thanks for the patch. But, it falters on the latest git. Can you > > please rebase and resend: > Ah, OK. Sorry for that. Now a patch rediffed against latest git tree of > LTP. Hopefully this time I got it right. Thanks. Regards-- Subrata > > Honza
Patch : https://patchwork.kernel.org/patch/99291/ Handled-By : Jan Kara <jack@suse.cz>
On Monday, June 14, 2010, Jan Kara wrote: > On Sun 13-06-10 16:48:58, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of regressions introduced between 2.6.33 and 2.6.34. > > > > The following bug entry is on the current list of known regressions > > introduced between 2.6.33 and 2.6.34. Please verify if it still should > > be listed and let the tracking team know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15909 > > Subject : open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a > symbolic link to a directory. > > Submitter : Marius Tolzmann <tolzmann@molgen.mpg.de> > > Date : 2010-05-05 13:01 (40 days old) > > Handled-By : OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> > > Jan Kara <jack@suse.cz> > > Patch : https://patchwork.kernel.org/patch/99291/ > The fix went in shortly before 2.6.34 was released (commit > 002baeecf53677d2034113e34197ec221f42e037). So everything should be fine.