From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C12AD156677 for ; Fri, 5 Dec 2025 21:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764970495; cv=none; b=pa3Ra1Ml8IU4SRVVA2Jy9QnK8cYHDPj/Ri155SxNG7GVCKC8GegGtBd8DSc8O7/4uIJpklvtMUa0ZP/IweFJBLdVg1DkYi+ivVAyLEcexpuaUgjddr72JrPaz93OqaBs2NUSB7Il7ICdR5FM408vSHZk8gVRLFDLdVkndXfMaRs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764970495; c=relaxed/simple; bh=oHNjfwLKzAtFXYxH6kYVCE5lPwBqqYm44c9XnwF3HxE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bQnaWoa0UJwTsobSXv9ahIjD7T/D7p2MqWPT7/+phK8Wy2GzbWloYRExyytDS3DDZs7nTC5RtuQqA+aytQFdCFJ/S74/Io3ekp7D0uRVrpR6GwI5Eq4QmIcAy+SpPESt53VnnMmUK3khmNQrvjTn3y4uBsuJIqeusYS4FXJbE8Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=d68Z2L2G; arc=none smtp.client-ip=209.85.221.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d68Z2L2G" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-42e2e239ec0so1581328f8f.0 for ; Fri, 05 Dec 2025 13:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764970492; x=1765575292; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=MjLjsRbRwmoA+FQ3Zj6LdJhYetQGPRvx5e8W29o2gSg=; b=d68Z2L2G8Xa/QMriNqN9EyMwn5kSxWSmd/KhxP/vvDuGYR0DgXRgG9SrcF+leuMbXy 4Rjidank33Nr68+2f/QCjw7mK+cmqEskCGvP55BRBmQfyrCUOQiGAF4G+lzTI4mVbNt9 kgePP3AdolniXNCinpp42bBTGc4Gd092G6UWLRJrt35UtSO5Tqj4irkAsCZWCZ15jQD0 SLE/7/4vD++oykqxhRWfTgG9AkyR45csK5OOcZcDKHZK7vZb7tErlsSgEh7sBdrHo7AM H8r91bqo19zvT/99dMit6bfGpGxJlyaCz+UUct0me76Rpwhrov42Ehr3mrFvH9dj41T1 vY/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764970492; x=1765575292; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MjLjsRbRwmoA+FQ3Zj6LdJhYetQGPRvx5e8W29o2gSg=; b=HmmraIjWL3cZkKyp4yATnCV/46gj+T8K6NdwbGjS4z4XTu1cl7VQ8u5gkHsmZUpy72 +HYcyTt45nadNEE4S5bg1XBdpaMOXjOMTMDwVx1nZeH6oWUsfr/9VHQczpHukg/lXtHA QkUFYzCnWmUjIv4UuNxZx+GM8ZbvEbpPdWMtaeGCjV0kiD5j3sg9zHK4/s85Sf2m4mjT 1nu3tLmNQYGcqBDnYsQMbHFmVpMof7hASrIKO0l4QzcYoTdmRFfJpxIv9Sm2FMJu9myU 0ej0BUAQtr1fKJgjCXOXAB51q5YzRPcwrHvc6jET3Nhf/Q5BUjAmx45sMyARoWiDDW5G L4uA== X-Forwarded-Encrypted: i=1; AJvYcCWQ02KLdwe+W7bdkfmlqnJHFp3kCk/2HP+qJ+7C9GqNX88TwZVo4Lx8A/dYK8gx9DDOyPKq7s+Uhq1O3/o=@vger.kernel.org X-Gm-Message-State: AOJu0YwjQvGYqtU/hW1a1ORt0B8qL6AdJ/clJd1gfFh2v2wYqkg1FfeF /5T7kIseT3lVhoZICBdtVp+z9YlUmYed/09IL5lJIIcfkCV8ydVoKGFk X-Gm-Gg: ASbGncvb4e7iHMQEK4J19fwrVznnGmqxvTrFDxyN1C0X1DFR5bWfQBoC8pQ199LM2+k LWHAYJ6K7sv/N1AZme3NuzZCdsAh+c2rBOAxgg13lGcTVJ61rUeb7Zb1mF+r9HGwwfuQRuz2raG 9wWgy2MsVkgD+ksdQLWZWZq1YLwbFelFQM8jOkcCkfjL5FtclDlmuFFkdlLiXC+fxvh+oJmHKtX 9ib+1WcTXoiO20HmVLhjED5DTfwog3TR5t/Pk4QxSNppl/ZLBsJyZHS0gevNK1HfGG1+0QBNGfl /PEaV1fk5o9JwObWejVldCEzDE2HNbx8mLvMNRowmLHg3EAP2fGqBZCdxihHewGxwWYQ1Yl4Z+N EoD3+vO0nwTzOP4vil8KAULaibuIqDZVNvG4Zcyj+HJFCAohtoH9c1d24ZWG6nGEEBqYfuxHThd LPuDb7S6YVF8SOPXxgIarGuckn9gvb3Ieme+SijJY3bxDgkzaYtRBEMnpolpWru+g= X-Google-Smtp-Source: AGHT+IHz5isvd2fROT9WV3DcH6mXEwl1tvt4z/k5O8VzjcHx14gWDTICAbNWJFuVd44ACykMs1s8Tw== X-Received: by 2002:a05:6000:220f:b0:42b:3d9d:c5f8 with SMTP id ffacd0b85a97d-42f89f17033mr572101f8f.6.1764970491933; Fri, 05 Dec 2025 13:34:51 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7d222478sm10630707f8f.20.2025.12.05.13.34.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Dec 2025 13:34:51 -0800 (PST) Date: Fri, 5 Dec 2025 21:34:49 +0000 From: David Laight To: Lorenzo Stoakes Cc: Andrew Morton , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , oliver.sang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: avoid use of BIT() macro for initialising VMA flags Message-ID: <20251205213449.12bf4819@pumpkin> In-Reply-To: <4eea9138-3853-457d-9113-e3caa7f00437@lucifer.local> References: <20251205175037.1287366-1-lorenzo.stoakes@oracle.com> <20251205184342.2cfcc73e@pumpkin> <4eea9138-3853-457d-9113-e3caa7f00437@lucifer.local> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 5 Dec 2025 19:18:56 +0000 Lorenzo Stoakes wrote: > On Fri, Dec 05, 2025 at 06:43:42PM +0000, David Laight wrote: > > On Fri, 5 Dec 2025 17:50:37 +0000 > > Lorenzo Stoakes wrote: > > > > > Commit 2b6a3f061f11 ("mm: declare VMA flags by bit") significantly changed > > > how VMA flags are declared, utilising an enum of VMA bit values and > > > ifdef-fery VM_xxx flag declarations via macro. > > > > > > As part of this change, it uses INIT_VM_FLAG() to define VM_xxx flags from > > > the newly introduced VMA bit numbers. > > > > > > However, use of this macro results in apparently unfortunate macro > > > expansion and resulted in a performance degradation.This appears to be due > > > to the (__force int), which is required for the sparse typechecking to > > > work. > > > > Does sparse complain if you just add 0? As in: > > #define INIT_VM_FLAG(name) BIT(VMA_ ## name ## _BIT + 0u) > > > > That should change the type without affecting what BIT() expands to. > > Thanks, checked that and unfortunately that doesn't satisfy sparse :) > > I don't think it's too crazy to use 1UL << here, just very frustrating (TM) > that this is an issue. I might use some of my copious spare time (ha) to see why BIT() fails. I bet it is just too complex for its own good. Personally I'm fine with both explicit (1ul << n) and hex constants. The latter are definitely most useful if you ever look at hexdumps. At the moment I'm trying to fix bitfield.h so you don't get compile errors on lines that are 18KB long. Found a new version in linux-next - has its own set of new bugs as well as more of the old ones. David > > > > Cheers, Lorenzo