* Re: [PATCH 17/30] mm: prefer vma_[start,end]_pgoff() to vma->vm_pgoff in kernel/
From: Pedro Falcato @ 2026-07-02 11:01 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <ea87349d63205bf4c26ea79854f179a9bf8cfb0b.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:28PM +0100, Lorenzo Stoakes wrote:
> Be consistent in using vma_start_pgoff() and vma_end_pgoff(), which clearly
> indicates which part of the VMA the page offset refers to and aids
> greppability.
>
> This is part of a broader series laying the ground to provide a virtual
> page offset for MAP_PRIVATE-file backed anon folios.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> kernel/dma/coherent.c | 7 ++++---
> kernel/dma/direct.c | 6 ++++--
> kernel/dma/mapping.c | 8 +++++---
> kernel/dma/ops_helpers.c | 4 ++--
> kernel/events/core.c | 20 +++++++++++---------
> kernel/events/uprobes.c | 11 +++++++----
> kernel/kcov.c | 2 +-
> kernel/trace/ring_buffer.c | 3 ++-
> 8 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
> index bcdc0f76d2e8..2d3195eb7e83 100644
> --- a/kernel/dma/coherent.c
> +++ b/kernel/dma/coherent.c
> @@ -236,14 +236,15 @@ static int __dma_mmap_from_coherent(struct dma_coherent_mem *mem,
> {
> if (mem && vaddr >= mem->virt_base && vaddr + size <=
> (mem->virt_base + ((dma_addr_t)mem->size << PAGE_SHIFT))) {
> - unsigned long off = vma->vm_pgoff;
> + const pgoff_t pgoff_start = vma_start_pgoff(vma);
> + const pgoff_t pgoff_end = vma_end_pgoff(vma);
> int start = (vaddr - mem->virt_base) >> PAGE_SHIFT;
> unsigned long user_count = vma_pages(vma);
> int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>
> *ret = -ENXIO;
> - if (off < count && user_count <= count - off) {
> - unsigned long pfn = mem->pfn_base + start + off;
> + if (pgoff_start < count && pgoff_end <= count) {
> + unsigned long pfn = mem->pfn_base + start + pgoff_start;
> *ret = remap_pfn_range(vma, vma->vm_start, pfn,
> user_count << PAGE_SHIFT,
> vma->vm_page_prot);
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 4391b797d4db..436310d6e4a2 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -534,6 +534,8 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> unsigned long user_count = vma_pages(vma);
> unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> unsigned long pfn = PHYS_PFN(dma_to_phys(dev, dma_addr));
> + const pgoff_t pgoff_start = vma_start_pgoff(vma);
> + const pgoff_t pgoff_end = vma_end_pgoff(vma);
> int ret = -ENXIO;
>
> vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
> @@ -545,9 +547,9 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> if (dma_mmap_from_global_coherent(vma, cpu_addr, size, &ret))
> return ret;
>
> - if (vma->vm_pgoff >= count || user_count > count - vma->vm_pgoff)
> + if (pgoff_start >= count || pgoff_end > count)
> return -ENXIO;
> - return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> + return remap_pfn_range(vma, vma->vm_start, pfn + pgoff_start,
> user_count << PAGE_SHIFT, vma->vm_page_prot);
> }
>
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 4fe04669e5e6..c986639044e9 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -761,12 +761,14 @@ EXPORT_SYMBOL_GPL(dma_free_pages);
> int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
> size_t size, struct page *page)
> {
> - unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> + const pgoff_t pgoff_start = vma_start_pgoff(vma);
> + const pgoff_t pgoff_end = vma_end_pgoff(vma);
> + const unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>
> - if (vma->vm_pgoff >= count || vma_pages(vma) > count - vma->vm_pgoff)
> + if (pgoff_start >= count || pgoff_end > count)
> return -ENXIO;
> return remap_pfn_range(vma, vma->vm_start,
> - page_to_pfn(page) + vma->vm_pgoff,
> + page_to_pfn(page) + pgoff_start,
> vma_pages(vma) << PAGE_SHIFT, vma->vm_page_prot);
> }
> EXPORT_SYMBOL_GPL(dma_mmap_pages);
> diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
> index 20caf9cabf69..6b5f9208d31c 100644
> --- a/kernel/dma/ops_helpers.c
> +++ b/kernel/dma/ops_helpers.c
> @@ -39,7 +39,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> #ifdef CONFIG_MMU
> unsigned long user_count = vma_pages(vma);
> unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - unsigned long off = vma->vm_pgoff;
> + unsigned long off = vma_start_pgoff(vma);
> struct page *page = dma_common_vaddr_to_page(cpu_addr);
> int ret = -ENXIO;
>
> @@ -52,7 +52,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> return -ENXIO;
>
> return remap_pfn_range(vma, vma->vm_start,
> - page_to_pfn(page) + vma->vm_pgoff,
> + page_to_pfn(page) + vma_start_pgoff(vma),
> user_count << PAGE_SHIFT, vma->vm_page_prot);
> #else
> return -ENXIO;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 954c36e28101..d6d2d557ccb8 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -6998,7 +6998,7 @@ static void perf_mmap_open(struct vm_area_struct *vma)
> refcount_inc(&event->mmap_count);
> refcount_inc(&event->rb->mmap_count);
>
> - if (vma->vm_pgoff)
> + if (vma_start_pgoff(vma))
> refcount_inc(&event->rb->aux_mmap_count);
>
> if (mapped)
> @@ -7032,7 +7032,7 @@ static void perf_mmap_close(struct vm_area_struct *vma)
> * The AUX buffer is strictly a sub-buffer, serialize using aux_mutex
> * to avoid complications.
> */
> - if (rb_has_aux(rb) && vma->vm_pgoff == rb->aux_pgoff &&
> + if (rb_has_aux(rb) && vma_start_pgoff(vma) == rb->aux_pgoff &&
> refcount_dec_and_mutex_lock(&rb->aux_mmap_count, &rb->aux_mutex)) {
> /*
> * Stop all AUX events that are writing to this buffer,
> @@ -7190,7 +7190,8 @@ static int map_range(struct perf_buffer *rb, struct vm_area_struct *vma)
> */
> for (pagenum = 0; pagenum < nr_pages; pagenum++) {
> unsigned long va = vma->vm_start + PAGE_SIZE * pagenum;
> - struct page *page = perf_mmap_to_page(rb, vma->vm_pgoff + pagenum);
> + struct page *page = perf_mmap_to_page(rb,
> + vma_start_pgoff(vma) + pagenum);
>
> if (page == NULL) {
> err = -EINVAL;
> @@ -7348,6 +7349,7 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
> u64 aux_offset, aux_size;
> struct perf_buffer *rb;
> int ret, rb_flags = 0;
> + const pgoff_t pgoff_start = vma_start_pgoff(vma);
Variable decs here seem to be in reverse christmas tree order, so perhaps
move this to the top.
>
> rb = event->rb;
> if (!rb)
> @@ -7366,11 +7368,11 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
> if (aux_offset < perf_data_size(rb) + PAGE_SIZE)
> return -EINVAL;
>
> - if (aux_offset != vma->vm_pgoff << PAGE_SHIFT)
> + if (aux_offset != pgoff_start << PAGE_SHIFT)
> return -EINVAL;
>
> /* already mapped with a different offset */
> - if (rb_has_aux(rb) && rb->aux_pgoff != vma->vm_pgoff)
> + if (rb_has_aux(rb) && rb->aux_pgoff != pgoff_start)
> return -EINVAL;
>
> if (aux_size != nr_pages * PAGE_SIZE)
> @@ -7400,7 +7402,7 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
> if (vma->vm_flags & VM_WRITE)
> rb_flags |= RING_BUFFER_WRITABLE;
>
> - ret = rb_alloc_aux(rb, event, vma->vm_pgoff, nr_pages,
> + ret = rb_alloc_aux(rb, event, pgoff_start, nr_pages,
> event->attr.aux_watermark, rb_flags);
> if (ret) {
> refcount_dec(&rb->mmap_count);
> @@ -7457,7 +7459,7 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma)
> if (event->state <= PERF_EVENT_STATE_REVOKED)
> return -ENODEV;
>
> - if (vma->vm_pgoff == 0)
> + if (!vma_start_pgoff(vma))
> ret = perf_mmap_rb(vma, event, nr_pages);
> else
> ret = perf_mmap_aux(vma, event, nr_pages);
> @@ -9884,7 +9886,7 @@ static bool perf_addr_filter_vma_adjust(struct perf_addr_filter *filter,
> struct perf_addr_filter_range *fr)
> {
> unsigned long vma_size = vma->vm_end - vma->vm_start;
> - unsigned long off = vma->vm_pgoff << PAGE_SHIFT;
> + unsigned long off = vma_start_pgoff(vma) << PAGE_SHIFT;
> struct file *file = vma->vm_file;
>
> if (!perf_addr_filter_match(filter, file, off, vma_size))
> @@ -9974,7 +9976,7 @@ void perf_event_mmap(struct vm_area_struct *vma)
> /* .tid */
> .start = vma->vm_start,
> .len = vma->vm_end - vma->vm_start,
> - .pgoff = (u64)vma->vm_pgoff << PAGE_SHIFT,
> + .pgoff = (u64)vma_start_pgoff(vma) << PAGE_SHIFT,
> },
> /* .maj (attr_mmap2 only) */
> /* .min (attr_mmap2 only) */
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index f23cebacbc6d..244651380ca1 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -144,12 +144,14 @@ static bool valid_vma(struct vm_area_struct *vma, bool is_register)
>
> static unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
> {
> - return vma->vm_start + offset - ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> + return vma->vm_start + offset -
> + ((loff_t)vma_start_pgoff(vma) << PAGE_SHIFT);
> }
>
> static loff_t vaddr_to_offset(struct vm_area_struct *vma, unsigned long vaddr)
> {
> - return ((loff_t)vma->vm_pgoff << PAGE_SHIFT) + (vaddr - vma->vm_start);
> + return ((loff_t)vma_start_pgoff(vma) << PAGE_SHIFT) +
> + (vaddr - vma->vm_start);
> }
Something we've seen in this series is that perhaps something like
static inline loff_t vma_start_off(vma)
{
return ((loff_t) vma_start_pgoff(vma)) << PAGE_SHIFT;
}
could be worth it.
>
> /**
> @@ -1482,7 +1484,7 @@ static int unapply_uprobe(struct uprobe *uprobe, struct mm_struct *mm)
> file_inode(vma->vm_file) != uprobe->inode)
> continue;
>
> - offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> + offset = (loff_t)vma_start_pgoff(vma) << PAGE_SHIFT;
> if (uprobe->offset < offset ||
> uprobe->offset >= offset + vma->vm_end - vma->vm_start)
> continue;
> @@ -2453,7 +2455,8 @@ static struct uprobe *find_active_uprobe_speculative(unsigned long bp_vaddr)
> if (!vm_file)
> return NULL;
>
> - offset = (loff_t)(vma->vm_pgoff << PAGE_SHIFT) + (bp_vaddr - vma->vm_start);
> + offset = (loff_t)(vma_start_pgoff(vma) << PAGE_SHIFT) +
> + (bp_vaddr - vma->vm_start);
This is more extremely contrived logic that could be better expressed as
loff_t vma_linear_off(vma, bp_vaddr);
> uprobe = find_uprobe_rcu(vm_file->f_inode, offset);
> if (!uprobe)
> return NULL;
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index 1df373fb562b..b19b473c366a 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -512,7 +512,7 @@ static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
>
> spin_lock_irqsave(&kcov->lock, flags);
> size = kcov->size * sizeof(unsigned long);
> - if (kcov->area == NULL || vma->vm_pgoff != 0 ||
> + if (kcov->area == NULL || vma_start_pgoff(vma) ||
as a nit, perhaps vma_start_pgoff(vma) > 0
would be a little more idiomatic.
> vma->vm_end - vma->vm_start != size) {
> res = -EINVAL;
> goto exit;
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 56a328e94395..dfa493d54ef9 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -7613,7 +7613,8 @@ static int __rb_inc_dec_mapped(struct ring_buffer_per_cpu *cpu_buffer,
> static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> struct vm_area_struct *vma)
> {
> - unsigned long nr_subbufs, nr_pages, nr_vma_pages, pgoff = vma->vm_pgoff;
> + unsigned long nr_subbufs, nr_pages, nr_vma_pages;
> + pgoff_t pgoff = vma_start_pgoff(vma);
> unsigned int subbuf_pages, subbuf_order;
> struct page **pages __free(kfree) = NULL;
> int p = 0, s = 0;
Anyway, in general:
Acked-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 18/30] mm/vma: remove duplicative vma_pgoff_offset() helper
From: Pedro Falcato @ 2026-07-02 11:02 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <10671c2fc5d0dd4e3bf497181923e63e46053df1.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:29PM +0100, Lorenzo Stoakes wrote:
> This is doing what linear_page_index() does, so eliminate it and replace it
> with linear_page_index().
>
> Update the VMA userland tests to reflect this change.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
> ---
> mm/vma.h | 9 +--------
> tools/testing/vma/include/dup.h | 16 ++++++++++++++++
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/mm/vma.h b/mm/vma.h
> index 527716c8739d..2342516ce00e 100644
> --- a/mm/vma.h
> +++ b/mm/vma.h
> @@ -247,13 +247,6 @@ static inline pgoff_t vmg_end_pgoff(const struct vma_merge_struct *vmg)
> return vmg_start_pgoff(vmg) + vmg_pages(vmg);
> }
>
> -/* Assumes addr >= vma->vm_start. */
> -static inline pgoff_t vma_pgoff_offset(struct vm_area_struct *vma,
> - unsigned long addr)
> -{
> - return vma->vm_pgoff + PHYS_PFN(addr - vma->vm_start);
> -}
> -
> #define VMG_STATE(name, mm_, vmi_, start_, end_, vma_flags_, pgoff_) \
> struct vma_merge_struct name = { \
> .mm = mm_, \
> @@ -275,7 +268,7 @@ static inline pgoff_t vma_pgoff_offset(struct vm_area_struct *vma,
> .start = start_, \
> .end = end_, \
> .vm_flags = vma_->vm_flags, \
> - .pgoff = vma_pgoff_offset(vma_, start_), \
> + .pgoff = linear_page_index(vma_, start_), \
> .file = vma_->vm_file, \
> .anon_vma = vma_->anon_vma, \
> .policy = vma_policy(vma_), \
> diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
> index 535747d7fee4..7ed165c8d9bc 100644
> --- a/tools/testing/vma/include/dup.h
> +++ b/tools/testing/vma/include/dup.h
> @@ -1548,3 +1548,19 @@ static inline pgprot_t vma_get_page_prot(vma_flags_t vma_flags)
>
> return vm_get_page_prot(vm_flags);
> }
> +
> +static inline pgoff_t linear_page_delta(const struct vm_area_struct *vma,
> + const unsigned long address)
> +{
> + return (address - vma->vm_start) >> PAGE_SHIFT;
> +}
> +
> +static inline pgoff_t linear_page_index(const struct vm_area_struct *vma,
> + const unsigned long address)
> +{
> + pgoff_t pgoff;
> +
> + pgoff = linear_page_delta(vma, address);
> + pgoff += vma_start_pgoff(vma);
> + return pgoff;
> +}
> --
> 2.54.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCH 19/30] mm: use linear_page_[index, delta]() consistently
From: Pedro Falcato @ 2026-07-02 11:04 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <bf56e2e98b512962a2fb88900d535a0e9e6769d8.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:30PM +0100, Lorenzo Stoakes wrote:
> There are a number of places where we open code what linear_page_index()
> and linear_page_delta() calculate.
>
> Replace this code with the appropriate functions for consistency.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de> # mm
--
Pedro
^ permalink raw reply
* Re: [PATCH 20/30] mm/vma: introduce vma_assert_can_modify()
From: Pedro Falcato @ 2026-07-02 11:16 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <23c7602c58cacc23ef22618a27af9a2d54addf58.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:31PM +0100, Lorenzo Stoakes wrote:
> vma_assert_write_locked() and vma_assert_attached() are useful for their
> own purposes, however VMA code absolutely does allow the modification of
> non-write locked VMAs if they are at that point detached (i.e. unreachable
> from anywhere).
>
> It's therefore useful to be able to assert that a VMA is either
> detached (modification doesn't matter) or write locked (you're explicitly
> locked for modification).
Hmm, I was wondering why detached does not imply write_locked, and then
realized that new VMAs aren't write-locked. Could we do it by default?
Like a simple:
vma->vm_lock_seq = __vma_raw_mm_seqnum(vma);
might do the trick. I don't see why it wouldn't work? Is there some other
case I am not considering?
>
> Therefore introduce vma_assert_can_modify() for this purpose.
>
> While we're here, make vma_is_attached() available generally - if
> !CONFIG_PER_VMA_LOCKS, then there's no sense in which a VMA is
> detached (vma_mark_detached() is a noop), so have this default to true in
> this case.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> include/linux/mmap_lock.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> index 04b8f61ece5d..d513286d8160 100644
> --- a/include/linux/mmap_lock.h
> +++ b/include/linux/mmap_lock.h
> @@ -506,6 +506,8 @@ static inline __must_check
> int vma_start_write_killable(struct vm_area_struct *vma) { return 0; }
> static inline void vma_assert_write_locked(struct vm_area_struct *vma)
> { mmap_assert_write_locked(vma->vm_mm); }
> +static inline bool vma_is_attached(struct vm_area_struct *vma)
> + { return true; }
> static inline void vma_assert_attached(struct vm_area_struct *vma) {}
> static inline void vma_assert_detached(struct vm_area_struct *vma) {}
> static inline void vma_mark_attached(struct vm_area_struct *vma) {}
> @@ -530,6 +532,12 @@ static inline void vma_assert_stabilised(struct vm_area_struct *vma)
>
> #endif /* CONFIG_PER_VMA_LOCK */
>
> +static inline void vma_assert_can_modify(struct vm_area_struct *vma)
> +{
> + if (vma_is_attached(vma))
> + vma_assert_write_locked(vma);
> +}
> +
> static inline void mmap_write_lock(struct mm_struct *mm)
> {
> __mmap_lock_trace_start_locking(mm, true);
> --
> 2.54.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCHv5 00/13] uprobes/x86: Fix red zone issue for optimized uprobes
From: Jiri Olsa @ 2026-07-02 11:20 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Oleg Nesterov, Peter Zijlstra, Ingo Molnar, Masami Hiramatsu,
Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <CAEf4BzYiPeLTbgeVEDKqU45oHBFJgU6ULgK=3i1J7dbzKS2+yg@mail.gmail.com>
On Wed, Jul 01, 2026 at 04:13:26PM -0700, Andrii Nakryiko wrote:
> On Wed, Jul 1, 2026 at 4:13 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > hi,
> > Andrii reported an issue with optimized uprobes [1] that can clobber
> > redzone area with call instruction storing return address on stack
> > where user code may keep temporary data without adjusting rsp.
> >
> > Fixing this by moving the optimized uprobes on top of 10-bytes nop
> > instruction, so we can squeeze another instruction to escape the
> > redzone area before doing the call.
> >
> > Note we need upstream update first for patch 3 (github.com/libbpf/usdt),
> > if we decide to take this change.
> >
> > thanks,
> > jirka
> >
> >
> > v1: https://lore.kernel.org/bpf/20260514135342.22130-1-jolsa@kernel.org/
> > v2: https://lore.kernel.org/bpf/20260518105957.123445-1-jolsa@kernel.org/
> > v3: https://lore.kernel.org/bpf/20260521124411.31133-1-jolsa@kernel.org/
> > v4: https://lore.kernel.org/bpf/20260526205840.173790-1-jolsa@kernel.org/
> >
> > v5 changes:
> > - several selftests changes and reviewed-by tags [Jakub]
> > - add more comments in int3_update_unoptimize [Andrii]
> > - several other minor changes and acks [Oleg]
> > - move insn_decode out of uprobe_init_insn to simplify the code
> > - align uprobe_red_zone_test to 64 to make sure nop10 is not on page boundary
> >
> > v4 changes:
> > - do not use 2nd int3 (ont +5 offset) because the call instruction
> > is allways the same for the given nop10 address [Andrii/Peter]
> > - unmap unused trampoline vma after unsuccesfull optimization [sashiko]
> > - small change to patch#2 moved user_64bit_mode earlier in the path
> > and pass/use mm_struct pointer directly from arch_uprobe_optimize
> > instead of gettting current->mm
> > Andrii, keeping your ack, please shout otherwise
> >
> > v3 changes:
> > - use nop10 update suggested by Peter in [2]
> > - remove struct uprobe_trampoline object, use vma objects directly instead
> > - selftests fixes [sashiko]
> > - ack from Andrii
> >
> > v2 changes:
> > - several selftest fixes [sashiko]
> > - consolidate is_lea_insn and is_call_insn insto single check [Jakub Sitnicki]
> > - use proper mm_struct object in __in_uprobe_trampoline check [sashiko]
> > - allow to copy uprobe trampolines vma objects on fork [sashiko]
> > - change uprobe syscall detection error from -ENXIO to -EPROTO [Andrii]
> > - added fork/clone tests
> > - I kept the selftest changes and nop5->nop10 changes in separate
> > commits for easier review, we can squash them later if we want to keep
> > bisect working properly
> >
> >
> > [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/
> > [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t
> > ---
>
> ASAN-enabled test_progs runs are not happy in CI, can you please check?
I failed to release link in test_uprobe_fork_optimized, fix is below
I can send new version or separate fix
also there's 2 things to solve/discuss once kernel changes are acked:
- selftest changes depend on:
selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch
that is taken from libbpf/usdt, I pushed the PR in here [1]
- as bots complained the patchset breaks bisection, because kernel
changes break selftests.. not sure what's prefered solution, as for
me I'd keep it that way rather than mixing kernel/user space changes
thanks,
jirka
[1] https://github.com/libbpf/usdt/pull/16
---
diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
index eb067f029a9f..e193206fc5d2 100644
--- a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
+++ b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
@@ -988,7 +988,6 @@ static noreturn int child_func(void *arg)
static void test_uprobe_fork_optimized(bool clone_vm)
{
struct uprobe_syscall_executed *skel = NULL;
- struct bpf_link *link = NULL;
unsigned long offset;
int pid, status, err;
char stack[65535];
@@ -1001,9 +1000,9 @@ static void test_uprobe_fork_optimized(bool clone_vm)
if (!ASSERT_OK_PTR(skel, "open_and_load"))
goto cleanup;
- link = bpf_program__attach_uprobe_opts(skel->progs.test_uprobe,
- -1, "/proc/self/exe", offset, NULL);
- if (!ASSERT_OK_PTR(link, "attach_uprobe"))
+ skel->links.test_uprobe = bpf_program__attach_uprobe_opts(skel->progs.test_uprobe,
+ -1, "/proc/self/exe", offset, NULL);
+ if (!ASSERT_OK_PTR(skel->links.test_uprobe, "attach_uprobe"))
goto cleanup;
skel->bss->pid = getpid();
^ permalink raw reply related
* Re: [PATCH 21/30] mm/vma: add and use vma_[add/sub]_pgoff()
From: Pedro Falcato @ 2026-07-02 11:20 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <794044881e454fd8ac13e59d5ff5fc86fca08b03.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:32PM +0100, Lorenzo Stoakes wrote:
> Add helpers for adding or subtracting to a VMA's page offset, exposed
> internally for VMA users within mm in mm/vma.h.
>
> This is to lay the foundations for tracking anonymous page offset for
> MAP_PRIVATE file-backed mappings, where adding and subtracting from this
> value must be reflected in both the file and anonymous offsets.
>
> These are used on VMA split and downward stack expansion.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/nommu.c | 6 ++++--
> mm/vma.c | 6 +++---
> mm/vma.h | 12 ++++++++++++
> tools/testing/vma/include/dup.h | 13 ++++++++++++-
> 4 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 7333d855e974..c7fafcd87c14 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -41,6 +41,7 @@
> #include <asm/tlbflush.h>
> #include <asm/mmu_context.h>
> #include "internal.h"
> +#include "vma.h"
>
> unsigned long highest_memmap_pfn;
> int heap_stack_gap = 0;
> @@ -1338,7 +1339,8 @@ static int split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
> region->vm_top = region->vm_end = new->vm_end = addr;
> } else {
> region->vm_start = new->vm_start = addr;
> - region->vm_pgoff = new->vm_pgoff += npages;
> + vma_add_pgoff(new, npages);
> + region->vm_pgoff = vma_start_pgoff(new);
> }
>
> vma_iter_config(vmi, new->vm_start, new->vm_end);
> @@ -1355,7 +1357,7 @@ static int split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
> delete_nommu_region(vma->vm_region);
> if (new_below) {
> vma->vm_region->vm_start = vma->vm_start = addr;
> - vma->vm_pgoff += npages;
> + vma_add_pgoff(vma, npages);
> vma->vm_region->vm_pgoff = vma_start_pgoff(vma);
> } else {
> vma->vm_region->vm_end = vma->vm_end = addr;
> diff --git a/mm/vma.c b/mm/vma.c
> index 185d07397ca6..cb7222e20c93 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -517,7 +517,7 @@ __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
> new->vm_end = addr;
> } else {
> new->vm_start = addr;
> - new->vm_pgoff += linear_page_delta(vma, addr);
> + vma_add_pgoff(new, linear_page_delta(vma, addr));
> }
>
> err = -ENOMEM;
> @@ -556,7 +556,7 @@ __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
>
> if (new_below) {
> vma->vm_start = addr;
> - vma->vm_pgoff += (addr - new->vm_start) >> PAGE_SHIFT;
> + vma_add_pgoff(vma, (addr - new->vm_start) >> PAGE_SHIFT);
> } else {
> vma->vm_end = addr;
> }
> @@ -3305,7 +3305,7 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address)
> vm_stat_account(mm, vma->vm_flags, grow);
> anon_vma_interval_tree_pre_update_vma(vma);
> vma->vm_start = address;
> - vma->vm_pgoff -= grow;
> + vma_sub_pgoff(vma, grow);
> /* Overwrite old entry in mtree. */
> vma_iter_store_overwrite(&vmi, vma);
> anon_vma_interval_tree_post_update_vma(vma);
> diff --git a/mm/vma.h b/mm/vma.h
> index 2342516ce00e..47fe35e5307e 100644
> --- a/mm/vma.h
> +++ b/mm/vma.h
> @@ -247,6 +247,18 @@ static inline pgoff_t vmg_end_pgoff(const struct vma_merge_struct *vmg)
> return vmg_start_pgoff(vmg) + vmg_pages(vmg);
> }
>
> +static inline void vma_add_pgoff(struct vm_area_struct *vma, pgoff_t delta)
> +{
> + vma_assert_can_modify(vma);
> + vma->vm_pgoff += delta;
> +}
> +
> +static inline void vma_sub_pgoff(struct vm_area_struct *vma, pgoff_t delta)
> +{
> + vma_assert_can_modify(vma);
> + vma->vm_pgoff -= delta;
> +}
> +
> #define VMG_STATE(name, mm_, vmi_, start_, end_, vma_flags_, pgoff_) \
> struct vma_merge_struct name = { \
> .mm = mm_, \
> diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
> index 7ed165c8d9bc..41fea90a344d 100644
> --- a/tools/testing/vma/include/dup.h
> +++ b/tools/testing/vma/include/dup.h
> @@ -1163,6 +1163,11 @@ static inline struct vm_area_struct *vma_next(struct vma_iterator *vmi)
> return mas_find(&vmi->mas, ULONG_MAX);
> }
>
> +static inline bool vma_is_attached(struct vm_area_struct *vma)
> +{
> + return refcount_read(&vma->vm_refcnt);
> +}
> +
> /*
> * WARNING: to avoid racing with vma_mark_attached()/vma_mark_detached(), these
> * assertions should be made either under mmap_write_lock or when the object
> @@ -1170,7 +1175,13 @@ static inline struct vm_area_struct *vma_next(struct vma_iterator *vmi)
> */
> static inline void vma_assert_attached(struct vm_area_struct *vma)
> {
> - WARN_ON_ONCE(!refcount_read(&vma->vm_refcnt));
> + WARN_ON_ONCE(!vma_is_attached(vma));
> +}
> +
> +static inline void vma_assert_can_modify(struct vm_area_struct *vma)
> +{
> + if (vma_is_attached(vma))
> + vma_assert_write_locked(vma);
> }
These hunks in dup.h look lost. Should perhaps be on the previous patch
(adding the helpers).
Anyway, Obviously Correct(tm).
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 22/30] mm/vma: move __install_special_mapping() to vma.c
From: Pedro Falcato @ 2026-07-02 11:22 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <b3254231831037ca3e9757e3e05c90072e04a6aa.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:33PM +0100, Lorenzo Stoakes wrote:
> This function is operating on VMAs and rightly belongs in vma.c, where it
> can be subject to VMA userland testing and allows us to isolate it from the
> rest of mm.
>
> The _install_special_mapping() function will remain in mmap.c as a wrapper,
> since this is used by architecture-specific code.
>
> Doing so allows us to isolate more functions in vma.c for the same reasons.
>
> This forms part of work to allow for tracking MAP_PRIVATE file-backed
> mappings by their anonymous virtual page offset, as doing so allows us to
> isolate and keep code that interacts with this together.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/mmap.c | 38 --------------------------------------
> mm/vma.c | 38 ++++++++++++++++++++++++++++++++++++++
> mm/vma.h | 5 +++++
> 3 files changed, 43 insertions(+), 38 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2d09a57e3620..46174e706bbe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1447,44 +1447,6 @@ static vm_fault_t special_mapping_fault(struct vm_fault *vmf)
> return VM_FAULT_SIGBUS;
> }
>
> -static struct vm_area_struct *__install_special_mapping(
> - struct mm_struct *mm,
> - unsigned long addr, unsigned long len,
> - vm_flags_t vm_flags, void *priv,
> - const struct vm_operations_struct *ops)
> -{
> - int ret;
> - struct vm_area_struct *vma;
> -
> - vma = vm_area_alloc(mm);
> - if (unlikely(vma == NULL))
> - return ERR_PTR(-ENOMEM);
> -
> - vma_set_range(vma, addr, addr + len, 0);
> - vm_flags |= mm->def_flags | VM_DONTEXPAND;
> - if (pgtable_supports_soft_dirty())
> - vm_flags |= VM_SOFTDIRTY;
> - vm_flags_init(vma, vm_flags & ~VM_LOCKED_MASK);
> - vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> -
> - vma->vm_ops = ops;
> - vma->vm_private_data = priv;
> -
> - ret = insert_vm_struct(mm, vma);
> - if (ret)
> - goto out;
> -
> - vm_stat_account(mm, vma->vm_flags, len >> PAGE_SHIFT);
> -
> - perf_event_mmap(vma);
> -
> - return vma;
> -
> -out:
> - vm_area_free(vma);
> - return ERR_PTR(ret);
> -}
> -
> bool vma_is_special_mapping(const struct vm_area_struct *vma,
> const struct vm_special_mapping *sm)
> {
> diff --git a/mm/vma.c b/mm/vma.c
> index cb7222e20c93..f4de706a2728 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -3399,3 +3399,41 @@ __weak unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
> {
> return vma_kernel_pagesize(vma);
> }
> +
> +struct vm_area_struct *__install_special_mapping(
> + struct mm_struct *mm,
> + unsigned long addr, unsigned long len,
> + vm_flags_t vm_flags, void *priv,
> + const struct vm_operations_struct *ops)
> +{
> + int ret;
> + struct vm_area_struct *vma;
> +
> + vma = vm_area_alloc(mm);
> + if (unlikely(vma == NULL))
> + return ERR_PTR(-ENOMEM);
> +
> + vma_set_range(vma, addr, addr + len, 0);
> + vm_flags |= mm->def_flags | VM_DONTEXPAND;
> + if (pgtable_supports_soft_dirty())
> + vm_flags |= VM_SOFTDIRTY;
> + vm_flags_init(vma, vm_flags & ~VM_LOCKED_MASK);
> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> +
> + vma->vm_ops = ops;
> + vma->vm_private_data = priv;
> +
> + ret = insert_vm_struct(mm, vma);
> + if (ret)
> + goto out;
> +
> + vm_stat_account(mm, vma->vm_flags, len >> PAGE_SHIFT);
> +
> + perf_event_mmap(vma);
> +
> + return vma;
> +
> +out:
> + vm_area_free(vma);
> + return ERR_PTR(ret);
> +}
> diff --git a/mm/vma.h b/mm/vma.h
> index 47fe35e5307e..14f026bf3be4 100644
> --- a/mm/vma.h
> +++ b/mm/vma.h
> @@ -775,4 +775,9 @@ static inline bool map_deny_write_exec(const vma_flags_t *old,
> }
> #endif
>
> +struct vm_area_struct *__install_special_mapping(struct mm_struct *mm,
> + unsigned long addr, unsigned long len,
> + vm_flags_t vm_flags, void *priv,
> + const struct vm_operations_struct *ops);
> +
> #endif /* __MM_VMA_H */
I'm really annoyed that _install_special_mapping has a leading underscore.
That's it.
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 23/30] mm/vma: make vma_set_range() static, drop insert_vm_struct() decl
From: Pedro Falcato @ 2026-07-02 11:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <62efd70f9f39570724c9552cc7f2aeb5c322b2ff.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:34PM +0100, Lorenzo Stoakes wrote:
> With __install_special_mapping() moved to vma.c, vma_set_range() can be
> made into a static function there and is now completely isolated from the
> rest of mm.
>
> While we're here, we can also remove the insert_vm_struct() declaration
> from mm.h - the function is implemented in vma.c and already declared in
> vma.h, and has no users outside of mm.
>
> Also update the VMA userland tests to reflect this change.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 24/30] mm/vma: update vma_shrink() to not pass unnecessary pgoff parameter
From: Pedro Falcato @ 2026-07-02 11:27 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <6dd744d57d778f94d2fef8fd623d7c4ed8010d93.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:35PM +0100, Lorenzo Stoakes wrote:
> vma_shrink() does not need to adjust vma->vm_pgoff, we were passing this
> parameter solely to satisfy vma_set_range()'s requirement for pgoff being
> specified.
>
> Since vma_set_range() is now isolated to vma.c, we can simply introduce
> __vma_set_range() which sets only vma->vm_[start, end], and invoke this
> instead, removing pgoff from vma_shrink() altogether.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 25/30] mm/vma: update vmg_adjust_set_range() to offset pgoff instead
From: Pedro Falcato @ 2026-07-02 11:29 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <910f7b5be78232304dc7ca01cd57c6f5ca8f3d13.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:36PM +0100, Lorenzo Stoakes wrote:
> We are calculating the pgoff as an offset, since we have vma_add_pgoff()
> and vma_sub_pgoff() available, just offset this value directly and use
> __vma_set_range() for vma->vm_[start, end] values.
>
> We take care to update the range before offsetting the page offset, so the
> adjusted VMA's vm_start and vm_pgoff are mutually consistent at the point
> the page offset helpers operate - this matters once vma_set_pgoff() comes
> to assert invariants which relate the two.
>
> Doing so lays the foundation for future work which allows for use of
> virtual page offsets for MAP_PRIVATE-file backed mappings.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/vma.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index e3355eab11f2..0579fc8c9bd5 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -714,9 +714,6 @@ void validate_mm(struct mm_struct *mm)
> */
> static void vmg_adjust_set_range(struct vma_merge_struct *vmg)
> {
> - struct vm_area_struct *adjust;
> - pgoff_t pgoff;
> -
> if (vmg->__adjust_middle_start) {
> /*
> * vmg->start vmg->end
> @@ -735,8 +732,8 @@ static void vmg_adjust_set_range(struct vma_merge_struct *vmg)
> struct vm_area_struct *middle = vmg->middle;
> const unsigned long delta = vmg->end - middle->vm_start;
>
> - pgoff = vma_start_pgoff(middle) + (delta >> PAGE_SHIFT);
> - adjust = middle;
> + __vma_set_range(middle, vmg->end, middle->vm_end);
> + vma_add_pgoff(middle, delta >> PAGE_SHIFT);
> } else if (vmg->__adjust_next_start) {
> /*
> * Originally:
> @@ -764,13 +761,9 @@ static void vmg_adjust_set_range(struct vma_merge_struct *vmg)
> struct vm_area_struct *next = vmg->next;
> const unsigned long delta = next->vm_start - vmg->end;
>
> - pgoff = vma_start_pgoff(next) - (delta >> PAGE_SHIFT);
> - adjust = next;
> - } else {
> - return;
> + __vma_set_range(next, vmg->end, next->vm_end);
> + vma_sub_pgoff(next, delta >> PAGE_SHIFT);
> }
> -
> - vma_set_range(adjust, vmg->end, adjust->vm_end, pgoff);
> }
Maybe this should be squashed with That Other Patch that touches this.
Anyway,
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 17/30] mm: prefer vma_[start,end]_pgoff() to vma->vm_pgoff in kernel/
From: Lorenzo Stoakes @ 2026-07-02 11:30 UTC (permalink / raw)
To: Pedro Falcato
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <akZCg73F-oGzDp1a@pedro-suse.lan>
On Thu, Jul 02, 2026 at 12:01:37PM +0100, Pedro Falcato wrote:
> On Mon, Jun 29, 2026 at 01:23:28PM +0100, Lorenzo Stoakes wrote:
> > Be consistent in using vma_start_pgoff() and vma_end_pgoff(), which clearly
> > indicates which part of the VMA the page offset refers to and aids
> > greppability.
> >
> > This is part of a broader series laying the ground to provide a virtual
> > page offset for MAP_PRIVATE-file backed anon folios.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> > kernel/dma/coherent.c | 7 ++++---
> > kernel/dma/direct.c | 6 ++++--
> > kernel/dma/mapping.c | 8 +++++---
> > kernel/dma/ops_helpers.c | 4 ++--
> > kernel/events/core.c | 20 +++++++++++---------
> > kernel/events/uprobes.c | 11 +++++++----
> > kernel/kcov.c | 2 +-
> > kernel/trace/ring_buffer.c | 3 ++-
> > 8 files changed, 36 insertions(+), 25 deletions(-)
> >
> > diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
> > index bcdc0f76d2e8..2d3195eb7e83 100644
> > --- a/kernel/dma/coherent.c
> > +++ b/kernel/dma/coherent.c
> > @@ -236,14 +236,15 @@ static int __dma_mmap_from_coherent(struct dma_coherent_mem *mem,
> > {
> > if (mem && vaddr >= mem->virt_base && vaddr + size <=
> > (mem->virt_base + ((dma_addr_t)mem->size << PAGE_SHIFT))) {
> > - unsigned long off = vma->vm_pgoff;
> > + const pgoff_t pgoff_start = vma_start_pgoff(vma);
> > + const pgoff_t pgoff_end = vma_end_pgoff(vma);
> > int start = (vaddr - mem->virt_base) >> PAGE_SHIFT;
> > unsigned long user_count = vma_pages(vma);
> > int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> >
> > *ret = -ENXIO;
> > - if (off < count && user_count <= count - off) {
> > - unsigned long pfn = mem->pfn_base + start + off;
> > + if (pgoff_start < count && pgoff_end <= count) {
> > + unsigned long pfn = mem->pfn_base + start + pgoff_start;
> > *ret = remap_pfn_range(vma, vma->vm_start, pfn,
> > user_count << PAGE_SHIFT,
> > vma->vm_page_prot);
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 4391b797d4db..436310d6e4a2 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -534,6 +534,8 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> > unsigned long user_count = vma_pages(vma);
> > unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > unsigned long pfn = PHYS_PFN(dma_to_phys(dev, dma_addr));
> > + const pgoff_t pgoff_start = vma_start_pgoff(vma);
> > + const pgoff_t pgoff_end = vma_end_pgoff(vma);
> > int ret = -ENXIO;
> >
> > vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
> > @@ -545,9 +547,9 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> > if (dma_mmap_from_global_coherent(vma, cpu_addr, size, &ret))
> > return ret;
> >
> > - if (vma->vm_pgoff >= count || user_count > count - vma->vm_pgoff)
> > + if (pgoff_start >= count || pgoff_end > count)
> > return -ENXIO;
> > - return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> > + return remap_pfn_range(vma, vma->vm_start, pfn + pgoff_start,
> > user_count << PAGE_SHIFT, vma->vm_page_prot);
> > }
> >
> > diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> > index 4fe04669e5e6..c986639044e9 100644
> > --- a/kernel/dma/mapping.c
> > +++ b/kernel/dma/mapping.c
> > @@ -761,12 +761,14 @@ EXPORT_SYMBOL_GPL(dma_free_pages);
> > int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
> > size_t size, struct page *page)
> > {
> > - unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > + const pgoff_t pgoff_start = vma_start_pgoff(vma);
> > + const pgoff_t pgoff_end = vma_end_pgoff(vma);
> > + const unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> >
> > - if (vma->vm_pgoff >= count || vma_pages(vma) > count - vma->vm_pgoff)
> > + if (pgoff_start >= count || pgoff_end > count)
> > return -ENXIO;
> > return remap_pfn_range(vma, vma->vm_start,
> > - page_to_pfn(page) + vma->vm_pgoff,
> > + page_to_pfn(page) + pgoff_start,
> > vma_pages(vma) << PAGE_SHIFT, vma->vm_page_prot);
> > }
> > EXPORT_SYMBOL_GPL(dma_mmap_pages);
> > diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
> > index 20caf9cabf69..6b5f9208d31c 100644
> > --- a/kernel/dma/ops_helpers.c
> > +++ b/kernel/dma/ops_helpers.c
> > @@ -39,7 +39,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> > #ifdef CONFIG_MMU
> > unsigned long user_count = vma_pages(vma);
> > unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > - unsigned long off = vma->vm_pgoff;
> > + unsigned long off = vma_start_pgoff(vma);
> > struct page *page = dma_common_vaddr_to_page(cpu_addr);
> > int ret = -ENXIO;
> >
> > @@ -52,7 +52,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> > return -ENXIO;
> >
> > return remap_pfn_range(vma, vma->vm_start,
> > - page_to_pfn(page) + vma->vm_pgoff,
> > + page_to_pfn(page) + vma_start_pgoff(vma),
> > user_count << PAGE_SHIFT, vma->vm_page_prot);
> > #else
> > return -ENXIO;
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 954c36e28101..d6d2d557ccb8 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -6998,7 +6998,7 @@ static void perf_mmap_open(struct vm_area_struct *vma)
> > refcount_inc(&event->mmap_count);
> > refcount_inc(&event->rb->mmap_count);
> >
> > - if (vma->vm_pgoff)
> > + if (vma_start_pgoff(vma))
> > refcount_inc(&event->rb->aux_mmap_count);
> >
> > if (mapped)
> > @@ -7032,7 +7032,7 @@ static void perf_mmap_close(struct vm_area_struct *vma)
> > * The AUX buffer is strictly a sub-buffer, serialize using aux_mutex
> > * to avoid complications.
> > */
> > - if (rb_has_aux(rb) && vma->vm_pgoff == rb->aux_pgoff &&
> > + if (rb_has_aux(rb) && vma_start_pgoff(vma) == rb->aux_pgoff &&
> > refcount_dec_and_mutex_lock(&rb->aux_mmap_count, &rb->aux_mutex)) {
> > /*
> > * Stop all AUX events that are writing to this buffer,
> > @@ -7190,7 +7190,8 @@ static int map_range(struct perf_buffer *rb, struct vm_area_struct *vma)
> > */
> > for (pagenum = 0; pagenum < nr_pages; pagenum++) {
> > unsigned long va = vma->vm_start + PAGE_SIZE * pagenum;
> > - struct page *page = perf_mmap_to_page(rb, vma->vm_pgoff + pagenum);
> > + struct page *page = perf_mmap_to_page(rb,
> > + vma_start_pgoff(vma) + pagenum);
> >
> > if (page == NULL) {
> > err = -EINVAL;
> > @@ -7348,6 +7349,7 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
> > u64 aux_offset, aux_size;
> > struct perf_buffer *rb;
> > int ret, rb_flags = 0;
> > + const pgoff_t pgoff_start = vma_start_pgoff(vma);
>
> Variable decs here seem to be in reverse christmas tree order, so perhaps
> move this to the top.
Ack will change on respin.
>
> >
> > rb = event->rb;
> > if (!rb)
> > @@ -7366,11 +7368,11 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
> > if (aux_offset < perf_data_size(rb) + PAGE_SIZE)
> > return -EINVAL;
> >
> > - if (aux_offset != vma->vm_pgoff << PAGE_SHIFT)
> > + if (aux_offset != pgoff_start << PAGE_SHIFT)
> > return -EINVAL;
> >
> > /* already mapped with a different offset */
> > - if (rb_has_aux(rb) && rb->aux_pgoff != vma->vm_pgoff)
> > + if (rb_has_aux(rb) && rb->aux_pgoff != pgoff_start)
> > return -EINVAL;
> >
> > if (aux_size != nr_pages * PAGE_SIZE)
> > @@ -7400,7 +7402,7 @@ static int perf_mmap_aux(struct vm_area_struct *vma, struct perf_event *event,
> > if (vma->vm_flags & VM_WRITE)
> > rb_flags |= RING_BUFFER_WRITABLE;
> >
> > - ret = rb_alloc_aux(rb, event, vma->vm_pgoff, nr_pages,
> > + ret = rb_alloc_aux(rb, event, pgoff_start, nr_pages,
> > event->attr.aux_watermark, rb_flags);
> > if (ret) {
> > refcount_dec(&rb->mmap_count);
> > @@ -7457,7 +7459,7 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma)
> > if (event->state <= PERF_EVENT_STATE_REVOKED)
> > return -ENODEV;
> >
> > - if (vma->vm_pgoff == 0)
> > + if (!vma_start_pgoff(vma))
> > ret = perf_mmap_rb(vma, event, nr_pages);
> > else
> > ret = perf_mmap_aux(vma, event, nr_pages);
> > @@ -9884,7 +9886,7 @@ static bool perf_addr_filter_vma_adjust(struct perf_addr_filter *filter,
> > struct perf_addr_filter_range *fr)
> > {
> > unsigned long vma_size = vma->vm_end - vma->vm_start;
> > - unsigned long off = vma->vm_pgoff << PAGE_SHIFT;
> > + unsigned long off = vma_start_pgoff(vma) << PAGE_SHIFT;
> > struct file *file = vma->vm_file;
> >
> > if (!perf_addr_filter_match(filter, file, off, vma_size))
> > @@ -9974,7 +9976,7 @@ void perf_event_mmap(struct vm_area_struct *vma)
> > /* .tid */
> > .start = vma->vm_start,
> > .len = vma->vm_end - vma->vm_start,
> > - .pgoff = (u64)vma->vm_pgoff << PAGE_SHIFT,
> > + .pgoff = (u64)vma_start_pgoff(vma) << PAGE_SHIFT,
> > },
> > /* .maj (attr_mmap2 only) */
> > /* .min (attr_mmap2 only) */
> > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > index f23cebacbc6d..244651380ca1 100644
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -144,12 +144,14 @@ static bool valid_vma(struct vm_area_struct *vma, bool is_register)
> >
> > static unsigned long offset_to_vaddr(struct vm_area_struct *vma, loff_t offset)
> > {
> > - return vma->vm_start + offset - ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
> > + return vma->vm_start + offset -
> > + ((loff_t)vma_start_pgoff(vma) << PAGE_SHIFT);
> > }
> >
> > static loff_t vaddr_to_offset(struct vm_area_struct *vma, unsigned long vaddr)
> > {
> > - return ((loff_t)vma->vm_pgoff << PAGE_SHIFT) + (vaddr - vma->vm_start);
> > + return ((loff_t)vma_start_pgoff(vma) << PAGE_SHIFT) +
> > + (vaddr - vma->vm_start);
> > }
>
> Something we've seen in this series is that perhaps something like
>
> static inline loff_t vma_start_off(vma)
> {
> return ((loff_t) vma_start_pgoff(vma)) << PAGE_SHIFT;
> }
>
> could be worth it.
Yeah I already thought about this kind of thing, but in the end decided against
it at least for now, maybe I could revisit with something like that added
though...
But given this series is being held off on already for acceptance, I'm not sure
adding _yet more_ changes will be welcomed.
Plus I worry people will get confused.
There's 2 forms I noticed:
1. effectively: linear_page_index(vma, address) << PAGE_SHIFT
I wanted to rewrite this as such, but you can't, because of course vaddr might
have non-page aligned bits (or tags) that you lose by doing that. So ugh.
You'd then need to write a slightly nuanced version like:
static inline unsigned long vma_offset(const struct vm_area_struct *vma,
const unsigned long address)
{
/* Retains page offset and tags. */
return address - vma->vm_start;
}
static inline unsigned long linear_page_offset(const struct vm_area_struct *vma,
const unsigned long address)
{
const unsigned long addr = vma_start_pgoff(vma) << PAGE_SHIFT;
addr += linear_delta(vma, address);
return addr;
}
(Could also do:)
static inline pgoff_t linear_page_delta(const struct vm_area_struct *vma,
const unsigned long address)
{
return vma_offset(vma, address) >> PAGE_SHIFT;
}
BUT.
I think this will confuse people. I already in a previous version of this series
named linear_page_delta() as linear_page_offset() and then changed it to avoid
confusion.
And I'm not sure it's really all that useful. Perhaps retaining vma_offset()
would be though.
2.
This is a much more useful form I noticed, effectively drivers doing the inverse
of a linear_page_index() to get the address:
static inline unsigned long linear_page_address(const struct vm_area_struct *vma,
const pgoff_t pgoff)
{
const pgoff_t page_delta = pgoff - vma_start_pgoff(vma);
const unsigned long offset = page_delta << PAGE_SHIFT;
return vma->vm_start + offset;
}
This is one that I think makes more sense.
But in general, I'd rather hold off from yet more churn here.
I'm making these changes to establish a basis for virtual page offsets
introduced in [0], rather than just cleaning up in general.
These changes are really to make it such that we more consistently use these
forms, so when I introduce the virt pgoff versions, it fits canonically into
that.
And also beacuse I may as well improve kernel code as I go :)
But I think adding yet more doesn't really serve the same purpose.
But it's food for a follow up perhaps?
>
> >
> > /**
> > @@ -1482,7 +1484,7 @@ static int unapply_uprobe(struct uprobe *uprobe, struct mm_struct *mm)
> > file_inode(vma->vm_file) != uprobe->inode)
> > continue;
> >
> > - offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> > + offset = (loff_t)vma_start_pgoff(vma) << PAGE_SHIFT;
> > if (uprobe->offset < offset ||
> > uprobe->offset >= offset + vma->vm_end - vma->vm_start)
> > continue;
> > @@ -2453,7 +2455,8 @@ static struct uprobe *find_active_uprobe_speculative(unsigned long bp_vaddr)
> > if (!vm_file)
> > return NULL;
> >
> > - offset = (loff_t)(vma->vm_pgoff << PAGE_SHIFT) + (bp_vaddr - vma->vm_start);
> > + offset = (loff_t)(vma_start_pgoff(vma) << PAGE_SHIFT) +
> > + (bp_vaddr - vma->vm_start);
>
> This is more extremely contrived logic that could be better expressed as
>
> loff_t vma_linear_off(vma, bp_vaddr);
See above.
>
> > uprobe = find_uprobe_rcu(vm_file->f_inode, offset);
> > if (!uprobe)
> > return NULL;
> > diff --git a/kernel/kcov.c b/kernel/kcov.c
> > index 1df373fb562b..b19b473c366a 100644
> > --- a/kernel/kcov.c
> > +++ b/kernel/kcov.c
> > @@ -512,7 +512,7 @@ static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
> >
> > spin_lock_irqsave(&kcov->lock, flags);
> > size = kcov->size * sizeof(unsigned long);
> > - if (kcov->area == NULL || vma->vm_pgoff != 0 ||
> > + if (kcov->area == NULL || vma_start_pgoff(vma) ||
>
> as a nit, perhaps vma_start_pgoff(vma) > 0
> would be a little more idiomatic.
I felt the if (<val>) form was more idiomatic?
>
> > vma->vm_end - vma->vm_start != size) {
> > res = -EINVAL;
> > goto exit;
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 56a328e94395..dfa493d54ef9 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -7613,7 +7613,8 @@ static int __rb_inc_dec_mapped(struct ring_buffer_per_cpu *cpu_buffer,
> > static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> > struct vm_area_struct *vma)
> > {
> > - unsigned long nr_subbufs, nr_pages, nr_vma_pages, pgoff = vma->vm_pgoff;
> > + unsigned long nr_subbufs, nr_pages, nr_vma_pages;
> > + pgoff_t pgoff = vma_start_pgoff(vma);
> > unsigned int subbuf_pages, subbuf_order;
> > struct page **pages __free(kfree) = NULL;
> > int p = 0, s = 0;
>
> Anyway, in general:
>
> Acked-by: Pedro Falcato <pfalcato@suse.de>
Thanks!
>
> --
> Pedro
[0]:https://lore.kernel.org/linux-mm/cover.1782745153.git.ljs@kernel.org/
^ permalink raw reply
* Re: [PATCH 26/30] mm/vma: introduce and use vma_set_pgoff()
From: Pedro Falcato @ 2026-07-02 11:34 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <37f4d951897641f304dba26f6f91ade03a50eb01.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:37PM +0100, Lorenzo Stoakes wrote:
> In order to lay the foundation for work that permits us to track the
> virtual page offset of MAP_PRIVATE file-backed mappings, we abstract the
> assignment of vma->vm_pgoff to vma_set_pgoff().
>
> We additionally add a lock check here using the newly introduced
> vma_assert_can_modify(). This asserts the VMA write lock if the VMA is
> attached.
>
> We also assert that, if this is an anonymous VMA and unfaulted, that its
> (virtual) page offset is equal to the page offset of the VMA's address.
>
> In order to maintain correctness given this assert, we also update
> __install_special_mapping() to invoke vma_set_range() after it's set
> vma->vm_ops (which determine whether the VMA is anonymous or not).
>
> We do not use vma_set_pgoff() in vm_area_init_from(), as at the point of
> forking, we don't necessarily have correct locking state.
>
> Updating vma_set_range() covers most cases, but in addition to this we also
> update insert_vm_struct(), compat_set_vma_from_desc() and nommu callers.
>
> We also update vma_add_pgoff() and vma_sub_pgoff() to use vma_set_pgoff().
>
> While we're here, we drop a BUG_ON() and update insert_vm_struct()'s
> comment to reflect the fact anonymous mappings can be added here.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 27/30] mm/vma: correct incorrect vma.h inclusion
From: Pedro Falcato @ 2026-07-02 11:40 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <22d0f4e3fe11f6fd1312734e242d008267ad142c.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:38PM +0100, Lorenzo Stoakes wrote:
> The only files which should be including vma.h are the implementation files
> for the core VMA logic - vma.c, vma_init.c, and vma_exec.c.
>
> This is in order to allow for userland testing of core VMA logic. In this
> cases, vma_internal.h and vma.h are included, providing both the
> dependencies upon which the core VMA logic requires and its declarations.
>
> Userland testable VMA logic is achieved by having separate vma_internal.h
> implementations for userland and kernel.
>
> Callers other than the core VMA implementation should include internal.h
> instead. This header does not need to include vma_internal.h as it only
> contains the vma.h declarations, for which the includes already present
> suffice.
>
> Update code to reflect this, update comments to reflect the fact there are
> 3 VMA implementation files and document things more clearly.
>
> While we're here, slightly improve the language of the comment describing
> vma_exec.c.
Two random thoughts:
1) perhaps vma.h -> vma_private.h
2) https://lore.kernel.org/all/CAHk-=wghMm2c+AYEcwYY7drSVXB27DYqc-ZXpFiq=XFs-w59wA@mail.gmail.com/
mm/vma/whatever.c :) would PROBABLY solve the issue of people snooping vma.h
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
> ---
> mm/mmu_notifier.c | 2 +-
> mm/nommu.c | 1 -
> mm/vma.c | 4 ++++
> mm/vma.h | 9 ++++++++-
> mm/vma_exec.c | 8 ++++++--
> mm/vma_init.c | 4 ++++
> mm/vma_internal.h | 4 ++--
> 7 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 245b74f39f91..df69ba6e797f 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -19,7 +19,7 @@
> #include <linux/sched/mm.h>
> #include <linux/slab.h>
>
> -#include "vma.h"
> +#include "internal.h"
>
> /* global SRCU for all MMs */
> DEFINE_STATIC_SRCU(srcu);
> diff --git a/mm/nommu.c b/mm/nommu.c
> index ba1c923c0942..4fef6fbbd6e9 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -41,7 +41,6 @@
> #include <asm/tlbflush.h>
> #include <asm/mmu_context.h>
> #include "internal.h"
> -#include "vma.h"
>
> unsigned long highest_memmap_pfn;
> int heap_stack_gap = 0;
> diff --git a/mm/vma.c b/mm/vma.c
> index d727150e377a..5c3062e0e706 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -4,6 +4,10 @@
> * VMA-specific functions.
> */
>
> +/*
> + * To allow for userland testing we place internal dependencies in
> + * vma_internal.h and external VMA API declarations in vma.h.
> + */
> #include "vma_internal.h"
> #include "vma.h"
>
> diff --git a/mm/vma.h b/mm/vma.h
> index 155eadda47aa..f4f885615a92 100644
> --- a/mm/vma.h
> +++ b/mm/vma.h
> @@ -2,7 +2,14 @@
> /*
> * vma.h
> *
> - * Core VMA manipulation API implemented in vma.c.
> + * Core VMA manipulation API implemented in vma.c, vma_init.c and vma_exec.c.
> + *
> + * Note that, in order for VMA logic to be userland testable, this header
> + * intentionally includes no dependencies.
> + *
> + * This is specifically scoped to mm-only. Users of this functionality (other
> + * than the core VMA implementation itself) should not include this header
> + * directly, but rather include internal.h.
> */
> #ifndef __MM_VMA_H
> #define __MM_VMA_H
> diff --git a/mm/vma_exec.c b/mm/vma_exec.c
> index 0107a6e3918c..c0f7ba2cfb27 100644
> --- a/mm/vma_exec.c
> +++ b/mm/vma_exec.c
> @@ -1,10 +1,14 @@
> // SPDX-License-Identifier: GPL-2.0-only
>
> /*
> - * Functions explicitly implemented for exec functionality which however are
> - * explicitly VMA-only logic.
> + * Functions provided for exec functionality which however are
> + * specifically VMA-only logic.
> */
>
> +/*
> + * To allow for userland testing we place internal dependencies in
> + * vma_internal.h and external VMA API declarations in vma.h.
> + */
> #include "vma_internal.h"
> #include "vma.h"
>
> diff --git a/mm/vma_init.c b/mm/vma_init.c
> index a459669a1654..715feee283f0 100644
> --- a/mm/vma_init.c
> +++ b/mm/vma_init.c
> @@ -5,6 +5,10 @@
> * between CONFIG_MMU and non-CONFIG_MMU kernel configurations.
> */
>
> +/*
> + * To allow for userland testing we place internal dependencies in
> + * vma_internal.h and external VMA API declarations in vma.h.
> + */
> #include "vma_internal.h"
> #include "vma.h"
>
> diff --git a/mm/vma_internal.h b/mm/vma_internal.h
> index 2da6d224c1a8..4d300e7bbaf4 100644
> --- a/mm/vma_internal.h
> +++ b/mm/vma_internal.h
> @@ -2,8 +2,8 @@
> /*
> * vma_internal.h
> *
> - * Headers required by vma.c, which can be substituted accordingly when testing
> - * VMA functionality.
> + * Headers required by vma.c, vma_init.c and vma_exec.c, which can be
> + * substituted accordingly when testing VMA functionality.
> */
>
> #ifndef __MM_VMA_INTERNAL_H
> --
> 2.54.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCH 28/30] mm/vma: use guard clauses in can_vma_merge_[before, after]()
From: Pedro Falcato @ 2026-07-02 11:41 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <213918ef85ed427d29d0635db6b07b15280d3bb0.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:39PM +0100, Lorenzo Stoakes wrote:
> Rather than combining a bunch of conditionals in a single expression,
> simplify by inverting the mergeability requirements into guard clauses.
>
> that is - instead of checking what must be true for the conditions to be
> met, instead check the inverse of the requirements and return false if any
> are true, defaulting to true.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/vma.c | 27 ++++++++++++++-------------
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index 5c3062e0e706..7201199fc668 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -215,13 +215,13 @@ static void init_multi_vma_prep(struct vma_prepare *vp,
> */
> static bool can_vma_merge_before(struct vma_merge_struct *vmg)
> {
> - if (is_mergeable_vma(vmg, /* merge_next = */ true) &&
> - is_mergeable_anon_vma(vmg, /* merge_next = */ true)) {
> - if (vmg_end_pgoff(vmg) == vma_start_pgoff(vmg->next))
> - return true;
> - }
> -
> - return false;
> + if (!is_mergeable_vma(vmg, /* merge_next = */ true))
> + return false;
> + if (!is_mergeable_anon_vma(vmg, /* merge_next = */ true))
> + return false;
> + if (vmg_end_pgoff(vmg) != vma_start_pgoff(vmg->next))
> + return false;
> + return true;
> }
>
> /*
> @@ -235,12 +235,13 @@ static bool can_vma_merge_before(struct vma_merge_struct *vmg)
> */
> static bool can_vma_merge_after(struct vma_merge_struct *vmg)
> {
> - if (is_mergeable_vma(vmg, /* merge_next = */ false) &&
> - is_mergeable_anon_vma(vmg, /* merge_next = */ false)) {
> - if (vma_end_pgoff(vmg->prev) == vmg_start_pgoff(vmg))
> - return true;
> - }
> - return false;
> + if (!is_mergeable_vma(vmg, /* merge_next = */ false))
> + return false;
> + if (!is_mergeable_anon_vma(vmg, /* merge_next = */ false))
> + return false;
> + if (vma_end_pgoff(vmg->prev) != vmg_start_pgoff(vmg))
> + return false;
> + return true;
> }
>
> static void __vma_link_file(struct vm_area_struct *vma,
Looks nicer, thanks.
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH 29/30] tools/testing/vma: default VMA flag bits to 64-bit
From: Pedro Falcato @ 2026-07-02 11:44 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <27cd07f6dd862d92410cf9db03f7c11e5f66854d.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:40PM +0100, Lorenzo Stoakes wrote:
> With all of the sanitisers turned on, setting the VMA flag bits depth to
> 128 by default results in overly long build times.
>
> Reduce this to 64 - we can always manipulate these later for testing of
> larger bitmaps as needed.
>
Hmm, what's the problem with the sanitizers? Shouldn't this just result in
slightly different codegen?
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> tools/testing/vma/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/vma/Makefile b/tools/testing/vma/Makefile
> index e72b45dedda5..ef6cc558afe1 100644
> --- a/tools/testing/vma/Makefile
> +++ b/tools/testing/vma/Makefile
> @@ -10,7 +10,7 @@ OFILES = $(SHARED_OFILES) main.o shared.o maple-shim.o
> TARGETS = vma
>
> # These can be varied to test different sizes.
> -CFLAGS += -DNUM_VMA_FLAG_BITS=128 -DNUM_MM_FLAG_BITS=128
> +CFLAGS += -DNUM_VMA_FLAG_BITS=64 -DNUM_MM_FLAG_BITS=64
>
> main.o: main.c shared.c shared.h vma_internal.h tests/merge.c tests/mmap.c tests/vma.c ../../../mm/vma.c ../../../mm/vma_init.c ../../../mm/vma_exec.c ../../../mm/vma.h include/custom.h include/dup.h include/stubs.h
>
> --
> 2.54.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCH 30/30] tools/testing/vma: output compared expression on ASSERT_[EQ, NE]()
From: Pedro Falcato @ 2026-07-02 11:53 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <432444fa4c12ae1c4047550e2b205d3e9bab458f.1782735110.git.ljs@kernel.org>
On Mon, Jun 29, 2026 at 01:23:41PM +0100, Lorenzo Stoakes wrote:
> Update the macros to output the compared values at hex for easier debugging
> when test asserts fail.
>
> Also remove unused IS_SET() macro.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> tools/testing/vma/shared.h | 31 +++++++++++++++++++------------
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/tools/testing/vma/shared.h b/tools/testing/vma/shared.h
> index ca4f1238f1c7..216be4cda369 100644
> --- a/tools/testing/vma/shared.h
> +++ b/tools/testing/vma/shared.h
> @@ -21,19 +21,28 @@
> } \
> } while (0)
>
> -#define ASSERT_TRUE(_expr) \
> - do { \
> - if (!(_expr)) { \
> - fprintf(stderr, \
> - "Assert FAILED at %s:%d:%s(): %s is FALSE.\n", \
> - __FILE__, __LINE__, __FUNCTION__, #_expr); \
> - return false; \
> - } \
> +#define __ASSERT_TRUE(_expr, _fmt, ...) \
> + do { \
> + if (!(_expr)) { \
> + fprintf(stderr, \
> + "Assert FAILED at %s:%d:%s(): %s is FALSE" \
> + _fmt ".\n", \
> + __FILE__, __LINE__, __FUNCTION__, #_expr \
> + __VA_OPT__(,) __VA_ARGS__); \
> + return false; \
> + } \
> } while (0)
>
> +#define __TO_SCALAR(x) ((unsigned long long)(uintptr_t)(x))
There's a slight footgun here: this can truncate 64-bit types in 32-bit archs.
Though it doesn't really matter in our case, I think.
> +
> +#define ASSERT_TRUE(_expr) __ASSERT_TRUE(_expr, "")
> #define ASSERT_FALSE(_expr) ASSERT_TRUE(!(_expr))
> -#define ASSERT_EQ(_val1, _val2) ASSERT_TRUE((_val1) == (_val2))
> -#define ASSERT_NE(_val1, _val2) ASSERT_TRUE((_val1) != (_val2))
> +#define ASSERT_EQ(_val1, _val2) \
> + __ASSERT_TRUE((_val1) == (_val2), " (0x%llx != 0x%llx)", \
> + __TO_SCALAR(_val1), __TO_SCALAR(_val2))
> +#define ASSERT_NE(_val1, _val2) \
> + __ASSERT_TRUE((_val1) != (_val2), " (0x%llx == 0x%llx)", \
> + __TO_SCALAR(_val1), __TO_SCALAR(_val2))
>
> #define ASSERT_FLAGS_SAME_MASK(_flags, _flags_other) \
> ASSERT_TRUE(vma_flags_same_mask((_flags), (_flags_other)))
> @@ -53,8 +62,6 @@
> #define ASSERT_FLAGS_NONEMPTY(_flags) \
> ASSERT_FALSE(vma_flags_empty(_flags))
>
> -#define IS_SET(_val, _flags) ((_val & _flags) == _flags)
> -
> extern bool fail_prealloc;
>
> /* Override vma_iter_prealloc() so we can choose to fail it. */
> --
> 2.54.0
Acked-by: Pedro Falcato <pfalcato@suse.de>
--
Pedro
^ permalink raw reply
* Re: [PATCH] tracing: Cleanup event_enable_trigger_parse() by using __free()
From: Markus Elfring @ 2026-07-02 11:58 UTC (permalink / raw)
To: linux-trace-kernel, Masami Hiramatsu, Mathieu Desnoyers,
Steven Rostedt
Cc: LKML
In-Reply-To: <20260701174829.67ab8a33@gandalf.local.home>
> The enable_data variable gets freed on most error paths in
> event_enable_trigger_parse(). Use free() to free it and just before
> returning normally, call no_free_ptr(enable_data) to keep it from being
> freed.
The conversion is incomplete for the application of scope-based resource management so far.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 4/4] rv/rtapp: Add wakeup monitor
From: Gabriele Monaco @ 2026-07-02 12:12 UTC (permalink / raw)
To: Nam Cao; +Cc: Steven Rostedt, linux-trace-kernel, linux-doc, linux-kernel
In-Reply-To: <87ldbtvoo8.fsf@yellow.woof>
On Thu, 2026-07-02 at 09:25 +0200, Nam Cao wrote:
> Gabriele Monaco <gmonaco@redhat.com> writes:
> > This looks good, but if I understand it correctly, the same violation should
> > be
> > spotted by both monitors from two different perspectives, but sleep catches
> > more
> > things (e.g. tasks using wrong sleeping ways despite their wakeup):
> >
> > # perf stat -a -e rv:error_sleep -e rv:error_wakeup -- stress-ng --cpu 5 -
> > -cpu-load 90 --sched rr -t 5
> >
> > Performance counter stats for 'system wide':
> >
> > 285
> > rv:error_sleep
> > 20
> > rv:error_wakeup
> >
> > Provided I don't really know what's happening down there (I just let the
> > stressor run free), this discrepancy is expected, right?
>
> Thanks for testing it.
>
> Beside monitoring low-prio task waking high-prio task, the rtapp/sleep
> monitor also checks that user uses the correct APIs for sleeping. So
> yes, this discrepancy is expected.
Alright makes sense, thanks.
Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
^ permalink raw reply
* Re: [PATCH 20/30] mm/vma: introduce vma_assert_can_modify()
From: Lorenzo Stoakes @ 2026-07-02 12:16 UTC (permalink / raw)
To: Pedro Falcato
Cc: Andrew Morton, Russell King, Dinh Nguyen, Simon Schuster,
James E . J . Bottomley, Helge Deller, Jarkko Sakkinen,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Ian Abbott, H Hartley Sweeten, Lucas Stach, David Airlie,
Simona Vetter, Patrik Jakobsson, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Clark, Dmitry Baryshkov, Tomi Valkeinen,
Thierry Reding, Mikko Perttunen, Jonathan Hunter,
Christian Koenig, Huang Rui, Ankit Agrawal, Alex Williamson,
Alexander Viro, Christian Brauner, Dan Williams, Muchun Song,
Oscar Salvador, David Hildenbrand, Suren Baghdasaryan,
Liam R . Howlett, Matthew Wilcox, Marek Szyprowski,
Peter Zijlstra, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Oleg Nesterov, Steven Rostedt, SeongJae Park,
Miaohe Lin, Hugh Dickins, Mike Rapoport, Kees Cook, Paolo Bonzini,
linux-kernel, linux-arm-kernel, linux-parisc, linux-sgx, etnaviv,
dri-devel, linux-arm-msm, freedreno, linux-tegra, kvm,
linux-fsdevel, nvdimm, linux-mm, iommu, linux-perf-users,
linux-trace-kernel, kasan-dev, damon, Rik van Riel, Harry Yoo,
Jann Horn
In-Reply-To: <akZHWwVgJfqCwA2W@pedro-suse.lan>
On Thu, Jul 02, 2026 at 12:16:32PM +0100, Pedro Falcato wrote:
> On Mon, Jun 29, 2026 at 01:23:31PM +0100, Lorenzo Stoakes wrote:
> > vma_assert_write_locked() and vma_assert_attached() are useful for their
> > own purposes, however VMA code absolutely does allow the modification of
> > non-write locked VMAs if they are at that point detached (i.e. unreachable
> > from anywhere).
> >
> > It's therefore useful to be able to assert that a VMA is either
> > detached (modification doesn't matter) or write locked (you're explicitly
> > locked for modification).
>
> Hmm, I was wondering why detached does not imply write_locked, and then
For one obviously when detaching they are also write locked (see
vma_mark_detached()) but yeah the point of this is when you have a VMA allocated
which doesn't hold the appropriate lock.
> realized that new VMAs aren't write-locked. Could we do it by default?
> Like a simple:
>
> vma->vm_lock_seq = __vma_raw_mm_seqnum(vma);
>
> might do the trick. I don't see why it wouldn't work? Is there some other
> case I am not considering?
Firstly, I'd rather not rework the VMA lock logic as part of this series. It's
subtle and such changes are tricky.
I'm trying to achieve the minimum changes while adding extra validation as I can
in preparation for the scalable CoW work.
And I'm not sure wanting to alter the fundamentals of VMA locks is a good reason
not to ack a patch :)
But since you bring it up...
There's subtleties here too.
- At what point do you do this assignment? If it's the VMA allocation logic,
it's not obvious then that you even have the mmap write lock necessarily. Now
you're making assumptions that might be broken, or broken in future.
Now everybody who allocates a VMA has to 'just know' that they need to assign
an mm and mark it write-locked (but in a special new VMA way) before setting
the pgoff.
- Detached means it is not currently in any tree, nor belongs necessarily to any
mm. So the concept of it being write locked is meaningless.
- It's broken to perform actions on a new VMA that is not yet linked into any
tree that would require the VMA write lock. Currently the code _explicitly_
asserts that a detached VMA is not attempted to be write locked.
- So we have a good way of catching people doing stupid or broken stuff to VMAs
that are not in the correct state (we currently _don't_ do that for detached
VMAs that _were_ in the tree, probably we should change that...!)
- You'd have to create a new function to do this since we explicitly disallow
doing this right now, and that's more complexity and then you're then
creating a whole new meaning as to what VMA write lock acquisition is,
which is even more added complexity.
- create_init_stack_vma() would break, so would hugetlb (lol) and static gate
VMAs explicitly do not belong to an mm, so there's simply no concept of them
being VMA write locked anyway.
- I'm not sure violating the invariant of seqnum = 0 = no write locked VMAs is
safe.
- Things get quite horrendous on fork (prior to us taking tmp's VMA write lock)
- you'd have to assign this field after duplicating the VMA midway through
attaching it to the new mm, where that mm has a new seqnum. But the new mm has
a seqnum of 0... so now you're having to duplicate it but alter what
vma_lock_init() does to reset the seqnum to 0 but then what if the
'duplication' logic asserts VMA write locked?
It's very chicken and egg - on VMA duplication you want to be able to write the
very fields that you need to do anything with the VMA prior to it being linked
in anywhere.
And we probably don't want to bake in the assumption that to change fundamental
fields requires that you always hold the write lock as a consequence.
>
> >
> > Therefore introduce vma_assert_can_modify() for this purpose.
> >
> > While we're here, make vma_is_attached() available generally - if
> > !CONFIG_PER_VMA_LOCKS, then there's no sense in which a VMA is
> > detached (vma_mark_detached() is a noop), so have this default to true in
> > this case.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> > include/linux/mmap_lock.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> > index 04b8f61ece5d..d513286d8160 100644
> > --- a/include/linux/mmap_lock.h
> > +++ b/include/linux/mmap_lock.h
> > @@ -506,6 +506,8 @@ static inline __must_check
> > int vma_start_write_killable(struct vm_area_struct *vma) { return 0; }
> > static inline void vma_assert_write_locked(struct vm_area_struct *vma)
> > { mmap_assert_write_locked(vma->vm_mm); }
> > +static inline bool vma_is_attached(struct vm_area_struct *vma)
> > + { return true; }
> > static inline void vma_assert_attached(struct vm_area_struct *vma) {}
> > static inline void vma_assert_detached(struct vm_area_struct *vma) {}
> > static inline void vma_mark_attached(struct vm_area_struct *vma) {}
> > @@ -530,6 +532,12 @@ static inline void vma_assert_stabilised(struct vm_area_struct *vma)
> >
> > #endif /* CONFIG_PER_VMA_LOCK */
> >
> > +static inline void vma_assert_can_modify(struct vm_area_struct *vma)
> > +{
> > + if (vma_is_attached(vma))
> > + vma_assert_write_locked(vma);
> > +}
> > +
> > static inline void mmap_write_lock(struct mm_struct *mm)
> > {
> > __mmap_lock_trace_start_locking(mm, true);
> > --
> > 2.54.0
> >
>
> --
> Pedro
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH v3 01/11] dt-bindings: reserved-memory: Document Tegra VPR
From: Thierry Reding @ 2026-07-02 12:58 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Christian Borntraeger, Rasmus Villemoes, dri-devel,
David Hildenbrand, Yury Norov, linux-media, linux-kernel,
Robin Murphy, Simona Vetter, linux-trace-kernel,
Krzysztof Kozlowski, Christian König, linux-mm, Russell King,
Will Deacon, Masami Hiramatsu, David Airlie, Vasily Gorbik,
Benjamin Gaignard, linaro-mm-sig, Heiko Carstens, Sumit Semwal,
Thierry Reding, Maxime Ripard, Thierry Reding, John Stultz,
Luca Ceresoli, Vlastimil Babka, Brian Starkey, Mikko Perttunen,
Michal Hocko, Steven Rostedt, Jonathan Hunter, Maarten Lankhorst,
Sowjanya Komatineni, Suren Baghdasaryan, linux-arm-kernel,
linux-s390, devicetree, Liam R. Howlett, linux-tegra,
Catalin Marinas, Marek Szyprowski, Conor Dooley,
Thomas Zimmermann, Andrew Morton, Gerald Schaefer,
Alexander Gordeev, Lorenzo Stoakes, T.J. Mercier,
Mathieu Desnoyers, iommu, Mike Rapoport, Sven Schnelle
In-Reply-To: <178293558945.1610040.13281502080616690110.robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]
On Wed, Jul 01, 2026 at 02:53:10PM -0500, Rob Herring (Arm) wrote:
>
> On Wed, 01 Jul 2026 18:08:12 +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > The Video Protection Region (VPR) found on NVIDIA Tegra chips is a
> > region of memory that is protected from CPU accesses. It is used to
> > decode and play back DRM protected content.
> >
> > It is a standard reserved memory region that can exist in two forms:
> > static VPR where the base address and size are fixed (uses the "reg"
> > property to describe the memory) and a resizable VPR where only the
> > size is known upfront and the OS can allocate it wherever it can be
> > accomodated.
> >
> > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Changes in v2:
> > - add examples for fixed and resizable VPR
> > ---
> > .../nvidia,tegra-video-protection-region.yaml | 76 ++++++++++++++++++++++
> > 1 file changed, 76 insertions(+)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.example.dtb: protected@2a8000000 (nvidia,tegra-video-protection-region): reg: [[2, 2818572288], [0, 1879048192]] is too long
> from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection-region.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra-video-protection-region.example.dtb: protected@2a8000000 (nvidia,tegra-video-protection-region): Unevaluated properties are not allowed ('no-map', 'reg' were unexpected)
> from schema $id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra-video-protection-region.yaml
Any ideas why that second error shows up? It turns out that it goes away
when the first one is fixed (which admittedly is a stupid mistake), but
I spent quite a bit of time looking for a fix before realizing that it's
only a side-effect of the first.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] tracing: Remove trace_printk.h from kernel.h
From: Uwe Kleine-König @ 2026-07-02 13:43 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, regressions
In-Reply-To: <20260624081948.301578807@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]
Hello,
On Wed, Jun 24, 2026 at 04:18:08AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> There have been complaints about trace_printk.h causing more build time
> for being in kernel.h. Move it out of kernel.h and place it in the headers
> and C files that use it.
>
> Link: https://lore.kernel.org/all/CAHk-=wikCBeVFjVXiY4o-oepdbjAoir5+TcAgtL12c4u1TpZLQ@mail.gmail.com/
>
> Suggested-by: Yury Norov <yury.norov@gmail.com>
> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
This patch became commit 9cbc3d9806d3 ("tracing: Remove trace_printk.h
from kernel.h") that currently is in next via
https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git trace/fixes
.
It creates a build regression for an ARCH=arc allmodconfig build:
CC lib/test_context-analysis.o
In file included from include/linux/local_lock_internal.h:8,
from include/linux/local_lock.h:5,
from lib/test_context-analysis.c:9:
include/linux/local_lock_internal.h: In function ‘local_lock_acquire’:
include/linux/lockdep.h:541:87: error: ‘_THIS_IP_’ undeclared (first use in this function)
541 | l) lock_acquire_exclusive(l, 0, 0, NULL, _THIS_IP_)
| ^~~~~~~~~
include/linux/lockdep.h:509:88: note: in definition of macro ‘lock_acquire_exclusive’
509 | re_exclusive(l, s, t, n, i) lock_acquire(l, s, t, 0, 1, n, i)
| ^
include/linux/local_lock_internal.h:46:9: note: in expansion of macro ‘lock_map_acquire’
46 | lock_map_acquire(&l->dep_map);
| ^~~~~~~~~~~~~~~~
include/linux/lockdep.h:541:87: note: each undeclared identifier is reported only once for each function it appears in
541 | l) lock_acquire_exclusive(l, 0, 0, NULL, _THIS_IP_)
| ^~~~~~~~~
include/linux/lockdep.h:509:88: note: in definition of macro ‘lock_acquire_exclusive’
509 | re_exclusive(l, s, t, n, i) lock_acquire(l, s, t, 0, 1, n, i)
| ^
include/linux/local_lock_internal.h:46:9: note: in expansion of macro ‘lock_map_acquire’
46 | lock_map_acquire(&l->dep_map);
| ^~~~~~~~~~~~~~~~
include/linux/local_lock_internal.h: In function ‘local_trylock_acquire’:
include/linux/lockdep.h:542:87: error: ‘_THIS_IP_’ undeclared (first use in this function)
542 | try(l) lock_acquire_exclusive(l, 0, 1, NULL, _THIS_IP_)
| ^~~~~~~~~
include/linux/lockdep.h:509:88: note: in definition of macro ‘lock_acquire_exclusive’
509 | re_exclusive(l, s, t, n, i) lock_acquire(l, s, t, 0, 1, n, i)
| ^
include/linux/local_lock_internal.h:53:9: note: in expansion of macro ‘lock_map_acquire_try’
53 | lock_map_acquire_try(&l->dep_map);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/local_lock_internal.h: In function ‘local_lock_release’:
include/linux/lockdep.h:545:65: error: ‘_THIS_IP_’ undeclared (first use in this function)
545 | fine lock_map_release(l) lock_release(l, _THIS_IP_)
| ^~~~~~~~~
include/linux/local_lock_internal.h:62:9: note: in expansion of macro ‘lock_map_release’
62 | lock_map_release(&l->dep_map);
| ^~~~~~~~~~~~~~~~
make[5]: *** [scripts/Makefile.build:289: lib/test_context-analysis.o] Error 1
make[4]: *** [scripts/Makefile.build:549: lib] Error 2
make[3]: *** [Makefile:2184: .] Error 2
make[2]: *** [Makefile:372: __build_one_by_one] Error 2
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Leaving directory '/home/uwe/work/kbuild/arc'
make: *** [Makefile:248: __sub-make] Error 2
#regzbot introduced: 9cbc3d9806d3
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 01/17] rv: Use generic rv_this for the rv_monitor variable in LTL
From: Nam Cao @ 2026-07-02 13:43 UTC (permalink / raw)
To: Gabriele Monaco, linux-trace-kernel, linux-kernel, Steven Rostedt,
Gabriele Monaco, Masami Hiramatsu
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260625121440.116317-2-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> Align the rv_monitor variable name in LTL to the generic rv_this as it
> is already done for DA/HA monitors. This improves consistency and eases
> assumptions across model classes.
>
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add set_memory_device() and set_memory_normal()
From: Thierry Reding @ 2026-07-02 13:46 UTC (permalink / raw)
To: Will Deacon
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Hunter,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Sowjanya Komatineni, Luca Ceresoli,
Mikko Perttunen, Yury Norov, Rasmus Villemoes, Russell King,
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Marek Szyprowski, Robin Murphy, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Catalin Marinas, Thierry Reding, devicetree, linux-tegra,
linux-kernel, dri-devel, linux-media, linux-arm-kernel,
linux-s390, linux-mm, iommu, linaro-mm-sig, linux-trace-kernel,
Thierry Reding, Chun Ng
In-Reply-To: <akYs91INHMXMTI-t@willie-the-truck>
[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]
On Thu, Jul 02, 2026 at 10:18:47AM +0100, Will Deacon wrote:
> On Wed, Jul 01, 2026 at 06:08:15PM +0200, Thierry Reding wrote:
> > From: Chun Ng <chunn@nvidia.com>
> >
> > Add helpers to swap PROT_NORMAL and PROT_DEVICE_nGnRnE protection bits
> > on a kernel-linear-map range.
>
> That sounds like a really terrible idea. Why is this necessary and how
> does it interact with things like load_unaligned_zeropad()?
This is necessary because once the memory controller has walled off the
new memory region the CPU must not access it under any circumstances or
it'll cause the CPU to lock up (I think technically it'll hit an SError
but in practice that just means it'll freeze, as far as I can tell).
Probably doesn't interact well at all with load_unaligned_zeropad().
> I think you should unmap the memory from the linear map and memremap()
> it instead.
Given that the memory can never be accessed by the CPU after the memory
controller locks it down, I don't think we'll even need memremap(). The
only thing we really need is the sg_table we hand out via the DMA BUFs
so that they can be used by device drivers to program their DMA engines
internally.
Looking through some of the architecture code around this, shouldn't we
simply be using set_memory_encrypted() and set_memory_decrypted() for
this? While they might've been created for slightly other use-cases,
they seem to be doing exactly what we want (i.e. remove the page range
from the linear mapping and flushing it, or restoring the valid bit and
standard permissions, respectively).
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 02/11] dt-bindings: display: tegra: Document memory regions
From: Thierry Reding @ 2026-07-02 13:47 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: linaro-mm-sig, Lorenzo Stoakes, Sven Schnelle, Gerald Schaefer,
Thomas Zimmermann, Yury Norov, linux-media, linux-trace-kernel,
Rasmus Villemoes, Jonathan Hunter, linux-s390, Masami Hiramatsu,
Vlastimil Babka, Heiko Carstens, Mikko Perttunen,
David Hildenbrand, Steven Rostedt, iommu, linux-kernel,
Simona Vetter, Mike Rapoport, Maarten Lankhorst, Robin Murphy,
Russell King, dri-devel, Maxime Ripard, Marek Szyprowski,
Vasily Gorbik, Brian Starkey, Krzysztof Kozlowski,
Christian Borntraeger, John Stultz, Christian König,
Thierry Reding, devicetree, Benjamin Gaignard, Catalin Marinas,
linux-arm-kernel, Alexander Gordeev, Mathieu Desnoyers, linux-mm,
Sumit Semwal, Will Deacon, Thierry Reding, Luca Ceresoli,
Liam R. Howlett, Andrew Morton, Suren Baghdasaryan,
Sowjanya Komatineni, linux-tegra, Conor Dooley, Michal Hocko,
T.J. Mercier, David Airlie
In-Reply-To: <178293559078.1610192.17087150631381044391.robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]
On Wed, Jul 01, 2026 at 02:53:11PM -0500, Rob Herring (Arm) wrote:
>
> On Wed, 01 Jul 2026 18:08:13 +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Add the memory-region and memory-region-names properties to the bindings
> > for the display controllers and the host1x engine found on various Tegra
> > generations. These memory regions are used to access firmware-provided
> > framebuffer memory as well as the video protection region.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Changes in v3:
> > - document properties for VIC
> > ---
> > .../devicetree/bindings/display/tegra/nvidia,tegra124-vic.yaml | 8 ++++++++
> > .../devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml | 10 ++++++++++
> > .../devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml | 10 +++++++++-
> > .../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 7 +++++++
> > 4 files changed, 34 insertions(+), 1 deletion(-)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: 'anyOf' conditional failed, one must be fixed:
> 'maxitems' is not one of ['$ref', 'additionalItems', 'additionalProperties', 'allOf', 'anyOf', 'const', 'contains', 'default', 'dependencies', 'dependentRequired', 'dependentSchemas', 'deprecated', 'description', 'else', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'items', 'if', 'minItems', 'minimum', 'maxItems', 'maximum', 'multipleOf', 'not', 'oneOf', 'pattern', 'patternProperties', 'properties', 'required', 'then', 'typeSize', 'unevaluatedProperties', 'uniqueItems']
> 'type' was expected
> from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names:items: {'enum': ['framebuffer', 'protected']} is not of type 'array'
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: Additional properties are not allowed ('maxitems' was unexpected)
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names:items: {'enum': ['framebuffer', 'protected']} is not of type 'array'
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dc.yaml: properties:memory-region-names: Additional properties are not allowed ('maxitems' was unexpected)
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
Ugh... looks like these are all because I mistyped maxItems as maxitems.
Oh well. Sorry for the noise.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 03/17] verification/rvgen: Improve rv_dir discovery in RVGenerator
From: Nam Cao @ 2026-07-02 13:53 UTC (permalink / raw)
To: Gabriele Monaco, linux-trace-kernel, linux-kernel, Steven Rostedt,
Gabriele Monaco
Cc: Thomas Weissschuh, Tomas Glozar, John Kacur, Wen Yang
In-Reply-To: <20260625121440.116317-4-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> The RVGenerator class can find the RV directory (kernel/trace/rv) in the
> kernel tree to do some auto patching. This works by assuming PWD is
> either the kernel tree or tools/verification, which isn't always the
> case (e.g. when running from selftests).
>
> Make discovery more robust by relying on the absolute path of the
> current script and traversing backwards the right number of times.
> This should work from any location if rvgen is in the kernel tree.
Agree.
> + # find the kernel tree root relative to this file's location
> + current_dir = os.path.dirname(os.path.abspath(__file__))
> + kernel_root = os.path.abspath(os.path.join(current_dir, "../../../.."))
The "../../../.." makes me sad.
We can find the git project root instead. For example:
def getGitRoot():
return subprocess.Popen(['git', 'rev-parse', '--show-toplevel'], stdout=subprocess.PIPE).communicate()[0].rstrip().decode('utf-8')
(stolen from https://stackoverflow.com/questions/22081209/find-the-root-of-the-git-repository-where-the-file-lives)
But that's not important, up to you.
Nam
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox