From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (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 CB520DDC5 for ; Sat, 6 Dec 2025 12:35:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765024527; cv=none; b=GsmcXVlGrGyqSXyn5pj4cOLMxu+PSi/RqNg6XD8SxRTt6DgSMRycZEH6kq5c7b5nutVnikmdn/E0cBaYv/YswfQS389DKP9Rgf3iFVcpDPOn3xs6eWNB6wbvRXm5J6MXoB5x5NXN4lAeGuBgwNSH9Fd9bllTnQKkbun2JoZyFVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765024527; c=relaxed/simple; bh=YDtTeiE7oG+FjQJDhXTI0AxD23M5NJLNDeRG/lUJH3U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aRNxfCpuGwn2pHkmk3/JneKwS4t4f7g2FQVamLFmMrHlex1dajwnXgbtrr3Fyh1nbqO4bOTmNshHJb19xcLqlRxmrj38srzAI9j7yCvzpZEF3yatIgLfu+BRay5eh4HCYSQgyLoRBqo5vBh3fUJznun7fV0oHBIEiOsr8D9u8vo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=JQUbakmx; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=xHxRT2bL; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=NAkHy5ca; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=FD7ycBcw; arc=none smtp.client-ip=195.135.223.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="JQUbakmx"; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="xHxRT2bL"; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="NAkHy5ca"; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="FD7ycBcw" Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 525495BDAD; Sat, 6 Dec 2025 12:35:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1765024523; h=from:from:reply-to: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; bh=5Nsbauxx0BTUi1oISALadbV1/HwdnVnaiXWwejprpqw=; b=JQUbakmxKW/vExSuk19+LscFXwkwqMRfPxodpGlLAIhGW6b610Cby2436q/tBVI+s9Qdv+ 2k33X/W72w6yDYypUgVRbemdfOeVd7/RmqCKjW5ggC0X8lIxlhyvUTE3H9nMDoJA7UiUhA DDOzWiwkJEgXP4MQGngmBznbwZ1dtVQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1765024523; h=from:from:reply-to: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; bh=5Nsbauxx0BTUi1oISALadbV1/HwdnVnaiXWwejprpqw=; b=xHxRT2bLlu2JWhMPlfoxdhYtGL0cWylQug0SWcEUUbBqs6e5JSmMIHpWdmaK7mrI9KVd07 rfMvDl0n3Zjhr7Cg== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=NAkHy5ca; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=FD7ycBcw DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1765024522; h=from:from:reply-to: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; bh=5Nsbauxx0BTUi1oISALadbV1/HwdnVnaiXWwejprpqw=; b=NAkHy5caQcdDsuUT9AVh4gkDTCEbPXrI6upP4BgHmaN6u7+DaUkh7o4NKYCFwbWUo8yIHs p+T7ybDivVzxqeeRe1K8SWUUtJIE8QrtcROdA0X+GzN8QPnXufwL5Yn8sC81x+9ZGcNltD hNZs7EZ7NQ0/ZArNC7OdYcIhC3Vrh2s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1765024522; h=from:from:reply-to: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; bh=5Nsbauxx0BTUi1oISALadbV1/HwdnVnaiXWwejprpqw=; b=FD7ycBcwpixFwN9ri7OIaKPLTnbxWnUUwmsK8sP1znm1so/ofvkWAjPAeBi0k/ZUR8cvno sQ3LtKCc2kFwLmAg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2EEF03EA63; Sat, 6 Dec 2025 12:35:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 13aOCgojNGmpSQAAD6G6ig (envelope-from ); Sat, 06 Dec 2025 12:35:22 +0000 Message-ID: <47e99b07-e599-48d7-92ad-0471ed6bfd8e@suse.cz> Date: Sat, 6 Dec 2025 13:35:51 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: avoid use of BIT() macro for initialising VMA flags To: Al Viro , Lorenzo Stoakes Cc: Andrew Morton , David Hildenbrand , "Liam R . Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , oliver.sang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20251205175037.1287366-1-lorenzo.stoakes@oracle.com> <20251206011435.GM1712166@ZenIV> <20251206012608.GN1712166@ZenIV> From: Vlastimil Babka Content-Language: en-US In-Reply-To: <20251206012608.GN1712166@ZenIV> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Flag: NO X-Spam-Score: -4.51 X-Rspamd-Queue-Id: 525495BDAD X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-0.999]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_SEVEN(0.00)[11]; DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.cz:dkim,suse.cz:mid]; DKIM_TRACE(0.00)[suse.cz:+] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Level: On 12/6/25 2:26 AM, Al Viro wrote: > 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? I was confused by this too at first when reviewing, but instead of the angry display above, simply asked the author and got answers. Comment says: /** * typedef vma_flag_t - specifies an individual VMA flag by bit number. * * This value is made type safe by sparse to avoid passing invalid flag values * around. */ typedef int __bitwise vma_flag_t; It's done as documented in Documentation/dev-tools/sparse.rst section "Using sparse for typechecking". So yeah the keyword is __bitwise and indeed we don't perform bitwise operations on the VM_ values, in fact we don't perform any operations without __force casting them back first, to catch when they are used by mistake. It's not cargo-culting, IIRC it catched a bug in an early version of the patch itself. I wouldn't mind if sparse provided a different keyword than __bitwise for this use case to make it less misleading. Or even better if we could make the compiler itself treat vma_flag_t as a "special int" that can't be implicitly cast to a normal int, so we don't have to rely on sparse checks to catch those. > 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?