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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E6749CC6B13 for ; Tue, 13 Oct 2026 07:53:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 53AD010F580; Tue, 13 Oct 2026 07:53:05 +0000 (UTC) Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id C002210E3D9 for ; Mon, 12 Oct 2026 18:24:11 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 70338429E5; Mon, 12 Oct 2026 18:24:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EB211F008A1; Mon, 12 Oct 2026 18:23:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791829451; bh=XFaoCRsSeFrqplzPhC7sYiQbwkNwnjThwg1EUt1kpJ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jtE+F+Qv8Id6B6sok4tUXFo/WttdoAtNDsnYx3FOXrAL8cH9okupFlV8UIia7guEU +vucEDeV2orWOn4vncvKjOHxgLpA4z1i7ajNG9MWZWMFVvN4qyIVzuZeKcX/kEyCrH E/taH25MY4+xXS5peaLpSE7R7Iim8QiaiSCBIYGbdI33SdOJfzFvr3BmyPD17L1aAJ U/0dNzP3xhDe22x9gKDa9ilglbfD3cWxl+IMj1eK+ZgOY9uKMvF9rxkAMBdTJx+kaH UEWib9ZdZm5YRBOs8FNN9IM2uvce7gfClsp4wZPpS8lSb0rbCcbaWuL8XwghfAbqY4 TscCzNvFkg/Kw== Date: Mon, 12 Oct 2026 19:23:24 +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 22/38] mm/mlock: clear VMA_LOCKED_MASK over mmap callback Message-ID: References: <20261009-b4-mmap-prepare-vma-flag-sanify-v5-0-923b70125b1e@kernel.org> <20261009-b4-mmap-prepare-vma-flag-sanify-v5-22-923b70125b1e@kernel.org> <5027aec2-84c1-461e-9f74-0736e2cc6171@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5027aec2-84c1-461e-9f74-0736e2cc6171@kernel.org> X-Mailman-Approved-At: Tue, 13 Oct 2026 07:52:58 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Oct 12, 2026 at 08:19:03PM +0200, David Hildenbrand (Arm) wrote: > On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote: > > Currently there's a confusing mess around VMA_LOCKED_BIT and > > VMA_LOCKONFAULT_BIT. > > > > It is permitted for drivers to set any flags they like, with the VMA > > already possessing lock flags. > > > > This results in the absurd situation of a VMA possessing both > > VMA_SPECIAL_FLAGS and VMA_LOCKED_MASK flags, which is not permitted. > > > > This has resulted in mlock_vma_folio() having a very silly check for this > > scenario to work around it. > > > > There is no need for this - just clear the flags before invoking the hook > > and reinstate them afterwards if they are required. > > > > Nothing relies upon this being set during the mmap operation. > > > > mmap_prepare is unaffected by this so requires no fix. > > > > Reviewed-by: Zi Yan > > Signed-off-by: Lorenzo Stoakes (ARM) > > --- > > mm/internal.h | 9 +-------- > > mm/vma.c | 17 +++++++++++++++++ > > 2 files changed, 18 insertions(+), 8 deletions(-) > > > > diff --git a/mm/internal.h b/mm/internal.h > > index 557e629db8c5..4ae08fedffff 100644 > > --- a/mm/internal.h > > +++ b/mm/internal.h > > @@ -970,14 +970,7 @@ void mlock_folio(struct folio *folio); > > static inline void mlock_vma_folio(struct folio *folio, > > struct vm_area_struct *vma) > > { > > - /* > > - * The VM_SPECIAL check here serves two purposes. > > - * 1) VM_IO check prevents migration from double-counting during mlock. > > - * 2) Although mmap_region() and mlock_fixup() take care that VM_LOCKED > > - * is never left set on a VM_SPECIAL vma, there is an interval while > > - * file->f_op->mmap() is using vm_insert_page(s), when VM_LOCKED may > > - * still be set while VM_SPECIAL bits are added: so ignore it then. > > - */ > > + /* The VM_IO check prevents migration from double-counting during mlock. */ > > if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) == VM_LOCKED)) > > mlock_folio(folio); > > } > > diff --git a/mm/vma.c b/mm/vma.c > > index 39ceb03023e2..4f09fb98a2fd 100644 > > --- a/mm/vma.c > > +++ b/mm/vma.c > > @@ -2607,6 +2607,11 @@ static int __mmap_new_file_vma(struct mmap_state *map, > > if (!map->vm_file->f_op->mmap) > > return 0; > > > > + /* > > + * Driver-specified flags may make the lock flags invalid, so clear > > + * VMA_LOCKED_MASK and reinstate it afterwards if appropriate. > > + */ > > + vma_clear_flags_mask(vma, VMA_LOCKED_MASK); > > error = mmap_file(vma->vm_file, vma); > > map->vm_file = vma->vm_file; > > > > @@ -2629,6 +2634,18 @@ static int __mmap_new_file_vma(struct mmap_state *map, > > return error; > > } > > > > + /* > > + * If the VMA is still eligible for mlock(), reinstate any original > > + * VMA_LOCKED_BIT and/or VMA_LOCKONFAULT_BIT flags. > > + */ > > + if (vma_supports_mlock(vma)) { > > + const vma_flags_t mask = > > + vma_flags_and_mask(&map->vma_flags, > > + VMA_LOCKED_MASK); > > I'd just have at least the = vma_flags_and_mask on the same line. It's ok to > exceed 80 chars. I've had people yell at me about this before on review :) you can't really win. Since I'm doing a respin anyway I can put it on one line. > > > Acked-by: David Hildenbrand (Arm) Thanks! -- Cheers, Lorenzo