[lkml]   [2006]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.6.20-rc1

On Fri, 15 Dec 2006, Alistair John Strachan wrote:
> In total isolation, v2.6.19..0e75f9063f5c55fb0b0b546a7c356f8ec186825e it
> breaks. Reverting just 0e75f9063f5c55fb0b0b546a7c356f8ec186825e, it works
> again.
> So I think this is the source, but I can't explain why it "goes away" before
> git1 and "comes back" before 2.6.20-rc1.

Can you see if the kernel state at commit 77d172ce ("[PATCH] fix SG_IO bio
leak") is good? Ie just do something like

git checkout -b test-branch 77d172ce

and compile and test that?

That commit _should_ be the one that fixed whatever problems that commit
0e75f906 introduced. It *did* fix it for other - somewhat similar -

That said: Jens - I think 0e75f906 was a mistake. "blk_rq_unmap()" really
should be passed the "struct bio", not the "struct request *". Right now
it does something _really_ strange with requests with linked bio's, and I
don't think your and FUJITA's "leak fix" really works. What happens when
the bio was a linked list on the request, and you put the old _head_ on
the request with "rq->bio = bio"? What happens to the other parts of it?

IOW, I think this is broken. I think we should revert 0e75f906. Or at
least you should explain to me why it's not broken, and why clearly people
(eg Alistair) still see problems with it?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.093 / U:1.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site