lkml.org 
[lkml]   [2008]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG: mmapfile/writev spurious zero bytes (x86_64/not i386, bisected, reproducable)


On Tue, 17 Jun 2008, Linus Torvalds wrote:
>
> Bron, does this untested patch hide the bug?

Ok, it does hide the bug.

> I don't think this patch is correct, because it doesn't really fix the
> basic issue (the code should do the right thing even if a page isn't
> there), but it might hide it by faulting in the whole "bytes" range rather
> than just the first iov.
>
> So Nick, it's still over to you, but if this does hide it, then that's an
> interesting detail in itself.

I actually am starting to think that the bug is in
__copy_to_user_inatomic_nocache().

The return value of that thing in the case of a failure seems to be
totally wrong. In particular, since that function does an unrolled loop of
accesses like so:

.Ls1: movq (%rsi),%r11
.Ls2: movq 1*8(%rsi),%r8
.Ls3: movq 2*8(%rsi),%r9
.Ls4: movq 3*8(%rsi),%r10
.Ld1: movnti %r11,(%rdi)
.Ld2: movnti %r8,1*8(%rdi)
.Ld3: movnti %r9,2*8(%rdi)
.Ld4: movnti %r10,3*8(%rdi)

it may have done three of the 64-bit loads, and then trap on the fouth:
but since it hasn't done a _single_ of the stores, it shouldn't count as
any different whether it traps on any of .Ls[1-4]. But that code
definitely seems to think it makes a difference whether the exception
happened at Ls1 or at Ls4, even though both points have copied _exactly_
as many bytes when the exception happens.

So I'm starting to think the bug is all in there, not in the VM itself.
See arch/x86/lib/copy_user_nocache.S.

In fact, even the comment there implies that the author didn't know or
care about returning the correct value.

Andi and Ingo added to Cc.

Linus


\
 
 \ /
  Last update: 2008-06-17 22:21    [W:0.880 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site