> 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

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



Jan KaraがAl ViroのせいでVFSがこわれたぞって修正パッチをポストしたところ、
Linusから、なんで今回のマージウィンドウでマージされたパッチに対する修正が -stableへの
バックポートが必要なのか。というツッコミが。


On Thu, 13 May 2010, Andrew Morton wrote:
>
> > 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.



まず、Andrew Mortonがバージョン毎のツリーを抱えて、いちいち patch --dry-run で
当ててみるという自身の力業テクを披露

それをみたLinus大先生による、どうやってバージョン特定を簡単にやるかという
git講座が開始される


What I did to double-check was:

git log fs/namei.c

to find the commit series by Al (obviously, you can do it other ways too,
but that was the easy way). Then, when you find the commit just do

git name-rev 1f36f774b22a0ceb7dd33eca626746c81a97b6a5

which gives us

1f36f774b22a0ceb7dd33eca626746c81a97b6a5 tags/v2.6.34-rc1~195^2

ie that commit is reachable from v2.6.34-rc1, not from any stable kernel.

(Or alternatively, use "git describe", and get "v2.6.33-5088-g1f36f77",
which means that it is v2.6.33 plus 5088 commits).

And as usual, there are other ways. One particularly obscure one is to say

git log --tags --source --author=viro fs/namei.c

which basically says "show only commits by viro in fs/namei.c, start from
all tags, and for each commit, show _which_ tag the commit was reached
from". It's not perfect, but it does it in one go. With "--oneline", you'd
have gotten a listing like

3e297b6 v2.6.34-rc3 Restore LOOKUP_DIRECTORY hint handling in final lookup on open()
781b167 v2.6.34-rc2 Fix a dumb typo - use of & instead of &&
1f36f77 v2.6.34-rc2 Switch !O_CREAT case to use of do_last()
def4af3 v2.6.34-rc2 Get rid of symlink body copying
3866248 v2.6.34-rc2 Finish pulling of -ESTALE handling to upper level in do_filp_open()
806b681 v2.6.34-rc2 Turn do_link spaghetty into a normal loop
10fa8e6 v2.6.34-rc2 Unify exits in O_CREAT handling
9e67f36 v2.6.34-rc2 Kill is_link argument of do_last()
...

so you see into which -rc the different patches from Al went.

Linus
--
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



超訳

git name-rev 1f36f774b22a0ceb7dd33eca626746c81a97b6a5

みたいに、git name-rev [commit-id] ってやれば

1f36f774b22a0ceb7dd33eca626746c81a97b6a5 tags/v2.6.34-rc1~195^2

こんな感じで、v2.6.34-rc1 で入ったって分かる。
もっと簡単にやるには

git log --tags --source --author=viro --oneline fs/namei.c

とかすると、fs/namei.c ファイルに入ったAl Viroの修正一覧がバージョンと共にずらっとでるよ。

3e297b6 v2.6.34-rc3 Restore LOOKUP_DIRECTORY hint handling in final lookup on open()
781b167 v2.6.34-rc2 Fix a dumb typo - use of & instead of &&
1f36f77 v2.6.34-rc2 Switch !O_CREAT case to use of do_last()
def4af3 v2.6.34-rc2 Get rid of symlink body copying
3866248 v2.6.34-rc2 Finish pulling of -ESTALE handling to upper level in do_filp_open()
806b681 v2.6.34-rc2 Turn do_link spaghetty into a normal loop
10fa8e6 v2.6.34-rc2 Unify exits in O_CREAT handling
9e67f36 v2.6.34-rc2 Kill is_link argument of do_last()
...