Bug 15909 - open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a symbolic link to a directory.
open("a/",O_NOFOLLOW) fails with ELOOP if "a" is a symbolic link to a directory.
Status: CLOSED CODE_FIX
Product: File System
Classification: Unclassified
Component: Other
All Linux
: P1 high
Assigned To: fs_other
:
Depends on:
Blocks: 15310
  Show dependency treegraph
 
Reported: 2010-05-05 13:01 UTC by Marius Tolzmann
Modified: 2010-06-14 14:20 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.34-rc6
Tree: Mainline
Regression: Yes


Attachments

Description Marius Tolzmann 2010-05-05 13:01:20 UTC
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.
Comment 1 Andrew Morton 2010-05-06 21:31:17 UTC
(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?
Comment 2 Marius Tolzmann 2010-05-06 22:39:37 UTC
i tested 2 more kernel versions:

2.6.33: behaves OK

2.6.34-rc1: FAILs
Comment 3 Marius Tolzmann 2010-05-07 10:14:24 UTC
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.
Comment 4 OGAWA Hirofumi 2010-05-09 16:03:43 UTC
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.
Comment 5 Rafael J. Wysocki 2010-05-09 21:36:24 UTC
Handled-By : OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Comment 6 Jan Kara 2010-05-11 16:25:57 UTC
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
Comment 7 Jan Kara 2010-05-11 16:33:00 UTC
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;
Comment 8 Jan Kara 2010-05-11 16:33:08 UTC
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;
Comment 9 Anonymous Emailer 2010-05-11 16:36:44 UTC
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;
> }
Comment 10 Marius Tolzmann 2010-05-11 17:47:56 UTC
(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..
Comment 11 Miklos Szeredi 2010-05-12 10:38:31 UTC
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
>
Comment 12 Jan Kara 2010-05-12 16:38:03 UTC
  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
Comment 13 Anonymous Emailer 2010-05-12 16:47:00 UTC
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
Comment 14 Jan Kara 2010-05-13 11:30:47 UTC
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
Comment 15 Anonymous Emailer 2010-05-17 20:07:25 UTC
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
Comment 16 Rafael J. Wysocki 2010-06-13 13:39:30 UTC
Patch : https://patchwork.kernel.org/patch/99291/
Handled-By : Jan Kara <jack@suse.cz>
Comment 17 Rafael J. Wysocki 2010-06-14 14:13:08 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.