From nobody Tue Jan 6 17:26:33 2026 X-Original-To: dev-commits-src-main@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 4dlykz23PRz6MQ9x; Tue, 06 Jan 2026 17:26:35 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dlykz1HqMz43pP; Tue, 06 Jan 2026 17:26:35 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1767720395; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7pI1XooX5sT16hwyrUKgXfxdb45opRBM8JkZ64QgklY=; b=GSj6H4VSjMwHn66jonfeUjbH9A+etZQ5E4R/6q30njkuxGclOhfadp9/+uAistZXuZF/pl 8z4PluF3Gjj1TqgsTjDuGm/Iu5IwJ4e6Rg6LfnQgUmmjG6MXgTM4k4W+JEIQ7gOGGeiaPD g57iDgc/YTV1QlGLznPVHssl0AsabLoXEJH9sRD1WrxlZhlbJeGWuBDmEZT7lO6HbClCT/ julGJGYLJiY/N3uDN4yPpphRwS7UM/QNtcLM/Zn+HsUyhdGWW1xTRoxJYt8LR/fgXPtMRP 1amq2k/u8Ca0HBuyWDW5xmhXGrHm1ZrMlTW/wFqyKOjP+9B7h5osN6rMyhjJyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1767720395; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7pI1XooX5sT16hwyrUKgXfxdb45opRBM8JkZ64QgklY=; b=F3yV6o5ERBpQnIrwEjJBJSGy/bIUzVypNA0yCy89Jz+Eb3XW2Onr62UgBqY0o0b+nAAcOy y6lRplYNr2UmccX7fxPXh1akcIpJYJyimNRGNF686LYhrg9/3fZGvn86JczLFMc7FdL+H5 QTCSinqGWHFeYo0mjTHdsWNTWcp3+3JDP2w5BfyTTtpYqctbu/xOH9ODCi8BD3sqQNtkK/ Sgo7wJ7P8SwC7T9fCFYp3YE07gkpJUHqQ3YV4dDbumTOpqlS4SQExGK17NcHgKw6G9n2zu D1iQ2q3RYb9nikAUvR7m5aTyqmLguyta+PSXgST2fihL93yGV778uwSyB1KZ2A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1767720395; a=rsa-sha256; cv=none; b=qK9s+8kEGHjBw9mn8hM5IXpKlgISO18e0ZaFU+Ej7wREF/vX5UaAG1h/HLWfdhM+hOTh/o gjCJ6J1jNUzCsz36qxJQFF3i2Xv6lwqpH92QlxCOljwMABWeDiaSm+XLizUMijnPEpCmGv 9wygOIze96DJVYUNI5GHT1ZIAFpw8r/kpa7bogBqDqDMQTequw/YGHphCcgMF18dROuzl6 VODbomDc1dDSRRDRJjDSI8ZxRLn+/kpYIZLQjzvIuLZcT6yaN3fW/xoVqQok4aR4kE7HH8 QnLo9UapkqfLmFGXg01XSiQmVR96XajjnWu7mqR4f21saSvvIZK8fOG/hW9vMQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dlyky6wFhz10dJ; Tue, 06 Jan 2026 17:26:34 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 21A2D187DF; Tue, 06 Jan 2026 18:26:33 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: John Baldwin Cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: 27894e20f140 - main - libgeom: Fix segfault in 32-on-64 case In-Reply-To: (John Baldwin's message of "Tue, 6 Jan 2026 08:37:12 -0600") References: <6958dd10.b4b9.2aebecda@gitrepo.freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 06 Jan 2026 18:26:33 +0100 Message-ID: <86eco2hcty.fsf@ltc.des.dev> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Baldwin writes: > Should we perhaps not use pointers to hold the cookies? This is going to= truncate > in the lib32 case which will probably still work in practice as the low 3= 2 bits of > kernel object addresses are probably unique, but isn't foolproof. Perhap= s the cookie > values should be stored as either kvaddr_t values, or uintmax_t? Unfortunately this is effectively part of the KBI, these values get cross-referenced against pointers in struct devstat returned by kern.devstat.all. I'm working on fixing that as well. Also, the way the code works, the =E2=80=9Ccookies=E2=80=9D get stored in p= ointer members and then later resolved to the actual pointers to the corresponding struct, so no, we can't easily not use pointers. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org