This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: [resend] Re: handling overflow in sbrk.
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Chris Demetriou" <cgd at google dot com>
- Cc: "Carlos O'Donell" <carlos at codesourcery dot com>, libc-help at sourceware dot org
- Date: Thu, 29 May 2008 20:12:09 -0400
- Subject: Re: [resend] Re: handling overflow in sbrk.
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=j4utPDjbwCBZLmwTd0WB4KeZNCSHdglyG3iuE5zutO4=; b=rD0ItJgLYCObDAv7mKhB3KJHs5cRxjxnwK/xQxlT+Sj3uyisjWrxzr4Dr8gdctPPPI4ZxDA6p1OXbm+V3iQpOJvouSTEx0iIB3b2yOzdByiD+GgvYr5b9Iibv89ngHgD6Mw9VLKna+hxQ3arxJJFrWvlZBx3skv7cl1pr2uv+nY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=N/ndIxPRdmSVAbgWp/coopyNVvyRoR0CdEJWrGPIeoe1IpTWUVjxzigriAwA4nov5zOEo9THEBJUGUwD/91osUU34FQDU9n0Oq0I/d69tOqJyVLjBOONsmk1tiw6DUQAp+MB4Je5EZJPK8SRmG0U9HCF+FgN6y2nkbBj/Ikziug=
- References: <2e7be40c0805162353w2cb0c7bco864d82cb6aa9a8fb@mail.gmail.com> <2e7be40c0805162357g61809593j469605765ad6832f@mail.gmail.com> <119aab440805200545r7abd3f7fq77329495f78213a8@mail.gmail.com> <2e7be40c0805202300qe5f6467ve636fa98c33b2041@mail.gmail.com> <20080529051257.4597D30A62@localhost> <483EC5F5.501@codesourcery.com> <2e7be40c0805291047m50b2da0au52120d4f44ef98db@mail.gmail.com>
On Thu, May 29, 2008 at 1:47 PM, Chris Demetriou <cgd@google.com> wrote:
> IMO yes, the kernel _should_ return an error on bad sys_brk, but given
> that it does not (maybe never has) and AFAICT the interface to sys_brk
> is different than brk and is not actually firmly documented... I'm a
> bit concerned about trying to make that change.
This is the real bug.
> re: slow path: well, you're just about to do a syscall which changes
> your page tables... *and* it's a correctness issue. Yes probably
> better to be handled in the kernel with a normal error return ... but
> it's not.
Think about a kernel fix:
1. No added instructions in the userspace fast path.
2. Possibly fixes other C libraries (uclibc?)
3. Overflow check exists in one location handled properly for S_G_U
and S_G_D cases.
In the end I think we need to fix the kernel instead of glibc.
I see that LTP has an sbrk test, but I don't know if it's any good.
You may wish to contribute your testcase to LTP or to the Open POSIX
test suite.
Cheers,
Carlos.