This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [resend] Re: handling overflow in sbrk.


Chris Demetriou wrote:
I figured this wasn't reasonably testable on 64-bit systems (since I
know none that support remotely close to 64 VA bits -- i.e., the
kernel should ENOMEM before you get close enough to *try* to wrap
around), so punted there.  It might not be harmful to allow the test
to run normally on 64-bit, but while I'm comfortable w/ trying to
allocate 4GB of virtual memory, I'm less comfortable about filling a
64-bit process's address space.  8-)

What does the test do when you run make -k check on an native 64-bit system?


2008-05-20 Chris Demetriou <cgd@google.com>

        * misc/sbrk.c (__sbrk): If incrementing __curbrk by the requested
        amount would cause it to overflow, return an error (ENOMEM).
        * misc/tst-sbrk1.c: New test.
        * misc/Makefile (tests): Add new test.


I saw you posted this again to libc-alpha, I hope you put on asbestos underwear.


The patch makes the common case in sbrk slower, and the kernel (2.6.25) already has support checking this overflow?

~~~ mm/mmap.c (do_brk) ~~~
       if ((addr + len) > TASK_SIZE || (addr + len) < addr)
                return -EINVAL;
~~~

Can you identify which kernels are broken?

Cheers,
Carlos.
--
Carlos O'Donell
CodeSourcery
carlos@codesourcery.com
(650) 331-3385 x716


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]