Prev: ramzswap: Remove backing swap support
Next: vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes
From: Linus Torvalds on 13 May 2010 11:30


On Thu, 13 May 2010, Jan Kara wrote:
>
> 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(a)kernel.org

Hmm? Is this correct? Isn't the bug introduced in this merge window, and
thus not relevant for stable?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 13 May 2010 11:50
On Thu, 13 May 2010 17:41:35 +0200 Jan Kara <jack(a)suse.cz> wrote:

> On Thu 13-05-10 08:24:59, Linus Torvalds wrote:
> >
> >
> > On Thu, 13 May 2010, Jan Kara wrote:
> > >
> > > 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(a)kernel.org
> >
> > Hmm? Is this correct? Isn't the bug introduced in this merge window, and
> > thus not relevant for stable?
> Ah, you're right! I've seen dates in the patches around December so I
> automatically thought the series went to 2.6.33 but checking git logs and
> the actual source code of 2.6.33 it went in later. I'm sorry for the
> confusion.

Yes, it's a bit tricky (for me, at least) to work out "which kernel version did
that patch go into" via git.

I just keep lots of kernel trees around and poke about with `patch
--dry-run'. PITA.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jan Kara on 13 May 2010 11:50
On Thu 13-05-10 08:24:59, Linus Torvalds wrote:
>
>
> On Thu, 13 May 2010, Jan Kara wrote:
> >
> > 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(a)kernel.org
>
> Hmm? Is this correct? Isn't the bug introduced in this merge window, and
> thus not relevant for stable?
Ah, you're right! I've seen dates in the patches around December so I
automatically thought the series went to 2.6.33 but checking git logs and
the actual source code of 2.6.33 it went in later. I'm sorry for the
confusion.

Honza
--
Jan Kara <jack(a)suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jan Kara on 13 May 2010 12:00
On Thu 13-05-10 08:43:35, Andrew Morton wrote:
> On Thu, 13 May 2010 17:41:35 +0200 Jan Kara <jack(a)suse.cz> wrote:
>
> > On Thu 13-05-10 08:24:59, Linus Torvalds wrote:
> > >
> > >
> > > On Thu, 13 May 2010, Jan Kara wrote:
> > > >
> > > > 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(a)kernel.org
> > >
> > > Hmm? Is this correct? Isn't the bug introduced in this merge window, and
> > > thus not relevant for stable?
> > Ah, you're right! I've seen dates in the patches around December so I
> > automatically thought the series went to 2.6.33 but checking git logs and
> > the actual source code of 2.6.33 it went in later. I'm sorry for the
> > confusion.
>
> Yes, it's a bit tricky (for me, at least) to work out "which kernel version did
> that patch go into" via git.
Well, if you know the commit id, "git describe --contains <commit-id>"
tells what you need. But sometimes I'm too lazy to use "git describe" and
sometimes I forget "--contains" which then returns the kernel version on
which the patch was based - not quite what I'm interested in...

Honza
--
Jan Kara <jack(a)suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 13 May 2010 12:00
On Thu, 2010-05-13 at 11:47 -0400, Christoph Hellwig wrote:
> On Thu, May 13, 2010 at 08:43:35AM -0400, Andrew Morton wrote:
> > Yes, it's a bit tricky (for me, at least) to work out "which kernel version did
> > that patch go into" via git.
>
> git-describe <revid>

Actually, that will print the version it was applied to. To find out
the version it was pulled into, you need git-describe --contains <revid>

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: ramzswap: Remove backing swap support
Next: vfs: Fix O_NOFOLLOW behavior for paths with trailing slashes