From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40BD22D6E59 for ; Sat, 6 Dec 2025 01:25:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764984356; cv=none; b=ToVAlMXgZ8R6B9ldrG2AJ4UbNhuTjb7m897Lqb7COuqfzbIKvTigskuwa/qOcAQTdgCUDTk6qegQl51Fq4xvbwPpNoAs/5Fc78DDpVtJpiwAIPPS4f9z7Qxu5DnHY0XpoFYHBHJcYz1KGfqbnEeN13+Qa+Ys0BgGp8umn8EIv5E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764984356; c=relaxed/simple; bh=EozJQzRO7s+HmKTRjn6m9NynrewM0uaHqwY6/++JZ54=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Da+n0DmRVd/AzCEm5BkFb6fcpmSqw/Fw0wNGnuUXdBMrC491qEZyPk74gA4wHUa4CooCLxdNxQk+cYZ22dBLJekTZHnQ7dqQXq28CNbsfOJHzgxx4eBcxckzkzxLeq1QXp6CnJ3lX5XMSF2DctU8MpbdHqdNpAYkZG0gOFd1GdI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=O7BwMqIr; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="O7BwMqIr" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=AxMUTPrkAZTGMcrjPXj4RfoXgnl9iUjMPVIZTyujls0=; b=O7BwMqIrdFF9CkePwh/M+8p5j0 t4FAqufD8mv2VNTzJqb/h605ECIFwGCAiGrNqEIKAEVJYf0LBFd0ajsBc6hByElUVyl4+Sfqno9Fh mnxI2LRXGgcIjeCrNS6HsfOnwjbJQIX3vJG7XS1NFanddj17lgKrf4+qJ/g7AtRZ09ovAB6JUCP17 Cjnw2ULSn0Gs9k0ZaeW7QAnyGRK1VH+L78Zwvp/uQrxSPXldbUwaXUKVOpIJ8V1UmoPhWpYGswWBR yaA1cBZws5Yx0o+OFaHH/LvIJgyAY8VtR78129HrLenoEI1RLaSYurLWPsv8HTbl8WqCmdLccsiro uOClFnIw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99 #2 (Red Hat Linux)) id 1vRh3o-000000040At-19iq; Sat, 06 Dec 2025 01:26:08 +0000 Date: Sat, 6 Dec 2025 01:26:08 +0000 From: Al Viro 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: <20251206012608.GN1712166@ZenIV> References: <20251205175037.1287366-1-lorenzo.stoakes@oracle.com> <20251206011435.GM1712166@ZenIV> 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-Disposition: inline In-Reply-To: <20251206011435.GM1712166@ZenIV> Sender: Al Viro On Sat, Dec 06, 2025 at 01:14:35AM +0000, Al Viro wrote: > On Fri, Dec 05, 2025 at 05:50:37PM +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. > > > -#define INIT_VM_FLAG(name) BIT((__force int) VMA_ ## name ## _BIT) > > +#define INIT_VM_FLAG(name) (1UL << (__force int)(VMA_ ## name ## _BIT)) > > What the hell is __bitwise doing on these enum values? > Could we please get rid of that ridiculous cargo-culting? > > Bitwise operations on BIT NUMBERS make no sense whatsoever; why are those > declared __bitwise? FWIW, bitwise does make sense for things like (1 << SOME_CONSTANT); then you get warned about arithmetics and conversions to integer for those, with bitwise operations explicitly allowed. VM_... are such; VMA_..._BIT are not. VM_READ | VM_EXEC is fine; VM_READ + 14 is nonsense and should be warned about. That's where __bitwise would make sense. On bit numbers it's not - what makes VMA_BIT_MAYREAD ^ VMA_BIT_SHARED any better than 3 * VMA_BIT_MAYREAD?