From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 6051F3B0585; Mon, 12 Oct 2026 18:58:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791831503; cv=none; b=DGBTVBPJZq/ocmdITuyqj1zXcXC2fBD/vHulOeU6eM4b5zXQhr5r1yLDzrcAj5CNLkXskvznDrshdUStJCYJl4USPacnmrlZEM2hhy3R7lGQn8Od5ztgPkc83YzRm9I7DaAHn1d+2Oqv8IL4LJKBmUn6XvI+kv5ieGa316maFqM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791831503; c=relaxed/simple; bh=mPMsM5/IdrLh22BcJk2q2UjNA9KRSqTSI4BO/emak7c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sMyPxMhWTR8ZoOn3loWP+OxRL44DLKxg+lpp5EF/bmXmH3y7opUOjeZPxB7c3czbqSYJACx51ovIM3vRO54acvi6ygtzP4IT+QJwjYszQ1Dru9qIq1I1EVyuQLL4mzaHz9t/nw90u9yGO/VtAgaj+ZR9GHc9m6f4GF4ZMRBYit8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=looXlA6f; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="looXlA6f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5EB01F0089B; Mon, 12 Oct 2026 18:57:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791831502; bh=qH+yTBGHMx4kskcBpBDKONKQ96Db6V1NplbT44nRvZo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=looXlA6fTwVHV01oPQjKIsaLN7qg4gOfpfxfIKT2JYCP5qc6mtNOfKXzipcBrh5Ot PwTlWcUh8iMGaWDsLLerJWirxQS11zQ+uNPPZD56vjlnfd4Xt8Ty0QR2gLNZRLAVmZ XB2AV4YuqJ2oKkV2g5m/6Icmp243c7oQwlXcOgSGhet9aPBJl7BLHiRyQaIFfTFg5f R5mIs3NuvgJeGZzERtd7pZ/l5Ywtb7I+I+N5/X1JMKypG8+SLTaEsyrMX/W1aLWQJP x0/ar3g7y36ElH0BWNMVIYJBfaYlLx77JuLREXrJFvmLlG+LDzzGKzUyJUzEJO7zAF 41OpXgdKh9hhA== Date: Mon, 12 Oct 2026 19:57:46 +0100 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jonathan Corbet , Greg Kroah-Hartman , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Paul Moore , Stephen Smalley , Jaroslav Kysela , Takashi Iwai , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Kiryl Shutsemau , Doug Gilbert , "James E.J. Bottomley" , "Martin K. Petersen" , Simona Vetter , Helge Deller , Sebastian Reichel , John Hubbard , Peter Xu , Masami Hiramatsu , Oleg Nesterov , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Rik van Riel , Harry Yoo , Juri Lelli , Vincent Guittot , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Arnd Bergmann , Muchun Song , Oscar Salvador , "Matthew Wilcox (Oracle)" , Jan Kara , Marc Zyngier , Oliver Upton , Catalin Marinas , Madhavan Srinivasan , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , "David S. Miller" , Andreas Larsson , Alexander Viro , Christian Brauner , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Youngjun Park , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Chengming Zhou , Michal Hocko , Miklos Szeredi , Xu Xin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-usb@vger.kernel.org, linux-rdma@vger.kernel.org, selinux@vger.kernel.org, linux-sound@vger.kernel.org, bpf@vger.kernel.org, linux-scsi@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-trace-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, fuse-devel@lists.linux.dev, Ihor Solodrai , Bert Karwatzki Subject: Re: [PATCH v5 24/38] mm/vma: enforce that mm-managed mappings may not set VMA_IO_BIT Message-ID: References: <20261009-b4-mmap-prepare-vma-flag-sanify-v5-0-923b70125b1e@kernel.org> <20261009-b4-mmap-prepare-vma-flag-sanify-v5-24-923b70125b1e@kernel.org> <5d51b6b3-ad58-4827-bedf-f1a79ebd5c86@kernel.org> <5ba7305f-0ad1-44ee-be0b-36752684cdb9@kernel.org> Precedence: bulk X-Mailing-List: bpf@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: On Mon, Oct 12, 2026 at 08:51:10PM +0200, David Hildenbrand (Arm) wrote: > On 10/12/26 20:48, Lorenzo Stoakes (ARM) wrote: > > On Mon, Oct 12, 2026 at 08:39:35PM +0200, David Hildenbrand (Arm) wrote: > >> On 10/12/26 20:35, Lorenzo Stoakes (ARM) wrote: > >>> > >>> That gets removed. > >>> > >>> > >>> I mean we do that in a subsequent commit, I think even the next one? > >>> > >>> > >>> > >>> Yeah, but to do that the code would now be something like: > >>> > >>> vma_flags_t masked = flags; > >>> > >>> /* > >>> * vma_flags_is_mm_managed() tests VMA_IO_BIT, which will be removed > >>> * in the next commit. > >>> */ > >>> vma_flags_clear(&flags, VMA_IO_BIT); > >>> if (!vma_flags_is_mm_managed(masked)) { > >>> ... > >>> } > >>> > >>> Is that really worth it? > >>> > >>> I don't think there's really too much confusion intra-patch about that is there? > >> > >> I would do it as above (- the comment, as that is the next patch indeed) and > >> only remove the vma_flags_clear() in the next patch. > >> > >> But in any case, you should spell out that this is only temporary in the patch > >> description :) > > > > And then there's a 'masked' variable that is unused? > > > > You need to have two vma_flags_t variables to be able both clear VMA_IO_BIT > > and use vma_flags_is_mm_managed(). > > > > So the change would have to be > > > > + vma_flags_t masked = *flags; > > + > > + vma_flags_clear(&flags, VMA_IO_BIT); > > + if (!vma_flags_is_mm_managed(&masked)) { > > + ... > > + } > > > > Then: > > > > - vma_flags_t masked = *flags; > > - > > - vma_flags_clear(&flags, VMA_IO_BIT); > > - if (!vma_flags_is_mm_managed(&masked)) { > > + if (!vma_flags_is_mm_managed(flags)) { > > ... > > } > > > > Which doesn't really seem worth it for somebody who is confused between two > > patches mid-series. > > > > But if you feel strongly I can make the change like that? > > Whatever you prefer. Most important thing for me was finding it in the next > patch and being pleasantly surprised ;) I'd rather not then! It was always intended that way, this was all part of a careful dance to ensure correct behaviour right up until the point where we enforce that VMA_IO_BIT is only set when appropriate. I can update the commit message to reflect it. -- Cheers, Lorenzo