Who understands this code?

Greg Schafer 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 
> incorrectly.

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 mailing list