From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Leon Romanovsky <leon@kernel.org>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Doug Gilbert <dgilbert@interlog.com>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <mkp@kernel.org>,
Simona Vetter <simona@ffwll.ch>, Helge Deller <deller@gmx.de>,
Sebastian Reichel <sre@kernel.org>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry@kernel.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Will Deacon <will@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Nick Piggin <npiggin@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oupton@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Anup Patel <anup@brainfault.org>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <baoquan.he@linux.dev>,
Youngjun Park <youngjun.park@lge.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Chengming Zhou <chengming.zhou@linux.dev>,
Michal Hocko <mhocko@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>, Xu Xin <xu.xin@linux.dev>,
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 <ihor.solodrai@linux.dev>,
Bert Karwatzki <spasswolf@web.de>
Subject: Re: [PATCH v5 07/38] mm: add mmap action for discontiguous kernel page mapping
Date: Mon, 12 Oct 2026 18:46:20 +0100 [thread overview]
Message-ID: <as0S-4wDLCJGEItq@gremlin> (raw)
In-Reply-To: <56cc2787-134b-48f0-a9e2-840f57b28607@kernel.org>
On Mon, Oct 12, 2026 at 05:03:02PM +0200, David Hildenbrand (Arm) wrote:
> On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote:
> > The existing kernel page mapping mmap actions allow for partial and full
> > mapping of an array of struct page pointers.
> >
> > However some drivers require the mapping of discontiguous ranges. Permit
> > this by providing discontig_kernel_page_ops which allows a driver to
> > specify how the operation should begin and how batches of pages should be
> > retrieved.
> >
> > It uses the minimum exposed interface to do so, providing address, page
> > offset and both vm_private_data state and a local private state object.
> >
> > ops->init can establish state for the operation, and ops->get outputs the
> > pages to map and their count. Should an error arise the core unmaps the
> > VMA, invoking vm_ops->close, which is therefore where any state established
> > by ops->init is released.
> >
> > Also update the compatibility layer to do this too via
> > compat_mmap_action_abort().
> >
> > Batches may not exceed the VMA, but may map less than its full range in
> > case the driver wishes to allow the user to map an area larger than the
> > available data.
> >
> > To use it, users invoke mmap_action_map_discontig_kernel_pages() with
> > initial local private state and a set of operations.
> >
> > Users can then use one of the provided helper functions to perform an
> > action:
> >
> > * discontig_kernel_map_abort() - Abort and leave the mapping as it has
> > been accumulated so far.
> > * discontig_kernel_map_page() - Map a single page, or a compound page given
> > its head page.
> > * discontig_kernel_map_page_range() - Maps a struct page ** array of a
> > specified count, mapping only those pages which fit in the VMA.
> >
> > While here, update vm_insert_page() and vm_insert_pages() to assert the
> > mmap write lock is held rather than the bizarre assert !mmap_read_trylock()
> > and use the new VMA API so all code paths are consistent.
> >
> > Also convert a BUG_ON() to a VM_WARN_ON_ONCE() in vm_insert_page().
> >
> > The userland VMA tests are updated accordingly.
> >
> > Acked-by: Zi Yan <ziy@nvidia.com>
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>
>
> Finally finding time to go over this. In the future I want to have more time to
> review such massive series, as it causes severe stress to be forced to review
> this last minute before it goes upstream.
>
> So if I push back in order to give me some more room to breathe in the future
> it's nothing personal, I just have to keep my sanity somehow.
>
> I hate being forced to review because we pick up stuff way to early. There is
> just way too much other stuff going on.
>
> I'm planning on picking up most stuff I maintain in the next cycle. For
> cross-component stuff (esp. VMA) I expect Andrew to pick stuff up until we
> tackle this once cycle later.
OK I understand, sorry for sending such a large series.
I already delayed it from last cycle and sent early in rc2, but I understand
there's been a lot of volume in this one.
I've been working evenings and weekends myself to keep up with review (and
failing), so I get how thankless it can be (LPC was also unhelpfully timed!)
I will try to split things out more in future, this had a lot of dependencies so
it wasn't clear that made sense + wouldn't just cause more stress over a longer
period otherwise.
>
>
> > +static inline
> > +void mmap_action_map_discontig_kernel_pages(struct vm_area_desc *desc,
> > + void *init_private, const struct discontig_kernel_page_ops *ops)
> > +{
> > + struct mmap_action *action = &desc->action;
> > +
> > + action->type = MMAP_DISCONTIG_KERNEL_PAGES;
> > + action->map_kernel_discontig.init_private = init_private;
> > + action->map_kernel_discontig.ops = ops;
> > +}
> > +
> > int mmap_action_prepare(struct vm_area_desc *desc);
> > int mmap_action_complete(struct vm_area_struct *vma,
> > struct mmap_action *action, bool is_compat);
>
> There is a mixture of two tab vs. different in your changes.
OK. mm is fairly inconsistent about this, I will convert all to 2 tabs.
>
> >
> > +static inline void
> > +discontig_kernel_map_abort(struct discontig_kernel_page_state *state)
> > +{
> > + state->action = DISCONTIG_KERNEL_PAGE_ABORT;
> > +}
> > +
> > +static inline void
> > +discontig_kernel_map_page(struct discontig_kernel_page_state *state,
> > + struct page *page)
> > +{
> > + struct folio *folio = page_folio(page);
> > +
> > + if (folio_test_large(folio)) {
> > + VM_WARN_ON_ONCE(page != folio_page(folio, 0));
> > + state->action = DISCONTIG_KERNEL_PAGE_MAP_COMPOUND_PAGE;
> > + state->__folio = folio;
> > + state->__nr_pages = min(state->nr_pages_remain,
> > + folio_nr_pages(folio));
> > + } else {
> > + state->action = DISCONTIG_KERNEL_PAGE_MAP_PAGE;
> > + state->__page = page;
> > + state->__nr_pages = 1;
> > + }
>
> Why are both separate? Isn't it sufficient to represent that through _page +
> _nr_pages > 1 ? See below.
Ack yup that works.
>
> > +}
> > +
> > +static inline void
> > +discontig_kernel_map_page_range(struct discontig_kernel_page_state *state,
> > + struct page **page_arr, unsigned long nr_pages)
>
> Is this actually "map_pages"? A range is rather a number of consectuive pages
> part of the same folio/compound page, no?
>
> (we call insert_pages() later ... )
Sure, can change.
>
> > +{
> > + state->action = DISCONTIG_KERNEL_PAGE_MAP_PAGE_RANGE;
> > + state->__page_arr = page_arr;
> > + state->__nr_pages = min(nr_pages, state->nr_pages_remain);
>
> So we expect all of them to be non-compound?
Yup this matches existing insert_pages() behaviour.
>
>
> [...]
>
> > diff --git a/mm/internal.h b/mm/internal.h
> > index fc4e249e2343..557e629db8c5 100644
> > --- a/mm/internal.h
> > +++ b/mm/internal.h
> > @@ -1515,6 +1515,9 @@ int simple_ioremap_prepare(struct vm_area_desc *desc);
> > int map_kernel_pages_prepare(struct vm_area_desc *desc);
> > int map_kernel_pages_complete(struct vm_area_struct *vma,
> > struct mmap_action *action);
> > +int map_discontig_kernel_pages_prepare(struct vm_area_desc *desc);
> > +int map_discontig_kernel_pages_complete(struct vm_area_struct *vma,
> > + struct mmap_action *action);
> >
> > static inline int io_remap_pfn_range_prepare(struct vm_area_desc *desc)
> > {
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 448342883e9d..e5c1d1c35bc7 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -2599,27 +2599,34 @@ int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> >
> > if (!range_in_vma(vma, addr, end))
> > return -EFAULT;
> > - if (!(vma->vm_flags & VM_MIXEDMAP)) {
> > - VM_WARN_ON_ONCE(mmap_read_trylock(vma->vm_mm));
> > - VM_WARN_ON_ONCE(vma->vm_flags & VM_PFNMAP);
> > - vm_flags_set(vma, VM_MIXEDMAP);
> > + if (!vma_test(vma, VMA_MIXEDMAP_BIT)) {
> > + mmap_assert_write_locked(vma->vm_mm);
> > + VM_WARN_ON_ONCE(vma_test(vma, VMA_PFNMAP_BIT));
>
> I would prefer to have these changes in a separate patch. Or is it strictly
> required to have this in this very patch?
That was because Suren raised the 'assert on mmap_read_trylock()' thing and I
wanted to get the other cases here to be consistent.
I will split it out into another patch.
>
>
> > + vma_start_write(vma);
> > + vma_set_flags(vma, VMA_MIXEDMAP_BIT);
> > }
> > /* Defer page refcount checking till we're about to map that page. */
> > return insert_pages(vma, addr, pages, num, vma->vm_page_prot);
> > }
> > EXPORT_SYMBOL(vm_insert_pages);
> >
> > +static void __map_kernel_pages_prepare(struct vm_area_desc *desc)
> > +{
> > + if (vma_desc_test(desc, VMA_MIXEDMAP_BIT))
> > + return;
> > +
> > + mmap_assert_write_locked(desc->mm);
> > + VM_WARN_ON_ONCE(vma_desc_test(desc, VMA_PFNMAP_BIT));
> > + vma_desc_set_flags(desc, VMA_MIXEDMAP_BIT);
> > +}
> > +
> > int map_kernel_pages_prepare(struct vm_area_desc *desc)
> > {
> > const struct mmap_action *action = &desc->action;
> > const unsigned long addr = action->map_kernel.start;
> > unsigned long nr_pages, end;
> >
> > - if (!vma_desc_test(desc, VMA_MIXEDMAP_BIT)) {
> > - VM_WARN_ON_ONCE(mmap_read_trylock(desc->mm));
> > - VM_WARN_ON_ONCE(vma_desc_test(desc, VMA_PFNMAP_BIT));
> > - vma_desc_set_flags(desc, VMA_MIXEDMAP_BIT);
> > - }
> > + __map_kernel_pages_prepare(desc);
> >
> > nr_pages = action->map_kernel.nr_pages;
> > end = addr + PAGE_SIZE * nr_pages;
> > @@ -2640,6 +2647,98 @@ int map_kernel_pages_complete(struct vm_area_struct *vma,
> > &nr_pages, vma->vm_page_prot);
> > }
> >
> > +int map_discontig_kernel_pages_prepare(struct vm_area_desc *desc)
> > +{
> > + const struct mmap_action *action = &desc->action;
> > + const struct discontig_kernel_page_ops *ops =
> > + action->map_kernel_discontig.ops;
> > +
> > + /* At minimum need to be able to get pages. */
> > + if (WARN_ON_ONCE(!ops || !ops->get))
> > + return -EINVAL;
> > +
> > + __map_kernel_pages_prepare(desc);
> > + return 0;
> > +}
> > +
> > +static int apply_discontig_action(struct vm_area_struct *vma,
> > + struct discontig_kernel_page_state *state)
> > +{
> > + unsigned long nr_pages = state->__nr_pages;
> > + unsigned long addr = state->addr;
> > + unsigned long i;
> > +
> > + if (state->action == DISCONTIG_KERNEL_PAGE_MAP_PAGE)
> > + return insert_page(vma, addr, state->__page,
> > + vma->vm_page_prot, /*mkwrite=*/false);
> > + if (state->action == DISCONTIG_KERNEL_PAGE_MAP_PAGE_RANGE)
> > + return insert_pages(vma, addr, state->__page_arr,
> > + &nr_pages, vma->vm_page_prot);
> > +
> > + /* Compound folio - have to iterate through each page. */
> > + for (i = 0; i < nr_pages; i++, addr += PAGE_SIZE) {
> > + struct page *page = folio_page(state->__folio, i);
> > + int err;
> > +
> > + err = insert_page(vma, addr, page, vma->vm_page_prot,
> > + /*mkwrite=*/false);
> > + if (err)
> > + return err;
> > + }
>
> Summarizing some of my comments below, I wonder if this could be:
>
> DISCONTIG_KERNEL_PAGE_MAP_PAGES - array of individual apges
> DISCONTIG_KERNEL_PAGE_MAP_CONTIG_PAGES - 1..N contiguous pages
OK.
>
>
> if (state->action == DISCONTIG_KERNEL_PAGE_MAP_PAGES)
> return insert_pages(vma, addr, state->__page_arr,
> &nr_pages, vma->vm_page_prot);
>
> VM_WARN_ON_ONCE(state->action != DISCONTIG_KERNEL_PAGE_MAP_CONTIG_PAGES)
> for (i = 0; i < nr_pages; i++, addr += PAGE_SIZE) {
> struct page *page = state->__page + i;
> int err;
>
> err = insert_page(vma, addr, page, vma->vm_page_prot,
> /*mkwrite=*/false);
> if (err)
> return err;
> }
> ...
OK. Will respin for v6.
>
> --
> Cheers,
>
> David
--
Cheers, Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Doug Gilbert <dgilbert@interlog.com>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <mkp@kernel.org>,
Simona Vetter <simona@ffwll.ch>, Helge Deller <deller@gmx.de>,
Sebastian Reichel <sre@kernel.org>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry@kernel.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Will Deacon <will@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Nick Piggin <npiggin@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oupton@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Anup Patel <anup@brainfault.org>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <baoquan.he@linux.dev>,
Youngjun Park <youngjun.park@lge.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Chengming Zhou <chengming.zhou@linux.dev>,
Michal Hocko <mhocko@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>, Xu Xin <xu.xin@linux.dev>,
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 <ihor.solodrai@linux.dev>,
Bert Karwatzki <spasswolf@web.de>
Subject: Re: [PATCH v5 07/38] mm: add mmap action for discontiguous kernel page mapping
Date: Mon, 12 Oct 2026 18:46:20 +0100 [thread overview]
Message-ID: <as0S-4wDLCJGEItq@gremlin> (raw)
In-Reply-To: <56cc2787-134b-48f0-a9e2-840f57b28607@kernel.org>
On Mon, Oct 12, 2026 at 05:03:02PM +0200, David Hildenbrand (Arm) wrote:
> On 10/9/26 20:04, Lorenzo Stoakes (ARM) wrote:
> > The existing kernel page mapping mmap actions allow for partial and full
> > mapping of an array of struct page pointers.
> >
> > However some drivers require the mapping of discontiguous ranges. Permit
> > this by providing discontig_kernel_page_ops which allows a driver to
> > specify how the operation should begin and how batches of pages should be
> > retrieved.
> >
> > It uses the minimum exposed interface to do so, providing address, page
> > offset and both vm_private_data state and a local private state object.
> >
> > ops->init can establish state for the operation, and ops->get outputs the
> > pages to map and their count. Should an error arise the core unmaps the
> > VMA, invoking vm_ops->close, which is therefore where any state established
> > by ops->init is released.
> >
> > Also update the compatibility layer to do this too via
> > compat_mmap_action_abort().
> >
> > Batches may not exceed the VMA, but may map less than its full range in
> > case the driver wishes to allow the user to map an area larger than the
> > available data.
> >
> > To use it, users invoke mmap_action_map_discontig_kernel_pages() with
> > initial local private state and a set of operations.
> >
> > Users can then use one of the provided helper functions to perform an
> > action:
> >
> > * discontig_kernel_map_abort() - Abort and leave the mapping as it has
> > been accumulated so far.
> > * discontig_kernel_map_page() - Map a single page, or a compound page given
> > its head page.
> > * discontig_kernel_map_page_range() - Maps a struct page ** array of a
> > specified count, mapping only those pages which fit in the VMA.
> >
> > While here, update vm_insert_page() and vm_insert_pages() to assert the
> > mmap write lock is held rather than the bizarre assert !mmap_read_trylock()
> > and use the new VMA API so all code paths are consistent.
> >
> > Also convert a BUG_ON() to a VM_WARN_ON_ONCE() in vm_insert_page().
> >
> > The userland VMA tests are updated accordingly.
> >
> > Acked-by: Zi Yan <ziy@nvidia.com>
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>
>
> Finally finding time to go over this. In the future I want to have more time to
> review such massive series, as it causes severe stress to be forced to review
> this last minute before it goes upstream.
>
> So if I push back in order to give me some more room to breathe in the future
> it's nothing personal, I just have to keep my sanity somehow.
>
> I hate being forced to review because we pick up stuff way to early. There is
> just way too much other stuff going on.
>
> I'm planning on picking up most stuff I maintain in the next cycle. For
> cross-component stuff (esp. VMA) I expect Andrew to pick stuff up until we
> tackle this once cycle later.
OK I understand, sorry for sending such a large series.
I already delayed it from last cycle and sent early in rc2, but I understand
there's been a lot of volume in this one.
I've been working evenings and weekends myself to keep up with review (and
failing), so I get how thankless it can be (LPC was also unhelpfully timed!)
I will try to split things out more in future, this had a lot of dependencies so
it wasn't clear that made sense + wouldn't just cause more stress over a longer
period otherwise.
>
>
> > +static inline
> > +void mmap_action_map_discontig_kernel_pages(struct vm_area_desc *desc,
> > + void *init_private, const struct discontig_kernel_page_ops *ops)
> > +{
> > + struct mmap_action *action = &desc->action;
> > +
> > + action->type = MMAP_DISCONTIG_KERNEL_PAGES;
> > + action->map_kernel_discontig.init_private = init_private;
> > + action->map_kernel_discontig.ops = ops;
> > +}
> > +
> > int mmap_action_prepare(struct vm_area_desc *desc);
> > int mmap_action_complete(struct vm_area_struct *vma,
> > struct mmap_action *action, bool is_compat);
>
> There is a mixture of two tab vs. different in your changes.
OK. mm is fairly inconsistent about this, I will convert all to 2 tabs.
>
> >
> > +static inline void
> > +discontig_kernel_map_abort(struct discontig_kernel_page_state *state)
> > +{
> > + state->action = DISCONTIG_KERNEL_PAGE_ABORT;
> > +}
> > +
> > +static inline void
> > +discontig_kernel_map_page(struct discontig_kernel_page_state *state,
> > + struct page *page)
> > +{
> > + struct folio *folio = page_folio(page);
> > +
> > + if (folio_test_large(folio)) {
> > + VM_WARN_ON_ONCE(page != folio_page(folio, 0));
> > + state->action = DISCONTIG_KERNEL_PAGE_MAP_COMPOUND_PAGE;
> > + state->__folio = folio;
> > + state->__nr_pages = min(state->nr_pages_remain,
> > + folio_nr_pages(folio));
> > + } else {
> > + state->action = DISCONTIG_KERNEL_PAGE_MAP_PAGE;
> > + state->__page = page;
> > + state->__nr_pages = 1;
> > + }
>
> Why are both separate? Isn't it sufficient to represent that through _page +
> _nr_pages > 1 ? See below.
Ack yup that works.
>
> > +}
> > +
> > +static inline void
> > +discontig_kernel_map_page_range(struct discontig_kernel_page_state *state,
> > + struct page **page_arr, unsigned long nr_pages)
>
> Is this actually "map_pages"? A range is rather a number of consectuive pages
> part of the same folio/compound page, no?
>
> (we call insert_pages() later ... )
Sure, can change.
>
> > +{
> > + state->action = DISCONTIG_KERNEL_PAGE_MAP_PAGE_RANGE;
> > + state->__page_arr = page_arr;
> > + state->__nr_pages = min(nr_pages, state->nr_pages_remain);
>
> So we expect all of them to be non-compound?
Yup this matches existing insert_pages() behaviour.
>
>
> [...]
>
> > diff --git a/mm/internal.h b/mm/internal.h
> > index fc4e249e2343..557e629db8c5 100644
> > --- a/mm/internal.h
> > +++ b/mm/internal.h
> > @@ -1515,6 +1515,9 @@ int simple_ioremap_prepare(struct vm_area_desc *desc);
> > int map_kernel_pages_prepare(struct vm_area_desc *desc);
> > int map_kernel_pages_complete(struct vm_area_struct *vma,
> > struct mmap_action *action);
> > +int map_discontig_kernel_pages_prepare(struct vm_area_desc *desc);
> > +int map_discontig_kernel_pages_complete(struct vm_area_struct *vma,
> > + struct mmap_action *action);
> >
> > static inline int io_remap_pfn_range_prepare(struct vm_area_desc *desc)
> > {
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 448342883e9d..e5c1d1c35bc7 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -2599,27 +2599,34 @@ int vm_insert_pages(struct vm_area_struct *vma, unsigned long addr,
> >
> > if (!range_in_vma(vma, addr, end))
> > return -EFAULT;
> > - if (!(vma->vm_flags & VM_MIXEDMAP)) {
> > - VM_WARN_ON_ONCE(mmap_read_trylock(vma->vm_mm));
> > - VM_WARN_ON_ONCE(vma->vm_flags & VM_PFNMAP);
> > - vm_flags_set(vma, VM_MIXEDMAP);
> > + if (!vma_test(vma, VMA_MIXEDMAP_BIT)) {
> > + mmap_assert_write_locked(vma->vm_mm);
> > + VM_WARN_ON_ONCE(vma_test(vma, VMA_PFNMAP_BIT));
>
> I would prefer to have these changes in a separate patch. Or is it strictly
> required to have this in this very patch?
That was because Suren raised the 'assert on mmap_read_trylock()' thing and I
wanted to get the other cases here to be consistent.
I will split it out into another patch.
>
>
> > + vma_start_write(vma);
> > + vma_set_flags(vma, VMA_MIXEDMAP_BIT);
> > }
> > /* Defer page refcount checking till we're about to map that page. */
> > return insert_pages(vma, addr, pages, num, vma->vm_page_prot);
> > }
> > EXPORT_SYMBOL(vm_insert_pages);
> >
> > +static void __map_kernel_pages_prepare(struct vm_area_desc *desc)
> > +{
> > + if (vma_desc_test(desc, VMA_MIXEDMAP_BIT))
> > + return;
> > +
> > + mmap_assert_write_locked(desc->mm);
> > + VM_WARN_ON_ONCE(vma_desc_test(desc, VMA_PFNMAP_BIT));
> > + vma_desc_set_flags(desc, VMA_MIXEDMAP_BIT);
> > +}
> > +
> > int map_kernel_pages_prepare(struct vm_area_desc *desc)
> > {
> > const struct mmap_action *action = &desc->action;
> > const unsigned long addr = action->map_kernel.start;
> > unsigned long nr_pages, end;
> >
> > - if (!vma_desc_test(desc, VMA_MIXEDMAP_BIT)) {
> > - VM_WARN_ON_ONCE(mmap_read_trylock(desc->mm));
> > - VM_WARN_ON_ONCE(vma_desc_test(desc, VMA_PFNMAP_BIT));
> > - vma_desc_set_flags(desc, VMA_MIXEDMAP_BIT);
> > - }
> > + __map_kernel_pages_prepare(desc);
> >
> > nr_pages = action->map_kernel.nr_pages;
> > end = addr + PAGE_SIZE * nr_pages;
> > @@ -2640,6 +2647,98 @@ int map_kernel_pages_complete(struct vm_area_struct *vma,
> > &nr_pages, vma->vm_page_prot);
> > }
> >
> > +int map_discontig_kernel_pages_prepare(struct vm_area_desc *desc)
> > +{
> > + const struct mmap_action *action = &desc->action;
> > + const struct discontig_kernel_page_ops *ops =
> > + action->map_kernel_discontig.ops;
> > +
> > + /* At minimum need to be able to get pages. */
> > + if (WARN_ON_ONCE(!ops || !ops->get))
> > + return -EINVAL;
> > +
> > + __map_kernel_pages_prepare(desc);
> > + return 0;
> > +}
> > +
> > +static int apply_discontig_action(struct vm_area_struct *vma,
> > + struct discontig_kernel_page_state *state)
> > +{
> > + unsigned long nr_pages = state->__nr_pages;
> > + unsigned long addr = state->addr;
> > + unsigned long i;
> > +
> > + if (state->action == DISCONTIG_KERNEL_PAGE_MAP_PAGE)
> > + return insert_page(vma, addr, state->__page,
> > + vma->vm_page_prot, /*mkwrite=*/false);
> > + if (state->action == DISCONTIG_KERNEL_PAGE_MAP_PAGE_RANGE)
> > + return insert_pages(vma, addr, state->__page_arr,
> > + &nr_pages, vma->vm_page_prot);
> > +
> > + /* Compound folio - have to iterate through each page. */
> > + for (i = 0; i < nr_pages; i++, addr += PAGE_SIZE) {
> > + struct page *page = folio_page(state->__folio, i);
> > + int err;
> > +
> > + err = insert_page(vma, addr, page, vma->vm_page_prot,
> > + /*mkwrite=*/false);
> > + if (err)
> > + return err;
> > + }
>
> Summarizing some of my comments below, I wonder if this could be:
>
> DISCONTIG_KERNEL_PAGE_MAP_PAGES - array of individual apges
> DISCONTIG_KERNEL_PAGE_MAP_CONTIG_PAGES - 1..N contiguous pages
OK.
>
>
> if (state->action == DISCONTIG_KERNEL_PAGE_MAP_PAGES)
> return insert_pages(vma, addr, state->__page_arr,
> &nr_pages, vma->vm_page_prot);
>
> VM_WARN_ON_ONCE(state->action != DISCONTIG_KERNEL_PAGE_MAP_CONTIG_PAGES)
> for (i = 0; i < nr_pages; i++, addr += PAGE_SIZE) {
> struct page *page = state->__page + i;
> int err;
>
> err = insert_page(vma, addr, page, vma->vm_page_prot,
> /*mkwrite=*/false);
> if (err)
> return err;
> }
> ...
OK. Will respin for v6.
>
> --
> Cheers,
>
> David
--
Cheers, Lorenzo
--
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv
next prev parent reply other threads:[~2026-10-12 17:47 UTC|newest]
Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 18:03 [PATCH v5 00/38] mm: make VMA flag semantics explicit, eliminate VM_SPECIAL Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` [PATCH v5 01/38] mm/vma: fix mmap_prepare file handling, remove file_doesnt_need_get Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` Lorenzo Stoakes (ARM)
2026-10-09 18:24 ` sashiko-bot
2026-10-09 18:03 ` [PATCH v5 02/38] mm/vma: introduce and use vma_[flags_]can_merge() Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` Lorenzo Stoakes (ARM)
2026-10-09 18:21 ` sashiko-bot
2026-10-09 18:03 ` [PATCH v5 03/38] mm: consistently validate VMA state after mmap[_prepare] hooks Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` Lorenzo Stoakes (ARM)
2026-10-09 18:33 ` sashiko-bot
2026-10-09 18:03 ` [PATCH v5 04/38] mm/vma: ensure mmap_prepare doesn't set actions on a mergeable vma Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` Lorenzo Stoakes (ARM)
2026-10-09 18:22 ` sashiko-bot
2026-10-09 18:03 ` [PATCH v5 05/38] mm: make map_kernel_pages_[prepare,complete] internal and unexported Lorenzo Stoakes (ARM)
2026-10-09 18:03 ` Lorenzo Stoakes (ARM)
2026-10-09 18:20 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 06/38] mm/vma: tidy up map kernel pages enum values Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:20 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 07/38] mm: add mmap action for discontiguous kernel page mapping Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:29 ` sashiko-bot
2026-10-12 15:03 ` David Hildenbrand (Arm)
2026-10-12 15:03 ` David Hildenbrand (Arm)
2026-10-12 17:46 ` Lorenzo Stoakes (ARM) [this message]
2026-10-12 17:46 ` Lorenzo Stoakes (ARM)
2026-10-12 19:02 ` David Hildenbrand (Arm)
2026-10-12 19:02 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 08/38] docs: filesystems: update mmap_prepare docs for discontig kernel pgs Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:19 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 09/38] drivers/usb/mon: update to use mmap_prepare + map kernel pages Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:32 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 10/38] infiniband: update hfi1 to use remap_vmalloc_range() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:30 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 11/38] selinux: reject writable opens of policy file, drop mmap shared/write check Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:26 ` sashiko-bot
2026-10-12 15:06 ` David Hildenbrand (Arm)
2026-10-12 15:06 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 12/38] ALSA: pcm: use vm_insert_page() to map PCM status page Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:38 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 13/38] bpf: arena: mark arena_map_mmap() mappings VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:30 ` sashiko-bot
2026-10-12 15:08 ` David Hildenbrand (Arm)
2026-10-12 15:08 ` David Hildenbrand (Arm)
2026-10-12 15:55 ` Lorenzo Stoakes (ARM)
2026-10-12 15:55 ` Lorenzo Stoakes (ARM)
2026-10-12 18:56 ` David Hildenbrand (Arm)
2026-10-12 18:56 ` David Hildenbrand (Arm)
2026-10-12 19:11 ` Lorenzo Stoakes (ARM)
2026-10-12 19:11 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 14/38] mm/vma: add vma[_flags]_is_mm_managed() predicates Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:26 ` sashiko-bot
2026-10-12 18:06 ` David Hildenbrand (Arm)
2026-10-12 18:06 ` David Hildenbrand (Arm)
2026-10-12 18:15 ` Lorenzo Stoakes (ARM)
2026-10-12 18:15 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 15/38] mm/vma: only allow mmap to clear VMA_MAYWRITE_BIT if not mm-managed Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:25 ` sashiko-bot
2026-10-12 18:07 ` David Hildenbrand (Arm)
2026-10-12 18:07 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 16/38] mm/vma: add and use vma_[flags]_is_fixed_mapping Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:29 ` sashiko-bot
2026-10-12 18:11 ` David Hildenbrand (Arm)
2026-10-12 18:11 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 17/38] scsi: sg: convert mmap hook to mmap_prepare and rework Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:44 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 18/38] fbdev: defio: assert FBINFO_VIRTFB, drop VM_IO, add VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:36 ` sashiko-bot
2026-10-12 18:12 ` David Hildenbrand (Arm)
2026-10-12 18:12 ` David Hildenbrand (Arm)
2026-10-12 18:12 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 19/38] HSI: cmt_speech: convert mmap hook to mmap_prepare, refactor Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:39 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 20/38] mm/gup: error out early on !VMA_MAYREAD_BIT VMAs Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:34 ` sashiko-bot
2026-10-12 18:15 ` David Hildenbrand (Arm)
2026-10-12 18:15 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 21/38] uprobes: remove VM_IO, set VM_MIXEDMAP for mapped kernel pages Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:41 ` sashiko-bot
2026-10-12 18:16 ` David Hildenbrand (Arm)
2026-10-12 18:16 ` David Hildenbrand (Arm)
2026-10-12 18:20 ` Lorenzo Stoakes (ARM)
2026-10-12 18:20 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 22/38] mm/mlock: clear VMA_LOCKED_MASK over mmap callback Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:40 ` sashiko-bot
2026-10-12 18:19 ` David Hildenbrand (Arm)
2026-10-12 18:19 ` David Hildenbrand (Arm)
2026-10-12 18:23 ` Lorenzo Stoakes (ARM)
2026-10-12 18:23 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 23/38] mm/mlock: eliminate weird VMA_IO_BIT abuse and simplify Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:49 ` sashiko-bot
2026-10-12 18:23 ` David Hildenbrand (Arm)
2026-10-12 18:23 ` David Hildenbrand (Arm)
2026-10-12 18:38 ` Lorenzo Stoakes (ARM)
2026-10-12 18:38 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 24/38] mm/vma: enforce that mm-managed mappings may not set VMA_IO_BIT Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:36 ` sashiko-bot
2026-10-12 18:25 ` David Hildenbrand (Arm)
2026-10-12 18:25 ` David Hildenbrand (Arm)
2026-10-12 18:35 ` Lorenzo Stoakes (ARM)
2026-10-12 18:35 ` Lorenzo Stoakes (ARM)
2026-10-12 18:39 ` David Hildenbrand (Arm)
2026-10-12 18:39 ` David Hildenbrand (Arm)
2026-10-12 18:48 ` Lorenzo Stoakes (ARM)
2026-10-12 18:48 ` Lorenzo Stoakes (ARM)
2026-10-12 18:51 ` David Hildenbrand (Arm)
2026-10-12 18:51 ` David Hildenbrand (Arm)
2026-10-12 18:57 ` Lorenzo Stoakes (ARM)
2026-10-12 18:57 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 25/38] mm: remove VMA_IO_BIT check in vma[_flags]_is_mm_managed() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:43 ` sashiko-bot
2026-10-12 18:31 ` David Hildenbrand (Arm)
2026-10-12 18:31 ` David Hildenbrand (Arm)
2026-10-12 18:42 ` Lorenzo Stoakes (ARM)
2026-10-12 18:42 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 26/38] mm: remove hugetlb_inline.h Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:38 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 27/38] mm: rename is_vm_hugetlb_page() to vma_is_hugetlb() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:40 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 28/38] mm: drop some redundant checks around hugetlb VMAs Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:43 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 29/38] mm/madvise: update is_valid_guard_vma() to use vma_can_merge() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:44 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 30/38] mm/vma: introduce vma[_flags]_is_mm_backed() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:48 ` sashiko-bot
2026-10-12 18:45 ` David Hildenbrand (Arm)
2026-10-12 18:45 ` David Hildenbrand (Arm)
2026-10-12 18:46 ` David Hildenbrand (Arm)
2026-10-12 18:46 ` David Hildenbrand (Arm)
2026-10-13 10:57 ` Lorenzo Stoakes (ARM)
2026-10-13 10:57 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 31/38] mm/uffd: use predicates for userfaultfd checks Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:46 ` sashiko-bot
2026-10-12 18:48 ` David Hildenbrand (Arm)
2026-10-12 18:48 ` David Hildenbrand (Arm)
2026-10-13 11:29 ` Lorenzo Stoakes (ARM)
2026-10-13 11:29 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 32/38] mm/madvise: use predicates for madvise(..., MADV_DOFORK) Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:47 ` sashiko-bot
2026-10-12 18:48 ` David Hildenbrand (Arm)
2026-10-12 18:48 ` David Hildenbrand (Arm)
2026-10-09 18:04 ` [PATCH v5 33/38] mm: eliminate VMA_SPECIAL_FLAGS usage when hugetlb explicitly tested Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:47 ` sashiko-bot
2026-10-12 18:49 ` David Hildenbrand (Arm)
2026-10-12 18:49 ` David Hildenbrand (Arm)
2026-10-13 11:43 ` Lorenzo Stoakes (ARM)
2026-10-13 11:43 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 34/38] mm: eliminate VMA_SPECIAL_FLAGS check in lru_gen_look_around() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:49 ` sashiko-bot
2026-10-12 18:50 ` David Hildenbrand (Arm)
2026-10-12 18:50 ` David Hildenbrand (Arm)
2026-10-13 11:45 ` Lorenzo Stoakes (ARM)
2026-10-13 11:45 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 35/38] mm: avoid use of VMA_SPECIAL_FLAGS in migrate_vma_setup() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:50 ` sashiko-bot
2026-10-12 18:52 ` David Hildenbrand (Arm)
2026-10-12 18:52 ` David Hildenbrand (Arm)
2026-10-13 11:46 ` Lorenzo Stoakes (ARM)
2026-10-13 11:46 ` Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` [PATCH v5 36/38] mm: eliminate VM_SPECIAL, VMA_SPECIAL_FLAGS Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:48 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 37/38] fuse: dax: do not set VM_MIXEDMAP Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:56 ` sashiko-bot
2026-10-09 18:04 ` [PATCH v5 38/38] mm/huge_memory: remove vma_is_special_huge() Lorenzo Stoakes (ARM)
2026-10-09 18:04 ` Lorenzo Stoakes (ARM)
2026-10-09 18:52 ` sashiko-bot
2026-10-12 18:53 ` David Hildenbrand (Arm)
2026-10-12 18:53 ` David Hildenbrand (Arm)
2026-10-10 22:00 ` [PATCH v5 00/38] mm: make VMA flag semantics explicit, eliminate VM_SPECIAL Andrew Morton
2026-10-10 22:00 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as0S-4wDLCJGEItq@gremlin \
--to=ljs@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=acme@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=andrii@kernel.org \
--cc=aneesh.kumar@kernel.org \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=byungchul@sk.com \
--cc=catalin.marinas@arm.com \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@kernel.org \
--cc=deller@gmx.de \
--cc=dennis.dalessandro@cornelisnetworks.com \
--cc=dev.jain@arm.com \
--cc=dgilbert@interlog.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eddyz87@gmail.com \
--cc=frankja@linux.ibm.com \
--cc=fuse-devel@lists.linux.dev \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=hca@linux.ibm.com \
--cc=ihor.solodrai@linux.dev \
--cc=imbrenda@linux.ibm.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joshua.hahnjy@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kas@kernel.org \
--cc=kasong@tencent.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=lance.yang@linux.dev \
--cc=leon@kernel.org \
--cc=liam@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maddy@linux.ibm.com \
--cc=mark.rutland@arm.com \
--cc=matthew.brost@intel.com \
--cc=maz@kernel.org \
--cc=memxor@gmail.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=miklos@szeredi.hu \
--cc=mingo@redhat.com \
--cc=mkp@kernel.org \
--cc=mripard@kernel.org \
--cc=muchun.song@linux.dev \
--cc=namhyung@kernel.org \
--cc=nico.pache@linux.dev \
--cc=nphamcs@gmail.com \
--cc=npiggin@gmail.com \
--cc=oleg@redhat.com \
--cc=osalvador@suse.de \
--cc=oupton@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul@paul-moore.com \
--cc=perex@perex.cz \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=pjw@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=selinux@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=simona@ffwll.ch \
--cc=sparclinux@vger.kernel.org \
--cc=spasswolf@web.de \
--cc=sre@kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=tiwai@suse.com \
--cc=tzimmermann@suse.de \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=weixugc@google.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=xu.xin@linux.dev \
--cc=ying.huang@linux.alibaba.com \
--cc=youngjun.park@lge.com \
--cc=yuanchu@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.