NetBSD Problem Report #52842

From www@NetBSD.org  Tue Dec 19 23:12:51 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 6BE8B7A167
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 19 Dec 2017 23:12:51 +0000 (UTC)
Message-Id: <20171219231250.AF0407A1E6@mollari.NetBSD.org>
Date: Tue, 19 Dec 2017 23:12:50 +0000 (UTC)
From: n54@gmx.com
Reply-To: n54@gmx.com
To: gnats-bugs@NetBSD.org
Subject: Obsolete brk(2)/sbrk(2)
X-Send-Pr-Version: www-1.0

>Number:         52842
>Category:       lib
>Synopsis:       Obsolete brk(2)/sbrk(2)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 19 23:15:00 +0000 2017
>Last-Modified:  Sat Jan 06 21:15:00 +0000 2018
>Originator:     Kamil Rytarowski
>Release:        NetBSD 8.99.9 amd64
>Organization:
TNF
>Environment:
NetBSD chieftec 8.99.9 NetBSD 8.99.9 (GENERIC) #2: Sun Dec 10 06:11:20 CET 2017  root@chieftec:/public/netbsd-root/sys/arch/amd64/compile/GENERIC amd64
>Description:
The sbrk(2) and brk(2) calls have been obsoleted by mmap(2).

sbrk(2) users:
 - gpl2/libmalloc
 - LLVM (Process::GetMallocUsage())
 - am-utils (debug)
 - unbound (debug)
 - binutils / nm (debug)
 - binutils / gas (debug)
 - binutils / ld (debug)
 - binutils / libiberty (debug)
 - gcc / libiberty (debug)
 - gdb
 - lib/libbsdmalloc
 - lib/libc/gmon/gmon.c
 - lib/libc/stdlib/jemalloc.c (USE_BRK)
 - lib/libc/stdlib/malloc.c
 - tests/lib/libc/gen/t_dir.c (hack for hand-made leak-detector)
 - tests/lib/libc/sys/t_mlock.c (sbrk(0))

brk(2) users:
 - lib/libc/stdlib/malloc.c


sbrk(2) is mostly used for debugging purposes, to find out the end of
heap ("sbrk(0)").

libc/gmon should be switched away from sbrk(2).

There is a need for improved debugging facilities to introspect the
jemalloc(3) internals, something comparable to mallinfo from <malloc.h>
in GNU.
>How-To-Repeat:
grep -r brk /usr/src
>Fix:
N/A

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Wed, 20 Dec 2017 01:12:12 +0000

  - LLVM (Process::GetMallocUsage())
 jemalloc can provide similar stats:
 http://jemalloc.net/mailman/jemalloc-discuss/2015-October/001196.html

  - lib/libbsdmalloc
  - gpl2/libmalloc
  - lib/libc/stdlib/malloc.c

 How many allocators do we need?

From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Wed, 20 Dec 2017 03:50:31 +0100

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --FjaT16Mjs0lhjS1rQXc9pUARgapwISEGL
 Content-Type: multipart/mixed; boundary="WHm6uJ7LXsBr6fabgjaCFdJHC4dnFJEJs";
  protected-headers="v1"
 From: Kamil Rytarowski <n54@gmx.com>
 To: gnats-bugs@NetBSD.org
 Message-ID: <8677cb37-523e-c973-2aee-68883838fa91@gmx.com>
 Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
 References: <pr-lib-52842@gnats.netbsd.org>
  <20171219231250.AF0407A1E6@mollari.NetBSD.org>
  <20171220011501.9EED17A1E6@mollari.NetBSD.org>
 In-Reply-To: <20171220011501.9EED17A1E6@mollari.NetBSD.org>

 --WHm6uJ7LXsBr6fabgjaCFdJHC4dnFJEJs
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable

 On 20.12.2017 02:15, coypu@sdf.org wrote:
 > The following reply was made to PR lib/52842; it has been noted by GNAT=
 S.
 >=20
 > From: coypu@sdf.org
 > To: gnats-bugs@NetBSD.org
 > Cc:=20
 > Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
 > Date: Wed, 20 Dec 2017 01:12:12 +0000
 >=20
 >   - LLVM (Process::GetMallocUsage())
 >  jemalloc can provide similar stats:
 >  http://jemalloc.net/mailman/jemalloc-discuss/2015-October/001196.html
 > =20

 Ah, good - maybe it will be good enough.

 >   - lib/libbsdmalloc
 >   - gpl2/libmalloc
 >   - lib/libc/stdlib/malloc.c
 > =20
 >  How many allocators do we need?
 > =20
 >=20

 At least, I don't think we need a single one that uses obsolete
 interfaces that are pending for removal.


 --WHm6uJ7LXsBr6fabgjaCFdJHC4dnFJEJs--

 --FjaT16Mjs0lhjS1rQXc9pUARgapwISEGL
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"

 -----BEGIN PGP SIGNATURE-----

 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlo5z/cMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZsprMQAKOcRNNhBx+ETrZzvohbl0jbadEPmeiwO/b+e1Di
 5P8gErtRyPaOVM5GSbgqIepFS32z9K7BqATyw0z5P5imfI4jlPmaaE4AURfdD2zY
 7lf62cp/P3dL1rhG2S9we5W936WPguN3QLVoFXeMQdAJ2fKsVoyXFnW8C/e6XW7x
 kr3aYkvHP0swGqgrYJHg1LpNCq0ACydZWPosNx23Z6Ik1f2uaFubMb0IzHwZUh85
 HyTOkPMEJcx7fJ6EkZIeU3TrreWKnatfALwlXsKGBubggsqkKiyGc2PCBfYNewpv
 /4aZ32jvsU+Vh2sxJfeneVvS5EE66C0Q2cTxu8bAHduolIUAiD+vUCd61QBE5Gvw
 94KzcAd7qi8kqrQrd1Ry+XfjfDbyl5EKxBGaQeO9BavyGdy9Yq290wCYDO7OorLC
 dvVU0Era+llJIoR8U+1g8HHI4OOMZOjpk6pUhruGR8n5v2cZw+NX/HclQRg2sxnF
 ri1ufV+rvhgCynH/oO2WYATNNVueMnZq8T61+Qor+Tk6jb48Fv+MOA3OECHhVoNs
 N2FOsmo62vttdWdsrE+S/jpMjcrzeN/XobaHHihQjMxgj6SMb1bTJvPtPTsg6ZIR
 zLwrzIi2VHTtedHT5MUkkn23zjKREb5hqm15E05rAMaNZCKjrZd9SLfzlUbnnaWk
 aKAn
 =9orN
 -----END PGP SIGNATURE-----

 --FjaT16Mjs0lhjS1rQXc9pUARgapwISEGL--

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Wed, 20 Dec 2017 11:08:52 +0700

     Date:        Wed, 20 Dec 2017 01:15:01 +0000 (UTC)
     From:        coypu@sdf.org
     Message-ID:  <20171220011501.9EED17A1E6@mollari.NetBSD.org>

   |  How many allocators do we need?

 We only need one, but they tend to have different characteristics, and
 different ones can be suited better for different applications.

 As long as they all provide the same basic API, so they are technically
 interchangeable, what does it really matter?

 To the subject of this message, I personally would prefer brk(2) to
 remain (forever).   There's no really good reason to delete it, its
 effects can be faked, at some cost, by simply including

 	char bigarray[1<<30];

 or something similar in the sources (the cost being the need to preallocate
 space that may never up never being needed - using brk() means that the BSS
 will be made large only on demand.)

 I have no problem with use of mmap() to allocate memory, if that someone
 seems useful - though to me it seems like a rather heavyweight interface,
 for what can be a very simple request.

 No problem deleting ssys() (never knew such a thing was even planned), and
 as far as I can recall, way back to the very early days, sbrk() was always
 really sbrk(3) and used brk(2) from libc to operate, it never was and never
 needed to be a sys call (sure, making it one could save some libc ugliness,
 but not enough to worry about.)

 I vaguely remember some purpose (at least intended) for vadvise() but I
 don't remember it ever being implemented, so I have no problem with that
 one going away either.

 That is, all that was removed in the past couple of days was fine, but
 at least in this area, it should stop here, leave brk() for the benefit of
 (perhaps old and simple) malloc() implementations that some application
 might prefer to use.

 kre

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Sat, 06 Jan 2018 07:06:50 +1100

 why?

 there's no good reason to remove this useful functionality.
 we'll need to keep it for backwards compat anyway.  i'm not
 even sure you can do it without significantly restructuring
 how exec works.

 i don't see any real benefit.


 .mrg.

From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Fri, 5 Jan 2018 23:42:40 +0100

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --OjrcGKq0mlIkbubkUmpttjEl3sNhHbu5x
 Content-Type: multipart/mixed; boundary="biQ3uC0Mb74WFxhxnlmiLXxEO9WBjAF66";
  protected-headers="v1"
 From: Kamil Rytarowski <n54@gmx.com>
 To: gnats-bugs@NetBSD.org
 Message-ID: <ba41cfa0-beb0-218a-7788-6a2e2e663bb0@gmx.com>
 Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
 References: <pr-lib-52842@gnats.netbsd.org>
  <20171219231250.AF0407A1E6@mollari.NetBSD.org>
  <20180105201000.B7F277A1CF@mollari.NetBSD.org>
 In-Reply-To: <20180105201000.B7F277A1CF@mollari.NetBSD.org>

 --biQ3uC0Mb74WFxhxnlmiLXxEO9WBjAF66
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable

 On 05.01.2018 21:10, matthew green wrote:
 > The following reply was made to PR lib/52842; it has been noted by GNAT=
 S.
 >=20
 > From: matthew green <mrg@eterna.com.au>
 > To: gnats-bugs@NetBSD.org
 > Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
 >     netbsd-bugs@netbsd.org
 > Subject: re: lib/52842: Obsolete brk(2)/sbrk(2)
 > Date: Sat, 06 Jan 2018 07:06:50 +1100
 >=20
 >  why?
 > =20
 >  there's no good reason to remove this useful functionality.
 >  we'll need to keep it for backwards compat anyway.  i'm not
 >  even sure you can do it without significantly restructuring
 >  how exec works.
 > =20
 >  i don't see any real benefit.
 > =20
 > =20
 >  .mrg.
 > =20
 >=20

 I will try to come with a rationale within a few days, first I need to
 prepare and perform some tests.

 The kernel part should stay as it is - for compatibility reasons with
 existing applications.


 --biQ3uC0Mb74WFxhxnlmiLXxEO9WBjAF66--

 --OjrcGKq0mlIkbubkUmpttjEl3sNhHbu5x
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"

 -----BEGIN PGP SIGNATURE-----

 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlpP/2AMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZsPa4QAL/APYNMU2jqA13lcJTeBf145ZFSmxhTP4kQekEu
 v32rvJYjnktyc5bx07mtBPOS0LAGoosUueDtd2IC/7Q7NynR+WsAAs+QMdnQg/B6
 P9FNbZ3BwFuZuGhCcPj2QhVh8ZjR5xJ/ATaGxHxiUI0Yr5ssZqnoIUMG/uhcqNgX
 NSgFiaXezZ1f8hEWUDMyozs9ixjQwykhRlNZxCnkQM2S/PUxBt4dSYEnjjNm8pVG
 W76OHPMnFuHIS5pG+Wuv81pgIJWaeF2ZSNkz25kmwABYuuN24PJY+6ymMrCEXHAo
 2FFbI7PnUcR3tedI+M9DFEfchePG4BCtQj1msLtMPVDz6UKEWZsc+zUUtHOEA8L8
 Ob2nB3dhounGtKysija7SwIG6bX6DjsCx/IpmpvCJlu6q2tyyUp4b/HQ3s9rnEKs
 7A3YGnH0456V/xxkS6dChqaLSlXCSv5BRPTMy1UHHiHQTOYxnSg/48f9i49A4n6j
 2SsHYcuj++DtgLCC6sJir+4BeWQ6lyTf7O0fYSeeQCA8DjhbjmzoCbrzN3dB+Jo/
 Ygqv9ctJdT0wIZrHre/MO7L0DTMHBDo0ROAagYjP0wjEjiHHXpcsWE7fWSM62u3f
 KDrm5AwKIt5QF3WBeWLqtS3eGX8Pkvm+x3t1XAIc4e7Ja89mS1noBK086bQYIRi0
 4foY
 =+pPu
 -----END PGP SIGNATURE-----

 --OjrcGKq0mlIkbubkUmpttjEl3sNhHbu5x--

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, n54@gmx.com
Subject: Re: lib/52842: Obsolete brk(2)/sbrk(2)
Date: Sat, 6 Jan 2018 22:13:49 +0100

 On Fri, Jan 05, 2018 at 08:10:00PM +0000, matthew green wrote:
 >  there's no good reason to remove this useful functionality.

 They are pretty fundamentally Russian Roulette for binaries using ASLR.

 Joerg

Home	PR Database Search