From owner-freebsd-hackers@freebsd.org Thu Oct 15 18:25:52 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AB1B94448E0 for ; Thu, 15 Oct 2020 18:25:52 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CByQR47C2z3ZL5 for ; Thu, 15 Oct 2020 18:25:50 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from garrigue.home ([90.112.35.12]) by mwinf5d44 with ME id gJRo230100FipBu03JRoaw; Thu, 15 Oct 2020 20:25:48 +0200 X-ME-Helo: garrigue.home X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Thu, 15 Oct 2020 20:25:48 +0200 X-ME-IP: 90.112.35.12 From: Paul Floyd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11 Date: Thu, 15 Oct 2020 20:25:46 +0200 References: To: FreeBSD Hackers In-Reply-To: Message-Id: <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4CByQR47C2z3ZL5 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.131) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [2.25 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[wanadoo.fr]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_POSSIBLE(0.00)[80.12.242.131:from]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.19)[0.187]; NEURAL_SPAM_LONG(0.73)[0.730]; RCVD_IN_DNSWL_NONE(0.00)[80.12.242.131:from]; NEURAL_HAM_SHORT(-0.06)[-0.063]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 18:25:52 -0000 > On 15 Oct 2020, at 16:54, karnajit wangkhem = wrote: >=20 > Hi freebsd team, >=20 > While checking on a valgrind issue, I encountered the following = mapping of > a simple test program on a freebsd-12. ;-) > [Stable 11] >=20 > # procstat -v 85507 >=20 > PID START END PRT RES PRES REF SHD FLAG = TP > PATH >=20 > >=20 > 85507 0x800820000 0x800822000 rw- 1 1 1 0 ---- = df > 85507 0x7ffffffdf000 0x7ffffffff000 rw- 1 1 1 0 ---D = df > 85507 0x7ffffffff000 0x800000000000 r-x 1 1 104 0 ---- = ph >=20 > There is an extra ~511MB reserved mmap area starting at 0x7fffdffff000 = in > stable 12. Could you please give me an insight of what this is for and = is > it ok for a userspace program to modify this mapping? >=20 > The reason is that our applications reserve some fixed memory that > crosses/modify the above region. As this mapping was not called by the > client program, valgrind had taken control of it. So, I have to decide > whether to give the control to the client and allow = modifications(mprotect, > unmap, mmap, etc) on this memory segment or logically(not mandatorily) = a > client program should be allowed to modify this area? This extra memory is the MAP_GUARD, which was introduced in FreeBSD 10.4 and changed to be a large zone in FreeBSD 11.1. If I understand correctly, it=E2=80=99s a kind of super-sized guard page = for the stack. There are more details in the mmap man page. If you run Valgrind with the -d option it will print a table of the = memory mapping (Prefixed with =E2=80=98aspacem=E2=80=99 for Address Space Manager). If = you want to see some more Valgrind details, see aspacemgr-linux.c from line 1646 (despite the = name it's used by all supported platforms). A+ Paul