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 03EF0C7115C for ; Fri, 20 Jun 2025 18:47:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80EEA6B009B; Fri, 20 Jun 2025 14:47:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E4D56B009D; Fri, 20 Jun 2025 14:47:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FB6B6B009E; Fri, 20 Jun 2025 14:47:06 -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 62D796B009B for ; Fri, 20 Jun 2025 14:47:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 138B281195 for ; Fri, 20 Jun 2025 18:47:06 +0000 (UTC) X-FDA: 83576661252.15.98FFDCD Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf18.hostedemail.com (Postfix) with ESMTP id C700C1C0013 for ; Fri, 20 Jun 2025 18:47:03 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=wV33ZKmi; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=iltBBPrt; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=wV33ZKmi; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=iltBBPrt; spf=pass (imf18.hostedemail.com: domain of pfalcato@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=pfalcato@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750445224; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0TkWPg2eqT1+Wq/XA39xuKkI/6ymg24dNRTDXNGfR9M=; b=3pzUXfmASOiadroKUmMlgE07nIVL7c33fUQ/wZlUBBbLZ8F+Zu7hx18FbaIquD5UETbeLy XgQRwkANo69+IIH44+YvpNKSgnTa4Msz12Kl1HHwMlHcmy61jcF/zzGK1c7ccyJHlHgD2i wY63ayXODA69aGNfB5UXvdTzwqz4teQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=wV33ZKmi; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=iltBBPrt; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=wV33ZKmi; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=iltBBPrt; spf=pass (imf18.hostedemail.com: domain of pfalcato@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=pfalcato@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750445224; a=rsa-sha256; cv=none; b=Q8/iU8VCfwI/NBL0c6/KamEu2cU4/G12RtcW5GTgfJQ11ycyiE4/DhFEiG4RuoYoX+sREp V4LO7bE6Mn/naHzhLXqcatKKbXTMvQ36HzS0ImXjRPZwgiiSUUGr0sRHaYHPP5nsXyFAqf qex59jOkmdXcRv6uXC3aO4kguy2kStU= 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-out1.suse.de (Postfix) with ESMTPS id 1721621165; Fri, 20 Jun 2025 18:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1750445222; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0TkWPg2eqT1+Wq/XA39xuKkI/6ymg24dNRTDXNGfR9M=; b=wV33ZKmidBf6Y8tLbYUzp3ExOoEPuqaXGNO1YKfUzB3/w6kUbu02/maHt8FMnN4Da9PGMS f/xj59Z9f2sNOOQGQZwZXjlX5vxf16MTmKx0ZrujArItuct/44+QL2YYZZXq6No3336eam mNLTOl4uB7qph5v5nYSGBhagrx1l+yg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1750445222; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0TkWPg2eqT1+Wq/XA39xuKkI/6ymg24dNRTDXNGfR9M=; b=iltBBPrtxjj12CpwRx3h+WSbqrjS7pCaqKpa20FayEi0UZ3cdueWboT+A2rw9MX97i0kQZ Kwks5DiRHuYcBuAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1750445222; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0TkWPg2eqT1+Wq/XA39xuKkI/6ymg24dNRTDXNGfR9M=; b=wV33ZKmidBf6Y8tLbYUzp3ExOoEPuqaXGNO1YKfUzB3/w6kUbu02/maHt8FMnN4Da9PGMS f/xj59Z9f2sNOOQGQZwZXjlX5vxf16MTmKx0ZrujArItuct/44+QL2YYZZXq6No3336eam mNLTOl4uB7qph5v5nYSGBhagrx1l+yg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1750445222; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0TkWPg2eqT1+Wq/XA39xuKkI/6ymg24dNRTDXNGfR9M=; b=iltBBPrtxjj12CpwRx3h+WSbqrjS7pCaqKpa20FayEi0UZ3cdueWboT+A2rw9MX97i0kQZ Kwks5DiRHuYcBuAQ== 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 8461B136BA; Fri, 20 Jun 2025 18:46:58 +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 y/tWHaKsVWgWFwAAD6G6ig (envelope-from ); Fri, 20 Jun 2025 18:46:58 +0000 Date: Fri, 20 Jun 2025 19:46:56 +0100 From: Pedro Falcato To: Lorenzo Stoakes Cc: Christian Brauner , Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "David S . Miller" , Andreas Larsson , Jarkko Sakkinen , Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Alexander Viro , Jan Kara , Kees Cook , Peter Xu , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Xu Xin , Chengming Zhou , Hugh Dickins , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Rik van Riel , Harry Yoo , Dan Williams , Matthew Wilcox , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jason Gunthorpe , John Hubbard , Muchun Song , Oscar Salvador , Jann Horn , Johannes Weiner , Qi Zheng , Shakeel Butt , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, sparclinux@vger.kernel.org, linux-sgx@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, nvdimm@lists.linux.dev, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] mm: change vm_get_page_prot() to accept vm_flags_t argument Message-ID: <64r5sm2aqgphrs5t4vzzgz7qitn3efmxpxjzv4wsaeyuncrn56@tdu4z7uzxluq> References: <20250619-unwiederholbar-addition-6875c99fe08d@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Queue-Id: C700C1C0013 X-Rspamd-Server: rspam01 X-Stat-Signature: qt1g8ttdabomc4f9pxdg9m1tfqp91sgd X-HE-Tag: 1750445223-84777 X-HE-Meta: U2FsdGVkX18zuCq+vYkrSTI4q/2+3lXtzlxh6rSmcBTu7Yl1DzMd81+DxbqzKnA7JvZWjwticavUd06NCJ7UpGejZGPL4Kpk5ws4gJTMxWXzMQGU+xGrEUeEpnLkeHLwXHzg3uLvqNMImIALnllii6wYV5c2d+iBp8Fir8/PD9JGDiO8va7t5FR9H3wzrtyBjD7zpy/O/zc7m2MC+0pwpyOTyLYpfOUlgiFvtzYSQV7ZMYz9G2bERr++1kPAQewylXbuZbJu3O4gL8hYLvtyfNmjm+QfvBkgRbtVNynAt442GOfIkFPxHbysqJYUIXTvn7KdY9nVz67p3al1mZWPMU5wFJuYaWosW/fUVPUPA+6cFshyi+++83PXKSx8+PjsSM0Av9kaUqs3ZWeRkdcdF0Fmpfj4km2+AKfKi/G8ZS3jFIGdg+6IbHfUkk1kqQVHc0ZCVDlOrmELt5L0QvY3hJFBuWpHxIhk5zXw7Qop/3gdqcpboKzSQgP+IqhyBHZOLif2P7gw5LlAQzaRfPm2pcfMtO6dRFkyTv6U7IIs7FMF8z02KTvq+li31fFH3SrUUbLLzt2Gi3wBMRKwQKlPrU/8wP5WrE2+ACXlvdhgN3M+SbDYwO/aP8PKlPqm5fMarkuyg2QVO/R2mP+HVa8ivoZLYFnzpVCqqNg9BPrg/rhAflUnqZINEBoLWuSHeHEWjksmR+CGkB8BjNPtrt5SEWbSGrjw43XSDYoStkyGu+CtotlfsYe4cCMLcMeUvWemMDfdQ1CDKvdYrRVbQAiipJKGhGaxvKchtTqpjU6DPfwXg0PRRVpb3G2ZHr2JJm+LOm6phsXHMcXfxAjjl/IydfzsNzy30zJfp8cKgYC/bcP9WKI3HmbTis2Zmgae+0w48TumfhA1l6R7HFcY977vC6wKUEn20R7BFNeLDO4NnXgvIhqtCAsVQXKgypxbpGkfsZktTsGpDf7bkdqFsHB AyK7bUek 66I0DSNaze+/J+L2YXdaY+b/Wqb/8l8jLd6A5fJCrxo6Qx+qPRLP0TbePLOEDTq3zIDa7v1N4TBxE9IVSBxn8xoK23mk3SvqXd5zSbiPcohEDIxeH+wGYHkW/tQDpUXmHfuRCzeaq2QsSyCRLzXUaifTNw/wN+YIpsCKGZ+ayifPm3Va8V1lx5wh3hdzzri64Dn1vqut0vWC0dA2J0xFUr4bwsK/MIdn3Gbl1rpeUlXNIdkX044PPO3l8ev8nFyKHHLd3bTW8O5k3qcj1AIgpelm8EdV1HH3yuITp6PORR2SiL2y9aO/Ac/wDqFSB4f+bWkSaFRW0E677chANki1i4ryITtVnIQtPg41b 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 Thu, Jun 19, 2025 at 09:49:03AM +0100, Lorenzo Stoakes wrote: > On Thu, Jun 19, 2025 at 10:42:14AM +0200, Christian Brauner wrote: > > If you change vm_flags_t to u64 you probably want to compile with some > > of these integer truncation options when you're doing the conversion. > > Because otherwise you risk silently truncating the upper 32bits when > > assigning to a 32bit variable. We've had had a patch series that almost > > introduced a very subtle bug when it tried to add the first flag outside > > the 32bit range in the lookup code a while ago. That series never made > > it but it just popped back into my head when I read your series. > > Yeah am very wary of this, it's a real concern. I'm not sure how precisely we > might enable such options but only in this instance? Because presumably we are > intentionally narrowing in probably quite a few places. > > Pedro mentioned that there might be compiler options to help so I'm guessing > this is the same thing as to what you're thinking here? I was thinking about -Wnarrowing but sadly it seems that this is only for C++ code. Also MSVC is quite strict (even in C) when it comes to this stuff, so you could also add MSVC support to the kernel, small task :P One could in theory add support for this stuff in GCC, but I would expect it to flag almost everything in the kernel (e.g long -> int implicit conversions). > > I also considered a sparse flag, Pedro mentioned bitwise, but then I worry that > we'd have to __force in a million places to make that work and it'd be > non-obvious. Here's an example for __bitwise usage taken from block: typedef unsigned int __bitwise blk_insert_t; #define BLK_MQ_INSERT_AT_HEAD ((__force blk_insert_t)0x01) then in block/blk-mq.c: if (flags & BLK_MQ_INSERT_AT_HEAD) list_add(&rq->queuelist, &hctx->dispatch); So doing regular old flag checks with the bitwise & operator seems to work fine. Assignment itself should also just work. So as long as we're vm_flags_t-typesafe there should be no problem? I think. > > Matthew's original concept for this was to simply wrap an array, but that'd > require a complete rework of every single place where we use VMA flags (perhaps > we could mitigate it a _bit_ with a vm_flags_val() helper that grabs a u64?) > I think the real question is whether we expect to ever require > 64 flags for VMAs? If so, going with an array would be the best option here. Though in that case I would guess we probably want to hide the current vm_flags member in vm_area_struct first, providing some vm_flags_is_set() and whatnot. -- Pedro