Re: BUG: mmapfile/writev spurious zero bytes (x86_64/not i386, bisected, reproducable)

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Bron Gondwana <brong@...>
Cc: Linux Kernel Mailing List <linux-kernel@...>, Nick Piggin <npiggin@...>, Andrew Morton <akpm@...>, Rob Mueller <robm@...>, Andi Kleen <andi@...>, Ingo Molnar <mingo@...>
Date: Tuesday, June 17, 2008 - 5:20 pm

On Tue, 17 Jun 2008, Linus Torvalds wrote:

Ok, so I just rebooted with this, and it does indeed fix the bug.

I'd be happier with a more complete fix (ie being byte-accurate and 
actually doing the partial copy when it hits a fault in the middle), but 
this seems to be the minimal fix, and at least fixes the totally bogus 
return values from the x86-64 __copy_user*() functions.

Not that I checked that I got _all_ cases correct (and maybe there are 
other versions of __copy_user that I missed entirely), but Bron's 
test-case at least seems to work properly for me now.

Bron? If you have a more complete test-suite (ie the real-world case that 
made you find this), it would be good to verify the whole thing. 

And again, this is the kind of thing that really wants others looking at 
it. I personally think that this thing should likely be written as C code, 
with just the inner loops done as asm (ie the inner "rep movsq" and the 
inner 64-byte unrolled cached/uncached copies done as inline asms, and 
then the outer layers could be C).

		Linus
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: BUG: mmapfile/writev spurious zero bytes (x86_64/not i38..., Linus Torvalds, (Tue Jun 17, 5:20 pm)