From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DE7CC3ABBE for ; Thu, 8 May 2025 14:24:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CDD26B000A; Thu, 8 May 2025 10:24:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27C3F6B0082; Thu, 8 May 2025 10:24:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16CFF6B0089; Thu, 8 May 2025 10:24:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EC73A6B000A for ; Thu, 8 May 2025 10:24:07 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4B78EC067B for ; Thu, 8 May 2025 14:24:09 +0000 (UTC) X-FDA: 83419960218.30.D0AE558 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf17.hostedemail.com (Postfix) with ESMTP id A641840007 for ; Thu, 8 May 2025 14:24:07 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=swGD1fVr; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of broonie@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746714247; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hs7kf43kgJgGhkPDb3YEryLJjl7hpWdhZ2J0A5gnOaY=; b=LL9BsIi+C310LKTcbBMdMGCzQinPyiM5Zi0jEthotAeL06vxqSFidsPAOA5A1p3zzPfOru 7Z5RFvtSLOmcsJb4B6ll4/Mj9Sd5OIzZe9W4T4HY3eyZ1LlAPE5f/9JI7sdLYbelvvWun7 haY51eKKhYzgj+ltVvD2kfeSpryZIDQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=swGD1fVr; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of broonie@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746714247; a=rsa-sha256; cv=none; b=mzRNGtNeEWQFStmYrsnnHDQWbJiAOxgY7pyO/o1nLHgFT8Sncg6U/QvSm71z1k+XXbwjEg QacHggkInyXsUrJdUvtRfQXP9d7kTGrHd5b1JCwdc1qRoJSlfKxYuzMgVT3m3MAvrekbIO ihNG3U3ed4nEt/uQCF/JpRFPMns76Io= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id BCF8E629F2; Thu, 8 May 2025 14:24:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AB5FC4CEED; Thu, 8 May 2025 14:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746714246; bh=hs7kf43kgJgGhkPDb3YEryLJjl7hpWdhZ2J0A5gnOaY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=swGD1fVrjIOA88oPXwaBBDwCwyezYItH+173qKxwxQN7PYeC1Bo85BIJILt+XZ5iI 4vF2ZyyxaYbo9ccHLYQUzEUc0NhVCVIKGl0hm2X2HBxNCHddagIFTUPCwvPx1RZ4nH Sayc58uHTc8X60Aj2ikJZoCzEbKH34rGf0xYQui6C/g74RakbwA7D63xrk2NgMX9Lw 9ZbJc8fOW/pPGKb4jIFsnoqaL2exByWNxjsWWsWdlFDaqB6cuA0G87g1wia27Crcoi gSM+pvZJ04WJj8m5sTCnwLAvJdgEZ2Te1CSdn06aptn24kBi0q3zvqlqqFxzwHjWKK 7503fPkZZ7ohw== Date: Thu, 8 May 2025 23:24:03 +0900 From: Mark Brown To: Florent Revest Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, akpm@linux-foundation.org, thiago.bauermann@linaro.org, jackmanb@google.com Subject: Re: [PATCH 0/4] mm: Avoid sharing high VMA flag bits Message-ID: References: <20250506095224.176085-1-revest@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3G+aMXgLa2YFDWGN" Content-Disposition: inline In-Reply-To: X-Cookie: Well begun is half done. X-Stat-Signature: 4ou778p91azapda7fjzpq8my6r8ea8kr X-Rspamd-Queue-Id: A641840007 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1746714247-742449 X-HE-Meta: U2FsdGVkX1/XhFv5OgfGrqiVB4A4Xxoc4/cTClzCjKnuFdU3fVuowA6EtAFAoi2EyijlXopMD2LAwOH7R0ZY/sS3nDIGVwdT7BYK8opvYP1bY41ZbVcVs531zerOf8NB6HRR5aPURWjHrsONGg/L9UibOSAJ15K0PU+d8sviILtITrVGCz2FWA3iK/hpb2jtG6LNuANwaG6FshjWgIhTJj+4BiU00Fk7UuteB2p6Qeg4H1gpytpaaZjFhd8M04A73Wfwa8jF4uUwP7x0APC6QY0pFf5Vk96ZRj75+juRoius78OIKiznqWNOIE30ztfFzUBdI5HpIZSGzTWoeFTt/zsNR6TWJ+b1yasKdfijpPQDYsflZKz0lMrkDlI82d+8JdlJCHr5zTOELMAGvokWJ7CBkdekLjpo7MS6a7EcEKUOr970HmpuKNKaVYm+3z3EoD3KzeT949sRHQS8W1HFfCOiPPIu0lgNvqQB+wPT2VOV6pXQP19Fipq+SIuI+A86zipXSlP+/iFqAt2gn/VoWfEs8c46vxIuS4MFnrEXfDX7nZVzmf6leZyKHPLymDzH13v19BSFC8L9zIBIvQD7zvaKl5muPCoNFuiqYJfj5NaGguqeetQB6Ejp7FGXNOI+9fOzmjdSpRuIm89g3mibD/K3kIntNKfVVX113rE8b4KkRh7mS//0czgP9aKjaZ7SfALySpUal8eWeXJQestrZo4xCE2jGAQEyOfIbrE6FatUvAJbwdsbw4E8QhuExfcWM42KWaopkJcfSPYJszbuXa+/qu8NBmlRZC/ZQ2tW7RNwbFmfnqXZMh6y5fKcWdOfaYwK3RkUwLX6DCw7f540SrMrOU26sINye5BMZYJ8ZUsnqDql97eZk5gAXABVp9lwdS/KolnCRc215lMNL78jZrYsyfVwrE7+uKaznB2T7x2ZYcge+xSwGWI4G3ZxdyoxB5ABgYf0xYLmfGJs7LH MWSpXB8e gDCCpSXajZKaQ2A24LHgQgUKcLA52PjoGIZXTqPMNJjHFeEHGREE2AYt/+loejzIoI66m61iKmbrTKdHacTAf98fLY+nDZtfDqPBoZf0oFoeT4RYu7uHh1czvXLWu/suZeLQ1EqpSOAx+K3ZnkLAboFmPiQv63Z/XyDKQm4KrNDhDQncjszmdN61z1QgEqwqgveYqZ3Lf/fKh0CSs2rWd+tbk/nOCryPzAu+spQR/2b9JWYH5GsuGwCQY9smTxm4xR/yRe7hcMO83UUXmaAzOf2/SqlTewQpCVIHFqMXwUnJJrosVe6hQOdxI2A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --3G+aMXgLa2YFDWGN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 07, 2025 at 03:09:50PM +0200, Florent Revest wrote: > I just want to make sure I fully understand the point you're making > here, it seems that you are suggesting that 7677f7fd8be7 > ("userfaultfd: add minor fault registration mode") and ae80e1629aea > ("mm: Define VM_SHADOW_STACK for arm64 when we support GCS") came in > from two different trees and independently chose to use the same bit > around the ~same time, is that right ? And that a conflict would have > appeared when they'd eventually get merged into a shared tree ? > I don't think that's what happened in this specific case though. As > far as I can tell, the former was merged in 2021 and the latter was > merged in late 2024. Also, since the hunks got added in very different Yes, indeed - I wrote that initial reply before I saw the actual change. I wasn't expecting a conflict but rather that what'd happened was that the bit was allocated independently in two different trees and then due to the way the allocations are scattered everywhere no conflict had flagged the issue. > parts of include/linux/mm.h, I don't think they caused a noticeable > merge conflict. But I agree it would probably be preferable if these > cases would cause some sort of noticeable merge conflict in the future Putting all the flags somewhere in the vicinity of each other would make the whole thing much more robust, or having some build assert for uniqueness. > I'll quickly respin this series to address my typos on patch 4 (sigh) > and add your Reviewed-by tag but just to be clear, my refactorings in > patches 2/3/4 currently focus on using VM_HIGH_ARCH macros > consistently, to make it a bit more obvious to a reader if two > features choose the same bit. But maybe what we would really need > instead is a more obvious way for these bits to be mutually exclusive > and to cause merge conflicts if they get added through independent > trees ? For example, my colleague Brendan Jackman suggested using an > enum for VMA flags bit offsets but I'm not sure what the sentiment is > around that. I think we need something here, although it wasn't what actually happened here the potential for the scenario I mentioned above to occur remains. --3G+aMXgLa2YFDWGN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmgcvoAACgkQJNaLcl1U h9BY0gf/dFflr/U3vGpugb7MR90AC1d+1+r2r6ToKtp08WD7Q+Dqe0+tiWFwAwXm 5CbrPisJAZxEGWoKrTS2QI/q4fwBcKKaMZj897g7XqB3703bieY69nkScl1ibZkj TxffPqbETz3wMdIxmhwAoryJqUFza4Vr/DjqG7gHbHRRgOb/rZebckwXnym6xR8A 8hP4fzSkF9Soti1v1djWf0Ni/R+B4JhNalBPWdoF3gbagH+Ev82IF/RVhL6SCeLe s2HhMNN1iYXvDsCXpkL7Gu95jFhFtcKSVfxqzBRXLG1HOT9o64xna4mze3AitMIl +XsRPhevIWCvICeM0z8SnfscVzgb9A== =+kmo -----END PGP SIGNATURE----- --3G+aMXgLa2YFDWGN--