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 02D663AAF54; Fri, 2 Oct 2026 14:56:33 +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=1790952995; cv=none; b=qfewKNWBllHv4Z5W3o+gaPBimGHrU349i4loD0QnHpuiVuIv/KRyrcVfYvktbgO2TbIhenvq0rP0SbeH0W8tBlr4d3PuzaBoaV5FlY/mdlUH6XFAsFClEXvKnBfkGbNxMCBSPe0L2T6sdLyJn0khb+x5G0SlQKgzLQ8TuiyWBCQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790952995; c=relaxed/simple; bh=vNF3N3IxUFgjfHwaXFhoUUdmxvTVJaq2s8vGsZwJrtA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tDRRoMZwwKDWQFbkBmzzMF7TsPkbSNJfobuF/S+vlifaw7wbrlV3WadnqzQAOyb51aIXuu/XCcsIroOluRnldBWMDT4bS3ZuQk2lL7RCspcvlfDZ1WaqEpYH9NlMKucJZof1YEOVwmtGfHlMak2n4FEl3J8z1e17T68P9P2dMWQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fdVzgh8v; 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="fdVzgh8v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C88791F00893; Fri, 2 Oct 2026 14:56:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790952993; bh=jQuiTsuvfiP4TjKhygdb17Hd1K9/CkYZDyLUI1EBmwE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=fdVzgh8vzUmdaKUlZe0VUNAIbLSN/FNhbQHH4wzlHFvv+hwCHSicNk7KjrZHYj3Yu iQlLhsYS9ojqwSku1HQOXWnmdKoCu8CHMkE9A7LZ/DH6hiJQldb++n4ez57oVgBl0V So8/jwrVJl3CEjbngowiXAkkkl3yvYCSfnXRCFedPo61Fs2XbO15rdcGoISGxqRB8K jXU4TLmv22BTp6yPLlF2Jpru5HvWTRYFQZfFHeldR1afhWGGXDAezdVopQG8Ave8bR CZFLT49VpC5WBX0wYA8iUka0IczATo+lcmXmrk2MeXbxiJX2meYd90/doZTa6tYh/0 hugq9t44NIjiw== Date: Fri, 2 Oct 2026 15:56:04 +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" , Jaya Kumar , 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 Subject: Re: [PATCH v3 15/40] mm/vma: add vma[_flags]_is_kernel_owned() predicates Message-ID: References: <20260917-b4-mmap-prepare-vma-flag-sanify-v3-0-4583d8a23bca@kernel.org> <20260917-b4-mmap-prepare-vma-flag-sanify-v3-15-4583d8a23bca@kernel.org> <0623ee06-00e5-421e-a24a-ed605abb559b@kernel.org> 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: <0623ee06-00e5-421e-a24a-ed605abb559b@kernel.org> On Thu, Oct 01, 2026 at 02:36:40PM +0200, David Hildenbrand (Arm) wrote: > On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote: > > Rather than referring to VMA flags with uncertain meaning, add a new > > predicate that explicitly describes what possession of the VMA_PFNMAP_BIT > > or VMA_MIXEDMAP_BIT flags mean, and then refer to that function for > > determining VMA mergeability. > > > > Either flag means the contents of the mapping are owned by the kernel, > > usually a driver, rather than by the core mm: the memory may be MMIO, > > kernel-allocated pages or even ordinary pages the driver maps itself, but > > the core must not populate, reclaim, migrate, copy-on-write or merge the > > range on its own initiative. > > > > We initially also include VMA_IO_BIT here, as by implication, these must be > > kernel-owned. (mlock() also sets VMA_IO_BIT transiently on ordinary VMAs > > while locking them, which is addressed later in this series.) > > > > However the intent is to in future remove this, as no mapping should be > > marked as an I/O mapping without also being marked with VMA_PFNMAP_BIT. > > > > This forms the basis of further work intended to improve how we express VMA > > properties such as this. > > > > Also update the VMA userland tests to reflect the change. > > > > No functional change intended. > > Of course I have to bitch about the naming :) Yup :) > > Intuitively: kernel owned vs ... user owned? > > No, it's kernel owned vs core-mm owned. I would say somebody who does: ptr = malloc(4096); Would think of that memory as 'owned' by them in the sense that they control the lifetime, they established its attributes, etc. So indeed, vs. user-owned. > > Which implies core-mm is not part of the kernel? > > Yes, this is confusing. ;) I think what you're missing here is what _creates_ or _establishes_ the mapping. Intuitively, if I do: ptr = kmalloc(GFP_KERNEL); I, whether I am in the core kernel, or a driver, or whatever own it in any meaningful sense of the word. I think the issue here is you're confusing this with other things like the rmap and refcounting, etc. > > I assume you're coming from "map_kernel_pages*", but that's rather "kernel > memory" and not "kernel owned". > > Usually we say "driver owned" when not talking about pagecache/anon. Or user vs. > kernel memory. I think it would only add confusion: VDSO/VVAR, perf ring buffers, shmem mapped via PFN map, uprobes, etc. are all in this category and I doubt people would consider those driver-owned. > > So is it really all about "is this (excluding CoW) no ordinary user memory that > we would track through the rmap" ? VMA_MIXEDMAP_BIT mappings can be refcounted and rmapped so that's not a correct description. The distinction is - who put them there and who's allowed to change them and who owns the lifecycle. > > > > > Signed-off-by: Lorenzo Stoakes (ARM) > > --- > > include/linux/mm.h | 56 ++++++++++++++++++++++++++++++++++++++++- > > tools/testing/vma/include/dup.h | 29 ++++++++++++++++++++- > > 2 files changed, 83 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 2a92193ac6a5..cab29d6e15c1 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -1612,6 +1612,44 @@ static inline bool vma_is_shared_maywrite(const struct vm_area_struct *vma) > > return is_shared_maywrite(&vma->flags); > > } > > > > +/** > > + * vma_flags_is_kernel_owned() - Do the specified VMA flags indicate that the > > + * contents of the VMA are owned by the kernel rather than the core mm? > > + * @flags: The VMA flags to test. > > + * > > + * A kernel-owned mapping is one whose contents are established and controlled > > + * by the kernel, typically a driver, rather than by the core mm's fault and > > + * rmap machinery. > > + * > > + * The mapping may be memory-mapped I/O, kernel-allocated pages or ordinary > > + * pages the owner has chosen to map itself (shmem via a PFN map, for instance). > > + * > > + * In all cases the core mm must not populate, reclaim, migrate, copy-on-write > > + * or merge it of its own accord. > > + * > > + * Pages mapped this way are not necessarily reference counted or map counted. > > + * > > + * Returns: true if the flags indicate a kernel-owned mapping. > > + */ > > +static inline bool vma_flags_is_kernel_owned(const vma_flags_t *flags) > > +{ > > + return vma_flags_test_any(flags, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT, > > + VMA_IO_BIT); > > I thought we have cases where we drivers insert pages and neither set > VMA_PFNMAP_BIT nor VMA_MIXEDMAP_BIT. There were 4 - defio, cmt_speech, uprobes and the bpf arena, and I fixed all of them :) Other than the DAX-only case below of course. It's not correct behaviour and part of the point of this series is to structurally _forbid_ illegal behaviour by drivers. > > I assume vmf_insert_page_mkwrite() is fine because it is DAX doing it (should we > limit this interface to DAX?). That is a DAX-only thing and DAX is precisely a case that should not be kernel-owned (and isn't!) This series actually fixes the FUSE case too, restricting this interface to DAX only seems like a sensible follow up as well. I could also add a patch to this series to do that too if you wanted? -- Cheers, Lorenzo