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 65F97C3ABC0 for ; Wed, 7 May 2025 13:10:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32A5F6B0085; Wed, 7 May 2025 09:10:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DAD66B0088; Wed, 7 May 2025 09:10:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1579A6B008C; Wed, 7 May 2025 09:10:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EE7706B0085 for ; Wed, 7 May 2025 09:10:03 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 55C92140128 for ; Wed, 7 May 2025 13:10:05 +0000 (UTC) X-FDA: 83416144770.17.6397FC2 Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) by imf07.hostedemail.com (Postfix) with ESMTP id 7A76240015 for ; Wed, 7 May 2025 13:10:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lnaNEoqL; spf=pass (imf07.hostedemail.com: domain of revest@chromium.org designates 209.85.161.50 as permitted sender) smtp.mailfrom=revest@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746623403; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KuFq/zeYni8KgGdHJD2LlQeGitZ5AOvXBhl3se89MLw=; b=ndpXdmnvh96nmSyAu3UWDyZCBypaXnAZDCc73Ylb0SAIVCMpJyd6MqeOKRsmJE9CvQcj2g uHXJvPII2/mKcVamq08FqOP3Q78vlz3DcUNUA9RHZaIOnOJ40DjgQmLxBgDeqCEowcP2Yb 09s3adxxxRVD3hzyGKfd3eyVL5uEu8o= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lnaNEoqL; spf=pass (imf07.hostedemail.com: domain of revest@chromium.org designates 209.85.161.50 as permitted sender) smtp.mailfrom=revest@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746623403; a=rsa-sha256; cv=none; b=hxlo7qjvIH9cxq6cmWektuMTim3Z3rvNnpHkwsZDHuw8cMXgNBE+SVqqvHl8y5xOIADBbE R1fK/0t49odmf2eyeBIeAemXM0tsyJet7RF8n6mm1HD/HdoLRj8olBTlwoGGAZFklQexjo l+AHhoM9nIUlAMMrH6cU41k6jXI0z3Q= Received: by mail-oo1-f50.google.com with SMTP id 006d021491bc7-607d5b7fbeaso845873eaf.3 for ; Wed, 07 May 2025 06:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1746623402; x=1747228202; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KuFq/zeYni8KgGdHJD2LlQeGitZ5AOvXBhl3se89MLw=; b=lnaNEoqLvXuLeCNMw0PFybcQzcyqEFlyZE+Po6zATEy2SDuR5YPILAO6AcdQB302Wp gQ00LIpW/r5odaRSrfVSfcJxGz7/OmVwVlBh5UutJDy/pFjGBmaVzqXl5EHk9dHIugme 0HXgOrh2Ag0zUPH8EnlcmC/kzRxZlFg4PWKPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746623402; x=1747228202; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KuFq/zeYni8KgGdHJD2LlQeGitZ5AOvXBhl3se89MLw=; b=NbCF+D0PTeHrOPCrx1H7CGWrTe+HsKeZ6ElhzC88XLUbVL9KQZP8FHUjMwP0uCac5w Dl7P6A/bjXuf8c8BQoeps05E5Ure03BipAL0qG4/kS99lifO0iVnD3COOIWGK1+8vV8f Pp6q0jRR3bUQxhEG0IpYFqA/Plohukyf9gIH1X85hM+/mvgqsRCDDG2KN/QCA5if6ikr wejXE2yl2Au3zTAH7B1OtIUzizSGGHIvxp0cRnF8ex1Os8/IGditITUfIpINfs/A/5SO lSm6W42tKo4SHn/GXvluwpgLXIOCMccIBs6XtghXxUfikOuHx4MUJBrq7gy7zB2CKdAX eRng== X-Forwarded-Encrypted: i=1; AJvYcCWtZCu2MYYQVc8likKDL4dFPNBJ1rhzTapAxePrR+f38JuRNlOcitt6y4KZpyLboifnlGjJ1kENCA==@kvack.org X-Gm-Message-State: AOJu0YwEj9cQAQZxh3/DU3j+hIU1Qn30pdXG11E3NkT59RsRk5U8679m D4/LMDUqk9GY2B/vyMTuiEGH2YR1b4d5sxqxYzvw+Dordgn7RNzJjWEqw8005ukAEXG/uYcEakr ZD+VzQMhQUyZbGn8yM0/2Nx5j7mBk4M5vRO2Q X-Gm-Gg: ASbGncukZQNbRDUKYJE5sLdMKXdiNGJhU6cLgdwbZPZodAHYanA+le34Ex1FOXtjQg7 QKTR2pWeGvrPf2SRFb+Fj3Mjb78jILOTB1BWdCui6r6mabKyt7dd9ImAA8FnZ/u/nIXjNx/pGOH Sj6KPUjlHGTIBcVCKai0OLkMMUPCMg8rx5Z29o1pzFKgkg142cBw== X-Google-Smtp-Source: AGHT+IFMCSz+DMkX+SXzsy6oBemggwRgx2rch6Bt53f4enSvSdPuMeC4mItCR5WNmCzwmoMolNdmuYo2j8u88K68g3A= X-Received: by 2002:a4a:e203:0:b0:607:de7b:aa0b with SMTP id 006d021491bc7-60828d094camr495455eaf.1.1746623402327; Wed, 07 May 2025 06:10:02 -0700 (PDT) MIME-Version: 1.0 References: <20250506095224.176085-1-revest@chromium.org> In-Reply-To: From: Florent Revest Date: Wed, 7 May 2025 15:09:50 +0200 X-Gm-Features: ATxdqUGqHGfM-ERnuNPXYXI2S2k9wJ40t1n7VxMcXPLGzQ6yF7PJYBq-4YriJMo Message-ID: Subject: Re: [PATCH 0/4] mm: Avoid sharing high VMA flag bits To: Mark Brown 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: x5mou9hsbkkxc5ckt5jq4nxowy9uicsn X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7A76240015 X-Rspam-User: X-HE-Tag: 1746623403-168741 X-HE-Meta: U2FsdGVkX1/UMbem73c06Vk01B0hHAR5T+lNOAY8sAKGxYTkMCBhEOnwZgg6eeoVbT/bJgc7XVf/Dl29DU+MOSgvCKhrvqvvo1zyvfx8SjDI6XNRXjNyz9wwcp4XmoxUEeamgr0FiABq4G90yFvuLdi+YdFXWvAyogh/BzD1sH3vu6GQYK+q2TDOXCSDMQPg5v4MzpVP0WnXr4WGrV1KCwER3usi1VUO4oly1a2DgYSYKqpHBrQejlPvtbQP6ia3QlV+bRZ7txRoU5nlTi2TlJZXi18dyGGQvrwdVeA+ZD35Fv7sI4QNEaRfVAgXT9iC68TxV6FSeZvf0E5GZ/YMrAD3J/kZfys2fgHyuDXFZqMOqiSDOFUJa7XDrR9PmS08BBk9+bB30goSPw2zEB88AgLvJqYiZhl+KJ7/uCUPCrldcLYrjr4eCaDRB0TSSX7qnXIRXbxipqLNoukCabLeFitC3/Yw9N8e0knJPl19c9QDelgjSAxpH7ualrX9ZolWOyqqGS9yGy5RlMjX3WTI+/vUaJwdXsDaxQ+zYjiF3EQ7Y/p2+my/KLdRcEyOwrylq0lERCGi+Tg5rPflQEt7IYEatRKJsoRBPz1607Rk6OmQgOD1N1aYVEg7XLopFdj1zq18TXmFfYiTO/7eCdjvqGbMcCvnKO9tEk/AAFy/pYWsYZojjCT5/NaoJoORmPsq810H0zAgmcAoTdGJt0aLEHO6hyoUqyGGxD1f19gMufFX9Mvv1Q5pGn9hNc2AeSsYig3VW8vck3uXibYdqsr0vLVaTLpe9KqvSVQKsNeLPPAb0MgqvPZR3dKWJXDYhPxsRC42pmWMr6UapxI4JB0ycV6VCS8FqTGo7mCShXlYQjh8TBu7ZUrWSc1oVYymHKM7IFtSBolLAbamVD+lBdzhVju/kohHUIHo 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: On Tue, May 6, 2025 at 3:34=E2=80=AFPM Mark Brown wrot= e: > > On Tue, May 06, 2025 at 11:52:20AM +0200, Florent Revest wrote: > > > While staring at include/linux/mm.h, I was wondering why VM_UFFD_MINOR = and > > VM_SHADOW_STACK share the same bit on arm64. I think I gained enough co= nfidence > > now to call it a bug. > > Yes, it's a bug - it'll be an add/add conflict with those coming in via > different trees. Thanks for the review Mark! :) 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 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 ... 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.