Re: [uml-user] possible data corruption with uml guest 2.6.32

[Janjaap B. <ja...@bo...>]

On Mon, 2010-03-08 at 19:25 +0100, Matthias Rieber wrote:
> This happens with 2.6.32.8 and .9 (9 with the fixed rlimit patch). Is 
> this a know issue? Wrong kernel config?
> 
> matthias


Hi Matthias,

Yes, there is an issue with integrity of ubd block operations in kernels
later than v2.6.30-rc1. I made a patch that solved my problems, which
has been running fine for a couple of weeks now.

I just use skas0, which works fine for me. Using your script I get the
following result on uml, with kernel 2.6.33-rc6

50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 9.24587 s, 5.7 MB/s
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin
9339e16d3b55810e6370ac7903e8d815  ./test.bin

Basically I had to revert a kernel commit. See below.

I have attached a patch for you to test. It is for kernel git
v2.6.33-rc6 which I currently use. (for x64_86). There are couple of
other changes included that I saw on this list.

If this solves it for you as well, I will forward it to uml-devel to
have it included in mainstream.

Regards,

-Janjaap


--------

reverted: commit f81f2f7c9fee307e371f37424577d46f9eaf8692
                  Author: Tejun Heo <tj...@ke...>
                  Date:   Tue Apr 28 13:06:10 2009 +0900
    
ubd: drop unnecessary rq->sector manipulation

ubd curiously updates rq->sector while issuing the request in multiple
pieces.  Don't do it and simply use local copy of sector.
    [ Impact: cleanup ]

--------------


The reason why these updates are needed was foreseen by Jeff in:

commit 0a6d3a2a3813e7b25267366cfbf9a4a4698dd1c2
Author: Jeff Dike <jd...@ad...>
Date:   Sun Jul 15 23:38:47 2007 -0700
    
uml: fix request->sector update
    
It is theoretically possible for a request to finish and be freed
between writing it to the I/O thread and updating the sector count.  In
this case, the update will dereference a freed pointer.
    
To avoid this, I delay the update until processing the next sg segment,
when the request pointer is known to be good.