Who understands this code?
gschafer at zip.com.au
Fri Mar 14 14:08:29 PST 2003
On Fri, Mar 14, 2003 at 04:41:00PM -0500, Donald Smith wrote:
> I don't think it's a bug at all, just a timing problem and a brain dead
> test. What the test is trying to determine is whether it can unmap two
> contiguous mmap'ed regions with a single munmap call. Unfortunately due
> to timing of events, the ld.so.cache gets munmap'd right before the test
> program maps it's first block. Because the ld.so.cache file is loaded
> early, it gets a low address, then some other things get mapped, then
> ld.so.cache gets unmap'd, then the two test maps happen with the first
> grabbing the address just freed by ld.so.cache and the second being way
> beyond the stuff mapped between.
> It works with no ld.so.cache because it's not there to get unmapped. It
> works with a large ld.so.cache (i.e. >4096 bytes) because that will free
> 2 pages which the 2 mmap's can grab and they'll be contiguous. It does
> not work with a small ld.so.cache (in this case 3102 bytes) because only
> one page gets "held" by the ld.so.cache to be released just in time to
> screw up the test.
> The only buggy code is the test. It should continue to mmap memory
> blocks until it gets two contiguous ones, then check the freeing.
Wow, nice. My understanding of this low level stuff is not 100% but your
theory makes sense and sounds plausible so I'll buy it :-)
> Instead of bombing on this check, it should just do a second anonymous
> mmap on x (or whichever of x and y were mapped first) and recheck for
> contiguousness. DO NOT UNMAP the first x, just let it go cause it'll be
> released on exit.
> If you want to submit the change to the check, just let the gcc guys (or
> whoever) know that you encountered a race condition with a small (less
> than one memory page) ld.so.cache file that caused the check to fail
Like I said, I don't fully understand this stuff. Care to make a patch to
the test case to demonstrate how the test should be done?
Thanks for your help with this.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev