Date: Mon, 12 Feb 2024 09:54:36 +0200 From: Konstantin Belousov <kib@freebsd.org> To: Paul Floyd <paulf2718@gmail.com> Cc: "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org> Subject: Re: Reconstructing mmaps from sysctl KERN_PROC_VMMAP Message-ID: <ZcnOvFhDXMUprcMR@kib.kiev.ua> In-Reply-To: <09ba49cb-5abc-453b-a49b-75434a188554@gmail.com> References: <09ba49cb-5abc-453b-a49b-75434a188554@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZcnOvFhDXMUprcMR>