From nobody Mon Feb 12 07:21:23 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 4TYG9270MXz59hr0 for ; Mon, 12 Feb 2024 07:21:26 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TYG922X8dz41MB for ; Mon, 12 Feb 2024 07:21:26 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=hsmilrS6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=paulf2718@gmail.com Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-33b86bc8974so117902f8f.2 for ; Sun, 11 Feb 2024 23:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707722485; x=1708327285; darn=freebsd.org; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=gQvstCDu3LQyK1/ARgpMF1FnTrJnaorRE93LWiJuNeE=; b=hsmilrS6wUKNqRf3OeYVIBqq/NjiAGGBOGsYVgFdYiRqT+6pA8J/UCwqyhpszKk0Qi anu1uNP8SsR/bM45WIOupJd33HyVLnkk7cmlL6J77fh2vFpAs5k8iE0L3baX6zMFYbks C53eEFPx8rI5yvky5x4FCxbx4cKeqp3aTjfaqx0rXxmS35XyIIGd8A3PSYD+2wqYxeV1 xL1u6YYB9u2/2Li8on0Hlci5ymTIeCLksDs3haOB/CH7SoXabPsXqBHPS7JrlYu4Py4e 0Grtl9uyfXJ6J/DrEsUiWjvOkspe9TJzgLHr3p7wZR7FxHqClmKp2jTURqZBBbrHnzjj yoTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707722485; x=1708327285; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=gQvstCDu3LQyK1/ARgpMF1FnTrJnaorRE93LWiJuNeE=; b=fXbUmtq9tPGleef76WkZ95aNgyQJwgqgH2BbbMya3e0E+lxzNZ3k8+UFiJMLPE/HPq ocF0fMxi2W1IikS4zGRc7BzHJhlDLSM3KW5fRuUC0ywOVxbdFFzUVsv/ZJtHfEeyP4dC NzPmpBsPnVnAMJYEdO1qEXQ6j7fcivtwWdCBpXsr9AOqplTgvhBdQX8wgEzGgLL07ruo g895/69jgTk8/wa8rNL2vm94+HJ1lPpZcVCwJqdDWs8LW3oEbRTBWvrVaAq0tXV2BwE6 nXAcRAZOf7AI5URLtvHOqElsxGnY3a/RCo1TfBVRdx5AvvulWmd2Xb8Dn9nWtd9/dcf9 b+2A== X-Gm-Message-State: AOJu0YxI+rValaI7DKrJ0TKDtOCy4b9vlB+6JkIYyQyuqkykjvYrzhDJ 6m3dRI53AOoeBdYP6/0/P/4ml1E/UIWq1B4KkV3C/Wvpf6sEJ1R5tjnLNOD4 X-Google-Smtp-Source: AGHT+IEiITllRY9iE2ZMdbfVtJCzam75rXRT7ywRCqRJL6T2JotK5+dTCEUARAk+OZOyaHpV3d2Biw== X-Received: by 2002:a5d:554c:0:b0:33b:713e:b36b with SMTP id g12-20020a5d554c000000b0033b713eb36bmr3563253wrw.6.1707722484801; Sun, 11 Feb 2024 23:21:24 -0800 (PST) Received: from ?IPV6:2a01:cb15:8010:2f00:1aa9:5ff:fe16:2efb? ([2a01:cb15:8010:2f00:1aa9:5ff:fe16:2efb]) by smtp.gmail.com with ESMTPSA id p11-20020a5d68cb000000b0033b66c2d61esm5901642wrw.48.2024.02.11.23.21.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Feb 2024 23:21:24 -0800 (PST) Message-ID: <09ba49cb-5abc-453b-a49b-75434a188554@gmail.com> Date: Mon, 12 Feb 2024 08:21:23 +0100 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 User-Agent: Mozilla Thunderbird To: "freebsd-hackers@FreeBSD.org" Content-Language: en-US From: Paul Floyd Subject: Reconstructing mmaps from sysctl KERN_PROC_VMMAP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from] X-Rspamd-Queue-Id: 4TYG922X8dz41MB 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. A+ Paul