NetBSD Problem Report #7934

Received: (qmail 11983 invoked from network); 6 Jul 1999 17:27:46 -0000
Message-Id: <19990706172744.9E4D1143@jekyll.piermont.com>
Date: Tue,  6 Jul 1999 13:27:44 -0400 (EDT)
From: perry@piermont.com
Reply-To: perry@piermont.com
To: gnats-bugs@gnats.netbsd.org
Subject: misc. problems remaining in brk/sbrk main page
X-Send-Pr-Version: 3.95

>Number:         7934
>Category:       kern
>Synopsis:       misc. problems remaining in brk/sbrk main page
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 06 10:35:01 +0000 1999
>Closed-Date:    Sat Aug 27 23:14:28 +0000 2016
>Last-Modified:  Sat Aug 27 23:14:28 +0000 2016
>Originator:     Perry E. Metzger
>Release:        NetBSD-current
>Organization:
Perry Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you."
>Environment:

System: NetBSD jekyll.piermont.com 1.4 NetBSD 1.4 (JEKYLL) #0: Mon May 3 09:58:15 EDT 1999 perry@jekyll.piermont.com:/usr/src/sys/arch/i386/compile/JEKYLL i386


>Description:

(Put in "kern" because figuring this out requires kernel source grovelling).

In revamping parts of the brk/sbrk man page, I discovered some
deficiencies that I did not correct.

1) I'm not clear on what happens if you try to sbrk() on a negative
incr that is not an even page.  If you do a negative incr that is not
an even multiple of a page, I'm presuming round down occurs. This has
to be documented -- right now, it isn't.

2) XPG says some interesting things about whether new pages are
guaranteed zeroed. (Straight from XPG:)

	The newly-allocated space is set to 0. However, if the application
	first decrements and then increments the break value, the contents of
	the reallocated space are unspecified.

We say nothing on this topic. It isn't clear what our behavior is. We
must document our behavior.

>How-To-Repeat:

man sbrk, note that not everything is clear

>Fix:
Someone who knows has to help finish the documentation.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->atatat 
Responsible-Changed-By: perry 
Responsible-Changed-When: Mon Mar 31 08:14:28 PST 2003 
Responsible-Changed-Why:  
Andrew understands this stuff very well at this point. I don't... 

From: Andrew Brown <atatat@atatdot.net>
To: perry@piermont.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/7934: misc. problems remaining in brk/sbrk main page
Date: Sun, 6 Apr 2003 16:02:39 -0400

 >In revamping parts of the brk/sbrk man page, I discovered some
 >deficiencies that I did not correct.
 >
 >1) I'm not clear on what happens if you try to sbrk() on a negative
 >incr that is not an even page.  If you do a negative incr that is not
 >an even multiple of a page, I'm presuming round down occurs. This has
 >to be documented -- right now, it isn't.

 sbrk() and brk() both map to sys_obreak() in the kernel.

 >2) XPG says some interesting things about whether new pages are
 >guaranteed zeroed. (Straight from XPG:)
 >
 >        The newly-allocated space is set to 0. However, if the application
 >        first decrements and then increments the break value, the contents of
 >        the reallocated space are unspecified.
 >
 >We say nothing on this topic. It isn't clear what our behavior is. We
 >must document our behavior.

 based on how sys_obreak() works, i would have to assume that if you
 move the break point down and then back up, you'll get fresh zfod
 pages.

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."

From: "Perry E. Metzger" <perry@piermont.com>
To: Andrew Brown <atatat@atatdot.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/7934: misc. problems remaining in brk/sbrk main page
Date: 06 Apr 2003 16:12:32 -0400

 Andrew Brown <atatat@atatdot.net> writes:

 > >In revamping parts of the brk/sbrk man page, I discovered some
 > >deficiencies that I did not correct.
 > >
 > >1) I'm not clear on what happens if you try to sbrk() on a negative
 > >incr that is not an even page.  If you do a negative incr that is not
 > >an even multiple of a page, I'm presuming round down occurs. This has
 > >to be documented -- right now, it isn't.
 > 
 > sbrk() and brk() both map to sys_obreak() in the kernel.

 Not quite. Both turn out to be wrapper functions that do a little bit
 more than you would expect. In particular, they maintain state in
 userland and do rounding of various kinds (or so I remember). 

 In any case, we should document the negative rounding behavior.

 > >2) XPG says some interesting things about whether new pages are
 > >guaranteed zeroed. (Straight from XPG:)
 > >
 > >        The newly-allocated space is set to 0. However, if the application
 > >        first decrements and then increments the break value, the contents of
 > >        the reallocated space are unspecified.
 > >
 > >We say nothing on this topic. It isn't clear what our behavior is. We
 > >must document our behavior.
 > 
 > based on how sys_obreak() works, i would have to assume that if you
 > move the break point down and then back up, you'll get fresh zfod
 > pages.

 Test? In any case, our man page lies on a bunch of counts -- for
 example, it indicates I think that we can set the break to an
 unaligned value, when in fact I believe if you try to do so the
 function will silently round it up.

 -- 
 Perry E. Metzger		perry@piermont.com

From: Andrew Brown <atatat@atatdot.net>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/7934: misc. problems remaining in brk/sbrk main page
Date: Sun, 6 Apr 2003 16:19:37 -0400

 >> >1) I'm not clear on what happens if you try to sbrk() on a negative
 >> >incr that is not an even page.  If you do a negative incr that is not
 >> >an even multiple of a page, I'm presuming round down occurs. This has
 >> >to be documented -- right now, it isn't.
 >> 
 >> sbrk() and brk() both map to sys_obreak() in the kernel.
 >
 >Not quite. Both turn out to be wrapper functions that do a little bit
 >more than you would expect. In particular, they maintain state in
 >userland and do rounding of various kinds (or so I remember). 

 yes, but they ultimately result in calls to sys_obreak() in the
 kernel, so that's where we can find the kernel's side of the behavior.

 the stuff done in userland is a little rotten, but it works.

 >In any case, we should document the negative rounding behavior.

 yes.

 >> based on how sys_obreak() works, i would have to assume that if you
 >> move the break point down and then back up, you'll get fresh zfod
 >> pages.
 >
 >Test? In any case, our man page lies on a bunch of counts -- for
 >example, it indicates I think that we can set the break to an
 >unaligned value, when in fact I believe if you try to do so the
 >function will silently round it up.

 of course, test.  i'm consing up the code now.

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."

From: Andrew Brown <atatat@atatdot.net>
To: perry@piermont.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/7934: misc. problems remaining in brk/sbrk main page
Date: Sun, 6 Apr 2003 17:50:51 -0400

 empiric testing done.

 >1) I'm not clear on what happens if you try to sbrk() on a negative
 >incr that is not an even page.  If you do a negative incr that is not
 >an even multiple of a page, I'm presuming round down occurs. This has
 >to be documented -- right now, it isn't.

 actually, it seems there's some rounding "up" so that you don't
 release part of a page (ie, the page containing your break point is
 fully allocated and you can wander past your "break point" up to the
 page boundary).  until you vacate an entire page via sbrk() the page
 isn't actually "released" from the vm system (vm map entries and amaps
 are adjusted accordingly).

 that means that this loop:

 	for (i = 0; i < PAGE_SIZE; i++)
 		p = sbrk(-1);

 will continually adjust the "last" break point (as recorded by the
 stub in libc) and tell the kernel to move the break point (as brk()
 does), but the kernel will do no work until an entire page is able to
 be released.

 >2) XPG says some interesting things about whether new pages are
 >guaranteed zeroed. (Straight from XPG:)
 >
 >        The newly-allocated space is set to 0. However, if the application
 >        first decrements and then increments the break value, the contents of
 >        the reallocated space are unspecified.
 >
 >We say nothing on this topic. It isn't clear what our behavior is. We
 >must document our behavior.

 new pages are zeroed.  if the "application first decrements and then
 increments the break value by a non-page-aligned amount", then the
 non-page piece comes with no warranty as to its contents (in point of
 fact, it will contain the same stuff that was there before).

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."
Responsible-Changed-From-To: atatat->kern-bug-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sun, 21 Mar 2010 15:48:24 +0000
Responsible-Changed-Why:
Back to role account, atatat lost his commit bit.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/7934: misc. problems remaining in brk/sbrk main page
Date: Sat, 27 Aug 2016 23:06:56 +0000

 Module Name:	src
 Committed By:	dholland
 Date:		Sat Aug 27 23:06:01 UTC 2016

 Modified Files:
 	src/lib/libc/sys: brk.2

 Log Message:
 Rework pursuant to PR 7934: be more clear about the page granularity
 behavior and when new memory is zeroed.

 Also, strengthen the warning about mixing with calls to malloc (which
 is not a bug) and mention that the portable way to fetch the initial
 break is to call sbrk(0). There are implementations in the wild where
 using _end as the initial break doesn't work.


 To generate a diff of this commit:
 cvs rdiff -u -r1.32 -r1.33 src/lib/libc/sys/brk.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 27 Aug 2016 23:14:28 +0000
State-Changed-Why:
Fixed.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.