copyout across 256MB boundary bug in 10.4.1
copyout across 256MB boundary bug in 10.4.1
- Subject: copyout across 256MB boundary bug in 10.4.1
- From: Andrew Gallatin <email@hidden>
- Date: Thu, 30 Jun 2005 17:55:15 -0400 (EDT)
I'm attempting to copyout a huge amount of data (a few hundred megs,
broken into 508KB chunks) from the ioctl routine of a driver. I think
I'm seeing corruption when copying out across 256MB boundaries in the
process address space. Many chunks (I've tested up to 512MB, but it
can go higher) are copied in a fairly tight loop, which calls
copyout on 127 pages at a time.
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.
This corruption disappears entirely if I alter my code
to never copyout across a 256MB boundary.
I know that the copyout code treats 256MB as "special", as I
see references to it in the ./osfmk/ppc/pmap.c:MapUserMemoryWindow()
as well as in ./osfmk/ppc/movc.s However, I'm not fluent
in mach vm, or pps asm, so most of that code is Greek to me.
I can't make this fail on panther (10.3.5), only on tiger (10.4.1).
The processes are 32-bits. The test machine is a dual 2.0GHz G5 with
4.5GB of ram.
The failures seem most likely to occur just after I re-compile
the test executable. I tried all kinds of tests to put memory
pressure on the system, but the most reliable way to induce
this is to rebuild the test binary just before running it.
After the first failure, the test always succeeds.
Am I crazy, or is there a bug here? ( or both ;)
Thanks in advance for any help,
Drew
_______________________________________________
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