From nobody Mon Feb 12 07:54:36 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TYGvS34LJz59lSm for ; Mon, 12 Feb 2024 07:54:44 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TYGvR6j7Hz44mS for ; Mon, 12 Feb 2024 07:54:43 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 41C7saA3036651; Mon, 12 Feb 2024 09:54:39 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 41C7saA3036651 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 41C7saj6036650; Mon, 12 Feb 2024 09:54:36 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 12 Feb 2024 09:54:36 +0200 From: Konstantin Belousov To: Paul Floyd Cc: "freebsd-hackers@FreeBSD.org" Subject: Re: Reconstructing mmaps from sysctl KERN_PROC_VMMAP Message-ID: References: <09ba49cb-5abc-453b-a49b-75434a188554@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09ba49cb-5abc-453b-a49b-75434a188554@gmail.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4TYGvR6j7Hz44mS X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Mon, Feb 12, 2024 at 08:21:23AM +0100, Paul Floyd wrote: > Hi > > I'm having difficulty with one of the Valgrind developer mode options, > "--sanity-level=3". With this option every time that there is a change to > things that are memory mapped Valgrind will do a check that its internal > memory map model is consistent with what the OS reports. It gets the OS > mappings via sysctl KERN_PROC_VMMAP. > > This breaks down for mappings done with MAP_STACK (which happens each time a > thread is created). For mmap calls like this there will initially be two > mappings, a 128k stack mapping and a 'length-128k' guard mapping. This first > guard page is really the stack growth area, and the size of the stack growth > chunks is controlled by sysctl KERN_SGROWSIZ. As the stack grows more > sgrowsiz mappings get created, eating up the stack growth guard mapping. > > Is there any way to work out that the split growth guard and sgrowsiz stack > mappings call come from a single mmap MAP_STACK? Indeed, is the kernel > capable of telling that these mappings came from the same mmap? > > My only idea at the moment is to modify the checks so that if Valgrind sees > an anon RW mapping in its model that matches a zero prot guard plus some > number of sgrowsiz RW stack mappings that have the same size as the singkle > anon RW mapping then it is probably OK. And if the size is THR_STACK_DEFAULT > it's even more likely to be OK. Of course, users could change the thread > stacksize and I suppose that if you try hard enough you can manually arrive > at a mapping with multiple mmap calls that looks like a single mmap > MAP_STACK. If you see a guard entry which is followed by a swap map entry with KVME_FLAG_GROWS_DOWN flag, then this is definitely the stack pair.