[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.020 / U:5.960 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site