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 7A1D726290 for ; Sat, 6 Dec 2025 01:14:22 +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=1764983664; cv=none; b=YAI+T24Ps43hovD+wTXdwGkUvmJCRS/tmM59F58NlGT19ifRcbR5wF4W5BA2+7zf9FhehWEkfuzAJwubbG14KXqHabHL1mrkdXthZj/Qo+6hUwTLKMsHxf6m9VsogE0Q6d9wnwCReXUlq8ieOD6R/tRCHmambrIf1sK9zenR5t4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764983664; c=relaxed/simple; bh=biafVuDuAnz9fvDwfiELDjqW0yQoNEuRxW7u+pBLgcc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gqTF5tdYPSOWfNgZsPCrcGtD0IpcJwTG8HGlrdRyvWCw5khpHpPhu0CHe03gyILyv3VsQnYeqW5Y5sT+A11TZuuELDl3GT5qKtUdK1xPREPCdBAqSdy0xA52qZBYL4kM2XUpRk4NBhmZ2DcuIMfzYuc/9qOpT3sJ+V+Fye4+4ms= 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=pIFhq44v; 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="pIFhq44v" 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=JFglSonZ7YxPo3VRt1KcGMtrxiomR8dgNDoQ6a4aYpo=; b=pIFhq44vqodCt8SjmE1bmMLqDH sw/i9MjfSnzBvRq551S7WyLZ7WpZK/+4+Uc91Y6TtqNJlCy/jF9dLdUAIARA53nQcT5/HAIz3GTQ7 YKGPWKIDOJwZuAvd5h0NdJsSh7xUmo3dD8ZIgdbcwWDUqmNH2qvkyYbPGm85TtgyArNtAd845GKs9 PrS7WHSo1gXniWkZ567QJmeL0YKuPOgzvspw5QgUeViMxAZ3jiGXqLZFIjWMLUSQI0egs+BSsj0b+ lX1OexNykLC6IHcQXw3WyM5zJxmyozP46LNa8WjYZRIQ0wt+2YPiES6pPOPvw2gGbIW5vjVMdHpfp SyzdI3Jg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99 #2 (Red Hat Linux)) id 1vRgsd-00000003sZU-0kc6; Sat, 06 Dec 2025 01:14:35 +0000 Date: Sat, 6 Dec 2025 01:14:35 +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: <20251206011435.GM1712166@ZenIV> References: <20251205175037.1287366-1-lorenzo.stoakes@oracle.com> 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: <20251205175037.1287366-1-lorenzo.stoakes@oracle.com> Sender: Al Viro 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?