Re: copyout across 256MB boundary bug in 10.4.1
Re: copyout across 256MB boundary bug in 10.4.1
- Subject: Re: copyout across 256MB boundary bug in 10.4.1
- From: William Kucharski <email@hidden>
- Date: Mon, 4 Jul 2005 02:16:48 -0500
On Jun 30, 2005, at 4:55 PM, Andrew Gallatin wrote:
It seems rock solid for small buffers, but once I get over a few
hundred megs, I see some "interesting" corruption. The corruption
starts at user address 0x10000000 and continues through the page
starting at 0x1006f000. Another "bad spot" appears at 0x20000000 and
continues through the page starting at 0x2006f000. Moreover, the
contents which should appear at 0x20000000..0x2006ffff appear at
0x10000000..0x1006ffff, while I see stale data at
0x20000000..0x2006ffff. This makes it seem like large copyouts which
cross a 256MB boundary may wrap around, and write to exactly 256MB
below the desired address.
256MB boundaries are "magic" as they denote the PPC "segment" to be
referenced, and segment registers are part of the PPC VM translation
mechanism. Simply put, each 256MB-aligned chunk is translated using
a different segment register value. (For 32-bit PPCs, the segment ID
is the virtual address & 0xf0000000).
The copyin/copyout mechanism works in an interesting manner, mapping
512MB chunks of the user memory space into the kernel address range
0xe0000000 - 0xffffffff.
So for example, accesses to virtual address 0x1000 would be mapped via
the kernel to kernel address 0xe0001000.
For what you're seeing to make sense, what must be happening is that
since you're wrapping around a 256MB boundary, the segment register
that SHOULD be programmed for the next 256MB "chunk" is actually being
programmed to point to the original 256MB chunk.
Do you see this same failure on 32-bit PPCs, or just on G5s? I know
you mentioned your test machine was a G5, but I'm just curious if we
can rule out the 32-bit VM code here.
William Kucharski
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden