Linux Trace Kernel
 help / color / mirror / Atom feed
* 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 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 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: [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 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: [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 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 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 v8 17/46] KVM: guest_memfd: Advertise KVM_SET_MEMORY_ATTRIBUTES2 ioctl
From: Xiaoyao Li @ 2026-07-02 10:51 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
	david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
	qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
	tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
	suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
	H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
	Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
	Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
	Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
	Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
	Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
	linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
	linux-coco
In-Reply-To: <akU7uAKb5E_Tklx-@google.com>

On 7/2/2026 12:09 AM, Sean Christopherson wrote:
> On Wed, Jul 01, 2026, Xiaoyao Li wrote:
>> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
>>> @@ -4969,6 +4973,11 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
>>>    		return 1;
>>>    	case KVM_CAP_GUEST_MEMFD_FLAGS:
>>>    		return kvm_gmem_get_supported_flags(kvm);
>>> +	case KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES:
>>> +		if (!gmem_in_place_conversion || !kvm_supports_private_mem(kvm))
>>> +			return 0;
>>> +
>>> +		return KVM_MEMORY_ATTRIBUTE_PRIVATE;
>>>    #endif
>>>    	default:
>>>    		break;
>>
>> this looks inconsistent with the
>>
>> 	case KVM_SET_MEMORY_ATTRIBUTES2:
>> 		if (!gmem_in_place_conversion)
>> 			return -ENOTTY;
>>
>> Well, the check of
>>
>> 	if (!kvm_arch_has_private_mem(f->kvm))
>> 		return -EINVAL;
>>
>> is buried in the following kvm_gmem_set_attributes(). How about moving of
>> kvm_arch_has_private_mem() check to put it along with
>> gmem_in_place_conversion check in kvm_gmem_ioctl() in Patch 13?
> 
> Me confused, patch 13 already adds the kvm_arch_has_private_mem() in
> kvm_gmem_set_attributes().

I wanted to make the check in KVM_SET_MEMORY_ATTRIBUTES2 in Patch 13 
like something below:

	case KVM_SET_MEMORY_ATTRIBUTES2:
		if (!gmem_in_place_conversion || !kvm_arch_has_private_mem(f->kvm))
		return -EXXX;

and finally, with the introduction of kvm_supports_private_mem() in this 
patch, it becomes:

	case KVM_SET_MEMORY_ATTRIBUTES2:
		if (!gmem_in_place_conversion || !kvm_supports_private_mem(f->kvm))
		return -EXXX;

So that the guard for KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES and 
KVM_SET_MEMORY_ATTRIBUTES2 is consistent.

> That said, the ordering here is wonky and misleading.  A cursory read of the series
> would make one think that waiting to advertise KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES
> makes it safe/ok for KVM to plumb in support for KVM_SET_MEMORY_ATTRIBUTES2 over
> multiple patches.  But that's not actually true, because the ioctl becomes live
> the instant the code exists, userspace doesn't need to wait for KVM to formally
> advertise support.
> 
> To further confuse matters, it is actually safe/ok to iteratively add support,
> because it's all effectively dead code until "Let userspace disable per-VM mem
> attributes, enable per-gmem attributes".

yeah, before patch 24, gmem_in_place_conversion is always false. So 
KVM_SET_MEMORY_ATTRIBUTES2 on gmem fd always return -ENOTTY.

> So, I think we should go a step further than what I think Xiaoyao is suggesting,
> and fully squash patch 17 into patch 13.  That way the reader doesn't have to jump
> through as many mental hoops to piece together what is happening.  It'll obviously
> be a bigger patch, but should be easier to review/understand overall.
> 
> Oh, and that combined patch should carve out error_offset straightaway, so that
> the full uAPI can be reviewed in a single patch.

It sounds good.

^ permalink raw reply

* Re: [PATCH 13/30] mm/vma: refactor vmg_adjust_set_range() for clarity
From: Lorenzo Stoakes @ 2026-07-02 10:50 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: <akY-Z1fsp9rHSc70@pedro-suse.lan>

On Thu, Jul 02, 2026 at 11:37:11AM +0100, Pedro Falcato wrote:
> On Mon, Jun 29, 2026 at 01:23:24PM +0100, Lorenzo Stoakes wrote:
> > Add comments with ASCII diagrams to describe what we're doing, avoid
> > dubious use of PHYS_PFN(), and use vma_start_pgoff().
> >
> > The most complicated scenario represented here is vmg->__adjust_next_start
> > - when this is set, vmg->[start, end] actually indicate the range to be
> > retained, so take special care to describe this accurately.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> >  mm/vma.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
> >  1 file changed, 47 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/vma.c b/mm/vma.c
> > index 6296acecf3b7..1e99fe8aa6ef 100644
> > --- a/mm/vma.c
> > +++ b/mm/vma.c
> > @@ -704,11 +704,54 @@ static void vmg_adjust_set_range(struct vma_merge_struct *vmg)
> >  	pgoff_t pgoff;
> >
> >  	if (vmg->__adjust_middle_start) {
> > -		adjust = vmg->middle;
> > -		pgoff = adjust->vm_pgoff + PHYS_PFN(vmg->end - adjust->vm_start);
> > +		/*
> > +		 * vmg->start    vmg->end
> > +		 * |             |
> > +		 * v    merge    v
> > +		 * <------------->
> > +		 *         delta
> > +		 *        <------>
> > +		 * |------|----------------|
> > +		 * | prev |    middle      |
> > +		 * |------|----------------|
> > +		 *        ^
> > +		 *        |
> > +		 *        middle->vm_start
> > +		 */
> > +		struct vm_area_struct *middle = vmg->middle;
>
> FWIW this can be simplified to
> 		adjust = middle;
> 		const unsigned long delta = vmg->end - adjust->vm_start;
>
> But I guess you're looking for explicitness here?

Yeah I'm intentionally trying to make that explicit as this code is very
confusing, so people don't have to think 'oh what was adjust again?'.

>
> > +		const unsigned long delta = vmg->end - middle->vm_start;
> > +
> > +		pgoff = vma_start_pgoff(middle) + (delta >> PAGE_SHIFT);
> > +		adjust = middle;
> >  	} else if (vmg->__adjust_next_start) {
> > -		adjust = vmg->next;
> > -		pgoff = adjust->vm_pgoff - PHYS_PFN(adjust->vm_start - vmg->end);
> > +		/*
> > +		 *                Originally:
> > +		 *
> > +		 *            vmg->start   vmg->end
> > +		 *            |            |
> > +		 *            v    merge   v
> > +		 *            <------------>
> > +		 *            .            .
> > +		 * merge_existing_range() updates to:
> > +		 *            .            .
> > +		 * vmg->start vmg->end     .
> > +		 * |          |            .
> > +		 * v  retain  v            .
> > +		 * <---------->            .
> > +		 *             delta       .
> > +		 *            <----->      .
> > +		 * |----------------|------|
> > +		 * |    middle      | next |
> > +		 * |----------------|------|
> > +		 *                  ^
> > +		 *                  |
> > +		 *                  next->vm_start
> > +		 */
> > +		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;
> >  	}
>
> Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Thanks!

>
> --
> Pedro

Cheers, Lorenzo

^ permalink raw reply

* Re: [PATCH 16/30] mm/vma: use vma_start_pgoff(), linear_page_index() in mm code
From: Lorenzo Stoakes @ 2026-07-02 10:49 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: <akZAwT-QWhA1wdA9@pedro-suse.lan>

On Thu, Jul 02, 2026 at 11:47:10AM +0100, Pedro Falcato wrote:
> small nit: perhaps the subject should simply have mm: as it hits mm in general
>
> On Mon, Jun 29, 2026 at 01:23:27PM +0100, Lorenzo Stoakes wrote:
> > There are many instances in which linear_page_index() (as well as
> > linear_page_delta()) is open-coded, which is confusing and inconsistent.
> >
> > Additionally, vma->vm_pgoff doesn't necessarily make it clear that this is
> > the page offset of the start of the VMA range.
> >
> > Doing so also aids greppability.
> >
> > So use vma_start_pgoff() in favour of directly accessing vma->vm_pgoff, and
> > linear_page_index() where we can.
> >
> > This also lays the ground for future changes which will add an anonymous
> > page offset in order to be able to index MAP_PRIVATE-file backed anon
> > folios in terms of their virtual page offset.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> > ---
> >  include/linux/huge_mm.h    |  1 +
> >  include/linux/hugetlb.h    |  3 +--
> >  include/linux/pagemap.h    |  2 +-
> >  mm/damon/vaddr.c           |  5 +++--
> >  mm/debug.c                 |  2 +-
> >  mm/filemap.c               |  7 ++++---
> >  mm/huge_memory.c           |  2 +-
> >  mm/hugetlb.c               | 11 ++++-------
> >  mm/internal.h              | 24 ++++++++++++++----------
> >  mm/khugepaged.c            |  3 ++-
> >  mm/madvise.c               |  6 +++---
> >  mm/mapping_dirty_helpers.c |  2 +-
> >  mm/memory.c                | 25 +++++++++++++------------
> >  mm/mempolicy.c             | 13 +++++++------
> >  mm/mremap.c                | 12 ++++--------
> >  mm/msync.c                 |  4 ++--
> >  mm/nommu.c                 |  7 ++++---
> >  mm/pagewalk.c              |  2 +-
> >  mm/shmem.c                 |  9 +++++----
> >  mm/userfaultfd.c           |  4 ++--
> >  mm/util.c                  |  4 ++--
> >  mm/vma.c                   | 15 +++++++--------
> >  mm/vma_exec.c              |  4 ++--
> >  mm/vma_init.c              |  2 +-
> >  24 files changed, 86 insertions(+), 83 deletions(-)
> >
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index ad20f7f8c179..653b81d08fe7 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -230,6 +230,7 @@ static inline bool thp_vma_suitable_order(struct vm_area_struct *vma,
> >
> >  	/* Don't have to check pgoff for anonymous vma */
> >  	if (!vma_is_anonymous(vma)) {
> > +		/* vma_start_pgoff() in mm.h so not available. */
>
> Yay for gigaheaders...

Yup C headers are a constant pain :)

>
> >  		if (!IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) - vma->vm_pgoff,
> >  				hpage_size >> PAGE_SHIFT))
> >  			return false;
> > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> > index 2abaf99321e9..8390f50604d6 100644
> > --- a/include/linux/hugetlb.h
> > +++ b/include/linux/hugetlb.h
> > @@ -792,8 +792,7 @@ static inline pgoff_t hugetlb_linear_page_index(struct vm_area_struct *vma,
> >  {
> >  	struct hstate *h = hstate_vma(vma);
> >
> > -	return ((address - vma->vm_start) >> huge_page_shift(h)) +
> > -		(vma->vm_pgoff >> huge_page_order(h));
> > +	return linear_page_index(vma, address) >> huge_page_order(h);
> >  }
> >
>
> Anyway, nothing jumped out at me.
>
> Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Thanks!

>
>
> --
> Pedro

Cheers, Lorenzo

^ permalink raw reply

* Re: [PATCH 16/30] mm/vma: use vma_start_pgoff(), linear_page_index() in mm code
From: Pedro Falcato @ 2026-07-02 10:47 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: <33d79008948391d30bab38db5ae31072ce12f0a1.1782735110.git.ljs@kernel.org>

small nit: perhaps the subject should simply have mm: as it hits mm in general

On Mon, Jun 29, 2026 at 01:23:27PM +0100, Lorenzo Stoakes wrote:
> There are many instances in which linear_page_index() (as well as
> linear_page_delta()) is open-coded, which is confusing and inconsistent.
> 
> Additionally, vma->vm_pgoff doesn't necessarily make it clear that this is
> the page offset of the start of the VMA range.
> 
> Doing so also aids greppability.
> 
> So use vma_start_pgoff() in favour of directly accessing vma->vm_pgoff, and
> linear_page_index() where we can.
> 
> This also lays the ground for future changes which will add an anonymous
> page offset in order to be able to index MAP_PRIVATE-file backed anon
> folios in terms of their virtual page offset.
> 
> No functional change intended.
> 
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
>  include/linux/huge_mm.h    |  1 +
>  include/linux/hugetlb.h    |  3 +--
>  include/linux/pagemap.h    |  2 +-
>  mm/damon/vaddr.c           |  5 +++--
>  mm/debug.c                 |  2 +-
>  mm/filemap.c               |  7 ++++---
>  mm/huge_memory.c           |  2 +-
>  mm/hugetlb.c               | 11 ++++-------
>  mm/internal.h              | 24 ++++++++++++++----------
>  mm/khugepaged.c            |  3 ++-
>  mm/madvise.c               |  6 +++---
>  mm/mapping_dirty_helpers.c |  2 +-
>  mm/memory.c                | 25 +++++++++++++------------
>  mm/mempolicy.c             | 13 +++++++------
>  mm/mremap.c                | 12 ++++--------
>  mm/msync.c                 |  4 ++--
>  mm/nommu.c                 |  7 ++++---
>  mm/pagewalk.c              |  2 +-
>  mm/shmem.c                 |  9 +++++----
>  mm/userfaultfd.c           |  4 ++--
>  mm/util.c                  |  4 ++--
>  mm/vma.c                   | 15 +++++++--------
>  mm/vma_exec.c              |  4 ++--
>  mm/vma_init.c              |  2 +-
>  24 files changed, 86 insertions(+), 83 deletions(-)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index ad20f7f8c179..653b81d08fe7 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -230,6 +230,7 @@ static inline bool thp_vma_suitable_order(struct vm_area_struct *vma,
>  
>  	/* Don't have to check pgoff for anonymous vma */
>  	if (!vma_is_anonymous(vma)) {
> +		/* vma_start_pgoff() in mm.h so not available. */

Yay for gigaheaders...

>  		if (!IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) - vma->vm_pgoff,
>  				hpage_size >> PAGE_SHIFT))
>  			return false;
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2abaf99321e9..8390f50604d6 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -792,8 +792,7 @@ static inline pgoff_t hugetlb_linear_page_index(struct vm_area_struct *vma,
>  {
>  	struct hstate *h = hstate_vma(vma);
>  
> -	return ((address - vma->vm_start) >> huge_page_shift(h)) +
> -		(vma->vm_pgoff >> huge_page_order(h));
> +	return linear_page_index(vma, address) >> huge_page_order(h);
>  }
>  

Anyway, nothing jumped out at me.

Reviewed-by: Pedro Falcato <pfalcato@suse.de>


-- 
Pedro

^ permalink raw reply

* Re: [PATCH 15/30] mm: introduce and use linear_page_delta()
From: Pedro Falcato @ 2026-07-02 10:42 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: <eedf589778aaab33e6df2ad6556dcde536e13460.1782735110.git.ljs@kernel.org>

On Mon, Jun 29, 2026 at 01:23:26PM +0100, Lorenzo Stoakes wrote:
> It's often useful to obtain the number of pages a given address lies at
> within a VMA.
> 
> Add linear_page_delta() to determine this and update linear_page_index() to
> make use of it.
> 
> Add comments to describe both linear_page_delta() and linear_page_index().
> 
> 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 14/30] mm/vma: minor cleanup of expand_[upwards, downwards]()
From: Pedro Falcato @ 2026-07-02 10: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: <b24f70b72f0a9e2a37b904e5b59d80b88bd42e4a.1782735110.git.ljs@kernel.org>

On Mon, Jun 29, 2026 at 01:23:25PM +0100, Lorenzo Stoakes wrote:
> Adjust the stack expansion functions expand_upwards() and
> expand_downwards() such that they are expressed in terms of named constant
> values, and make use of vma_start_pgoff().
> 
> This clearly documents that we are referencing the page offset of the start
> of the VMA.
> 
> Additionally this cleans up the overflow check in expand_upwards().
> 
> 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 13/30] mm/vma: refactor vmg_adjust_set_range() for clarity
From: Pedro Falcato @ 2026-07-02 10:37 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: <ada7972f49ea7f1ff1df6d11e4651f270444f8fd.1782735110.git.ljs@kernel.org>

On Mon, Jun 29, 2026 at 01:23:24PM +0100, Lorenzo Stoakes wrote:
> Add comments with ASCII diagrams to describe what we're doing, avoid
> dubious use of PHYS_PFN(), and use vma_start_pgoff().
> 
> The most complicated scenario represented here is vmg->__adjust_next_start
> - when this is set, vmg->[start, end] actually indicate the range to be
> retained, so take special care to describe this accurately.
> 
> No functional change intended.
> 
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
>  mm/vma.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vma.c b/mm/vma.c
> index 6296acecf3b7..1e99fe8aa6ef 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -704,11 +704,54 @@ static void vmg_adjust_set_range(struct vma_merge_struct *vmg)
>  	pgoff_t pgoff;
>  
>  	if (vmg->__adjust_middle_start) {
> -		adjust = vmg->middle;
> -		pgoff = adjust->vm_pgoff + PHYS_PFN(vmg->end - adjust->vm_start);
> +		/*
> +		 * vmg->start    vmg->end
> +		 * |             |
> +		 * v    merge    v
> +		 * <------------->
> +		 *         delta
> +		 *        <------>
> +		 * |------|----------------|
> +		 * | prev |    middle      |
> +		 * |------|----------------|
> +		 *        ^
> +		 *        |
> +		 *        middle->vm_start
> +		 */
> +		struct vm_area_struct *middle = vmg->middle;

FWIW this can be simplified to
		adjust = middle;
		const unsigned long delta = vmg->end - adjust->vm_start;

But I guess you're looking for explicitness here?

> +		const unsigned long delta = vmg->end - middle->vm_start;
> +
> +		pgoff = vma_start_pgoff(middle) + (delta >> PAGE_SHIFT);
> +		adjust = middle;
>  	} else if (vmg->__adjust_next_start) {
> -		adjust = vmg->next;
> -		pgoff = adjust->vm_pgoff - PHYS_PFN(adjust->vm_start - vmg->end);
> +		/*
> +		 *                Originally:
> +		 *
> +		 *            vmg->start   vmg->end
> +		 *            |            |
> +		 *            v    merge   v
> +		 *            <------------>
> +		 *            .            .
> +		 * merge_existing_range() updates to:
> +		 *            .            .
> +		 * vmg->start vmg->end     .
> +		 * |          |            .
> +		 * v  retain  v            .
> +		 * <---------->            .
> +		 *             delta       .
> +		 *            <----->      .
> +		 * |----------------|------|
> +		 * |    middle      | next |
> +		 * |----------------|------|
> +		 *                  ^
> +		 *                  |
> +		 *                  next->vm_start
> +		 */
> +		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;
>  	}

Reviewed-by: Pedro Falcato <pfalcato@suse.de>

-- 
Pedro

^ permalink raw reply

* Re: [RFC 0/2] arm64: kprobes: Fix single-step fault and reentry handling
From: Pu Hu @ 2026-07-02 10:09 UTC (permalink / raw)
  To: Masami Hiramatsu (Google), catalin.marinas@arm.com,
	will@kernel.org, naveen@kernel.org, davem@davemloft.net,
	yang@os.amperecomputing.com, Hongyan Xia, Jiazi Li,
	ada.coupriediaz@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <a6504443-8708-4f6b-819f-2052615d37df@transsion.com>

On 7/2/2026 6:07 PM, hupu wrote:
> On 7/1/2026 9:56 PM, Pu Hu wrote:
>> On 7/1/2026 9:43 PM, Masami Hiramatsu wrote:
>>> On Wed, 1 Jul 2026 12:14:54 +0000
>>> Pu Hu <hupu@transsion.com> wrote:
>>>
>>>> From: hupu <hupu@transsion.com>
>>>>
...
...>
> I will send the complete test case in a follow-up email.
> 
> Thanks,
> hupu
> 

Hi maintainers,

As mentioned in my previous email, below is the complete test case I 
used to reproduce the arm64 kprobe crash on mainline.

It contains:

   - a small kprobe module that probes folio_wait_bit_common()
   - a userspace program that repeatedly triggers file-backed page faults
   - a Makefile to build both parts

Depending on the local build environment, the following variables in the
Makefile may need to be adjusted:

     CROSS_COMPILE
     KERN_DIR
     DEST_PATH

Thanks,
Pu Hu

---


diff --git a/misc/kprobe/Makefile b/misc/kprobe/Makefile
new file mode 100755
index 0000000..14c00c0
--- /dev/null
+++ b/misc/kprobe/Makefile
@@ -0,0 +1,36 @@
+PWD                            := $(shell pwd)
+ARCH                   ?= arm64
+CROSS_COMPILE  ?= aarch64-dumpstack-linux-gnu-
+KERN_DIR               ?= $(PWD)/../../output/build-mainline
+DEST_PATH              ?= $(PWD)/../../output
+Q                              := @
+
+UNIT_TEST              := fault_stress
+UNIT_TEST_SRC  := fault_stress.c
+
+KP_MOD                 := kp_folio
+obj-m                  := $(KP_MOD).o
+
+USER_CFLAGS            := -static -g -O0 -fno-omit-frame-pointer 
-fasynchronous-unwind-tables
+USER_LIBS              := -lm -lpthread
+EXTRA_CFLAGS   += -I$(KERN_DIR)
+
+.PHONY: all modules user clean
+
+all: modules user install
+
+modules:
+       $(Q)$(MAKE) -C $(KERN_DIR) M=$(PWD) 
EXTRA_CFLAGS="$(EXTRA_CFLAGS)" ARCH=$(ARCH) 
CROSS_COMPILE=$(CROSS_COMPILE) modules
+
+user:
+       $(Q)$(CROSS_COMPILE)gcc $(USER_CFLAGS) $(UNIT_TEST_SRC) -o 
$(UNIT_TEST) $(USER_LIBS)
+
+install:
+       $(Q)mkdir -p $(DEST_PATH)
+       $(Q)cp -f *.ko $(DEST_PATH)/
+       $(Q)cp -f $(UNIT_TEST) $(DEST_PATH)/
+
+clean:
+       $(Q)$(MAKE) -C $(KERN_DIR) M=$(PWD) clean
+       $(Q)rm -f $(UNIT_TEST)
+       $(Q)rm -f $(DEST_PATH)/$(UNIT_TEST) $(DEST_PATH)/*.ko
diff --git a/misc/kprobe/fault_stress.c b/misc/kprobe/fault_stress.c
new file mode 100755
index 0000000..10150ff
--- /dev/null
+++ b/misc/kprobe/fault_stress.c
@@ -0,0 +1,96 @@
+#define _GNU_SOURCE
+#include <fcntl.h>
+#include <pthread.h>
+#include <sched.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+#define FILE_SIZE   (256UL * 1024 * 1024)
+#define NR_THREADS  8
+
+static void deep_call(int n)
+{
+       volatile char buf[4096];
+
+       memset((void *)buf, n, sizeof(buf));
+
+       if (n > 0)
+               deep_call(n - 1);
+       else
+               sched_yield();
+}
+
+static void *worker(void *arg)
+{
+       const char *path = arg;
+       int fd;
+       char *map;
+       unsigned long i;
+       volatile unsigned long sum = 0;
+
+       fd = open(path, O_RDONLY);
+       if (fd < 0) {
+               perror("open");
+               return NULL;
+       }
+
+       map = mmap(NULL, FILE_SIZE, PROT_READ, MAP_PRIVATE, fd, 0);
+       if (map == MAP_FAILED) {
+               perror("mmap");
+               close(fd);
+               return NULL;
+       }
+
+       for (;;) {
+               /*
+                * Drop the pages backing this mapping from the current 
process.
+                * Subsequent accesses are more likely to trigger 
file-backed
+                * page faults again.
+                */
+               madvise(map, FILE_SIZE, MADV_DONTNEED);
+
+               for (i = 0; i < FILE_SIZE; i += 4096 * 17) {
+                       sum += map[i];
+                       deep_call(64);
+               }
+       }
+
+       munmap(map, FILE_SIZE);
+       close(fd);
+       return NULL;
+}
+
+int main(void)
+{
+       pthread_t th[NR_THREADS];
+       const char *path = "/tmp/fault_stress_file";
+       int fd;
+       int i;
+
+       fd = open(path, O_CREAT | O_RDWR, 0644);
+       if (fd < 0) {
+               perror("open file");
+               return 1;
+       }
+
+       if (ftruncate(fd, FILE_SIZE) < 0) {
+               perror("ftruncate");
+               return 1;
+       }
+
+       close(fd);
+
+       for (i = 0; i < NR_THREADS; i++)
+               pthread_create(&th[i], NULL, worker, (void *)path);
+
+       for (i = 0; i < NR_THREADS; i++)
+               pthread_join(th[i], NULL);
+
+       return 0;
+}
+
diff --git a/misc/kprobe/kp_folio.c b/misc/kprobe/kp_folio.c
new file mode 100755
index 0000000..c8f3e1d
--- /dev/null
+++ b/misc/kprobe/kp_folio.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/sched.h>
+#include <linux/atomic.h>
+#include <linux/ratelimit.h>
+
+static atomic64_t kp_hit_count = ATOMIC64_INIT(0);
+
+static int folio_wait_bit_common_handler(
+                       struct kprobe *p,^M
+                       struct pt_regs *regs)
+{
+       unsigned long hit;
+
+       hit = atomic64_inc_return(&kp_hit_count);
+
+       pr_info("kp_folio: hit=%lu comm=%s tgid=%d tid=%d\n",
+               hit, current->comm, current->tgid, current->pid);
+
+       return 0;
+}
+
+static struct kprobe kp_folio_wait_bit_common = {
+       .symbol_name = "folio_wait_bit_common",
+       .pre_handler = folio_wait_bit_common_handler,
+};
+
+static int __init kp_folio_init(void)
+{
+       int ret;
+
+       ret = register_kprobe(&kp_folio_wait_bit_common);
+       if (ret < 0) {
+               pr_err("kp_folio: register_kprobe failed, ret=%d\n", ret);
+               return ret;
+       }
+
+       pr_info("kp_folio: kprobe registered at %pS, addr=%px\n",
+               kp_folio_wait_bit_common.addr,
+               kp_folio_wait_bit_common.addr);
+
+       return 0;
+}
+
+static void __exit kp_folio_exit(void)
+{
+       unregister_kprobe(&kp_folio_wait_bit_common);
+
+       pr_info("kp_folio: kprobe unregistered, total hits=%lld\n",
+               atomic64_read(&kp_hit_count));
+}
+
+module_init(kp_folio_init);
+module_exit(kp_folio_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("hupu <hupu@transsion.com>");
+MODULE_DESCRIPTION("simple kprobe reproducer for folio_wait_bit_common");



^ permalink raw reply related

* Re: [RFC 0/2] arm64: kprobes: Fix single-step fault and reentry handling
From: Pu Hu @ 2026-07-02 10:07 UTC (permalink / raw)
  To: Masami Hiramatsu (Google), catalin.marinas@arm.com,
	will@kernel.org, naveen@kernel.org, davem@davemloft.net,
	yang@os.amperecomputing.com, Hongyan Xia, Jiazi Li,
	ada.coupriediaz@arm.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <ec11e9ca-ae7c-49c3-ae7b-47a70e9f86af@transsion.com>

On 7/1/2026 9:56 PM, Pu Hu wrote:
> On 7/1/2026 9:43 PM, Masami Hiramatsu wrote:
>> On Wed, 1 Jul 2026 12:14:54 +0000
>> Pu Hu <hupu@transsion.com> wrote:
>>
>>> From: hupu <hupu@transsion.com>
>>>
>>> This series fixes two arm64 kprobes issues observed when running
>>> simpleperf with preemptirq tracepoints and dwarf callchains while a
>>> kprobe is active on a frequently executed kernel function.
>>>
>>> The crash happens in the kprobe debug exception path. While a kprobe is
>>> preparing or executing its XOL single-step instruction, perf/trace code
>>> can run in the same window. That code may either take a fault of its own
>>> or hit another kprobe.
>>>
>>> Patch 1 makes kprobe_fault_handler() handle a fault in
>>> KPROBE_HIT_SS/KPROBE_REENTER only when the faulting PC points at the
>>> current kprobe's XOL instruction. Otherwise the fault is left to the
>>> normal fault handling path.
>>>
>>> Patch 2 allows a kprobe hit in KPROBE_HIT_SS to be handled as a
>>> recoverable one-level reentry. Only a hit while already in
>>> KPROBE_REENTER remains unrecoverable.
>>>
>>> This follows the same logic as the existing x86 fixes:
>>>    6381c24cd6d5 ("kprobes/x86: Fix page-fault handling logic")
>>>    6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on 
>>> single-stepping")
>>
>> Good catch!!
>> The series looks good to me.
>>
>> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>>
>> But it should be reviewed by arm64 maintainers too.
>>
>> BTW, if you are "Pu Hu", the Signed-off-by tag should be
>> "Pu Hu <...>" instead of "hupu <...>".
>>
> 
> Hi Masami,
> 
> Thank you for your reply and Acked-by.
> 
> Yes, thanks for pointing this out. I will fix the author name and the
> Signed-off-by tags to use a consistent name in the next version of the
> patchset.
> 
> Thanks,
> hupu
> 


Hi maintainers,

I have reproduced the same issue on the latest mainline kernel available
today. The commit I tested is 665159e24674.

Below are the steps I used to reproduce the issue. I hope this can help
with further debugging. The complete test case used in these steps will 
be provided in a follow-up email.

Reproduction steps:

1. Build the test case

Please use the test case that I will send in the next email. Depending 
on your local environment, the following variables in the Makefile may 
need to be adjusted:

     CROSS_COMPILE ?= aarch64-dumpstack-linux-gnu-
     KERN_DIR      ?= $(PWD)/../../output/build-mainline
     DEST_PATH     ?= $(PWD)/../../output

Then run:

     make all

This builds the userspace test program:

     fault_stress

and the kprobe module:

     kp_folio.ko

2. Boot QEMU

To increase memory pressure, I used only two CPUs and 512 MB of memory 
in the QEMU guest:

     SMP="-smp 2"

     qemu-system-aarch64 -m 512 -cpu cortex-a53 \
         -M virt,gic-version=3,its=on,iommu=smmuv3 \
         -nographic $SMP -kernel $KERNEL_IMAGE \
         -append "nokaslr noinitrd sched_debug root=/dev/vda 
rootfstype=ext4 rw crashkernel=256M loglevel=8" \
         -drive if=none,file=$ROOTFS_IMAGE,id=hd0,format=raw \
         -device virtio-blk-device,drive=hd0 \
         --fsdev local,id=kmod_dev,path=./output/,security_model=none \
         -device virtio-9p-pci,fsdev=kmod_dev,mount_tag=kmod_mount \
         -net nic -net tap,ifname=tap0,script=no,downscript=no \
         $GDB_DEBUG

3. Run the test in the guest

After the guest has booted, run the following commands.

Allow kernel symbols to be shown:

     echo 0 > /proc/sys/kernel/kptr_restrict

Load the kprobe module:

     insmod kp_folio.ko

Start the fault stress program:

     ./fault_stress &

Start stress-ng to add memory pressure:

     ./stress-ng --vm 2 --vm-bytes 70% --page-in &

Run perf against the fault_stress process. In the command below, 171 is 
the PID of fault_stress in my test environment:

     ./perf record -p 171 -c 1 \
         -e preemptirq:preempt_disable \
         -e preemptirq:preempt_enable \
         --call-graph dwarf \
         -o /tmp/perf.data \
         -- sleep 5

With the steps above, I can reproduce the crash reliably in my local 
QEMU setup. After applying my previously submitted fix, I can no longer 
reproduce the issue with the same test.

The crash log is shown below:

[  173.383321] kp_folio: hit=1564 comm=fault_stress tgid=171 tid=173
[  173.402940] kp_folio: hit=1565 comm=fault_stress tgid=171 tid=179
[  173.528342] kp_folio: hit=1566 comm=fault_stress tgid=171 tid=175
[  173.846895] kp_folio: hit=1567 comm=fault_stress tgid=171 tid=172
[  174.223031] kp_folio: hit=1568 comm=fault_stress tgid=171 tid=179
[  174.224419] kp_folio: hit=1569 comm=fault_stress tgid=171 tid=174
[  174.928471] kp_folio: hit=1570 comm=fault_stress tgid=171 tid=175
[  174.930916] Unable to handle kernel paging request at virtual address 
0000ffffa3592000
[  174.931068] Mem abort info:
[  174.931116]   ESR = 0x0000000096000007
[  174.931180]   EC = 0x25: DABT (current EL), IL = 32 bits
[  174.931240]   SET = 0, FnV = 0
[  174.931368]   EA = 0, S1PTW = 0
[  174.931430]   FSC = 0x07: level 3 translation fault
[  174.931490] Data abort info:
[  174.931540]   ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
[  174.931593]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  174.931669]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  174.931762] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049bf8000
[  174.931829] [0000ffffa3592000] pgd=0800000049a99403, 
p4d=0800000049a99403, pud=0800000049ac0403, pmd=0800000049bed403, 
pte=00000000000047c0
[  174.932328] Internal error: Oops: 0000000096000007 [#1]  SMP
[  174.939042] Modules linked in: kp_folio(O)
[  174.942114] CPU: 1 UID: 0 PID: 175 Comm: fault_stress Tainted: G 
      O        7.2.0-rc1-00010-g7679152d724a-dirty #2 PREEMPT
[  174.945427] Tainted: [O]=OOT_MODULE
[  174.946006] Hardware name: linux,dummy-virt (DT)
[  174.947011] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)
[  174.948582] pc : folio_wait_bit_common+0x0/0x320
[  174.949626] lr : perf_output_sample+0x708/0x968
[  174.950041] sp : ffff800084b13540
[  174.950511] x29: ffff800084b13570 x28: ffff000006704260 x27: 
0000ffffa3591d08
[  174.953274] x26: ffff000009a19a80 x25: 0000000000000000 x24: 
ffff800084b13780
[  174.953601] x23: 0000000000000ee8 x22: 000000000000b5ef x21: 
0000000000001000
[  174.954003] x20: 0000000000000ee8 x19: ffff800084b135e0 x18: 
000000000000000a
[  174.954262] x17: ffff8000803d1af4 x16: ffff80008036d01c x15: 
0000ffffa3591d08
[  174.954549] x14: 0000000000000000 x13: 0000000000000000 x12: 
0000000000000000
[  174.954863] x11: 0000000000000000 x10: 0000000000000000 x9 : 
0000000000000000
[  174.955315] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 
ffff0000069ce2c8
[  174.955592] x5 : ffff0000069ceee8 x4 : 0000000000000008 x3 : 
0000000000000000
[  174.956083] x2 : 0000000000000be0 x1 : 0000ffffa3592000 x0 : 
ffff0000069ce000
[  174.956838] Call trace:
[  174.958282]  folio_wait_bit_common+0x0/0x320 (P)
[  174.958618]  perf_event_output_forward+0xc0/0x1a8
[  174.958811]  __perf_event_overflow+0x108/0x518
[  174.959066]  perf_swevent_event+0x238/0x260
[  174.959295]  perf_tp_event+0x34c/0x6a0
[  174.959667]  perf_trace_run_bpf_submit+0x8c/0xd0
[  174.962331]  perf_trace_preemptirq_template+0xc4/0x130
[  174.962644]  trace_preempt_on+0x114/0x1e8
[  174.963019]  preempt_count_sub+0x78/0xe0
[  174.963402]  el1_brk64+0x40/0x60
[  174.963617]  el1h_64_sync_handler+0x68/0xb0
[  174.963817]  el1h_64_sync+0x6c/0x70
[  174.964239]  0xffff8000846c5000 (P)
[  174.964938]  __do_fault+0x44/0x288
[  174.965452]  __handle_mm_fault+0xaf8/0x1a40
[  174.965815]  handle_mm_fault+0xb4/0x420
[  174.966527]  do_page_fault+0x140/0x7b0
[  174.967398]  do_translation_fault+0x4c/0x70
[  174.968057]  do_mem_abort+0x48/0xa0
[  174.969705]  el0_da+0x64/0x290
[  174.969984]  el0t_64_sync_handler+0xd0/0xe8
[  174.970324]  el0t_64_sync+0x198/0x1a0
[  174.970713] Code: d50323bf d65f03c0 12800140 17fffffc (d4200080)
[  174.971338] kp_folio: hit=1571 comm=fault_stress tgid=171 tid=174
[  174.972266] ---[ end trace 0000000000000000 ]---

I will send the complete test case in a follow-up email.

Thanks,
hupu


^ permalink raw reply

* Re: [PATCH] tracing: Cleanup event_enable_trigger_parse() by using __free()
From: Markus Elfring @ 2026-07-02  9:58 UTC (permalink / raw)
  To: linux-trace-kernel, Masami Hiramatsu, Mathieu Desnoyers,
	Steven Rostedt
  Cc: LKML
In-Reply-To: <20260701174829.67ab8a33@gandalf.local.home>

…
> +++ b/kernel/trace/trace_events_trigger.c
> @@ -1739,7 +1739,7 @@ int event_enable_trigger_parse(struct event_command *cmd_ops,
>  			       char *glob, char *cmd, char *param_and_filter)
>  {
>  	struct trace_event_file *event_enable_file;
> -	struct enable_trigger_data *enable_data;
> +	struct enable_trigger_data *enable_data __free(kfree) = NULL;
…

How do you think about to reduce the scope for this local variable?

Regards,
Markus

^ permalink raw reply

* Re: [PATCH v3 04/11] arm64/mm: Add set_memory_device() and set_memory_normal()
From: Will Deacon @ 2026-07-02  9:18 UTC (permalink / raw)
  To: Thierry Reding
  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: <20260701-tegra-vpr-v3-4-d80f7b871bb4@nvidia.com>

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()?

I think you should unmap the memory from the linear map and memremap()
it instead.

Will

^ permalink raw reply

* Re: [PATCH] tracing: Add a no-rcu-check version of trace_##event##_enabled()
From: Geert Uytterhoeven @ 2026-07-02  8:50 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, Linux trace kernel, Masami Hiramatsu, Mathieu Desnoyers,
	David Carlier
In-Reply-To: <20260701132744.6a7fc68b@robin>

On Wed, 1 Jul 2026 at 19:27, Steven Rostedt <rostedt@goodmis.org> wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> Tracepoints require that RCU is watching. To prevent them from being used
> in places that RCU is not watching, the trace_##event() macro always
> calls rcu_is_watching() even when the event is not enabled and warns if
> RCU is not watching. This is to make sure a warning is triggered even if
> the tracepoint is never enabled (as it is only a bug when it is).
>
> It was noticed that tracepoints could be hidden within
> trace_#event#_enabled() calls, which are used to do extra work for the
> tracepoint only if the tracepoint is enabled. But this also can hide the
> fact that a tracepoint is placed in a location that can be called when RCU
> is not watching.
>
> Commit 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to
> trace_##name##_enabled()") added a check to the trace_##event##_enabled()
> macro to make sure RCU is watching when it is called to make sure not to
> hide the bug of a tracepoint being called when RCU is not watching.
>
> There is one case in the irq_disable tracepoint where it is within a
> trace_irq_disable_enabled() block, but it checks if RCU is watching, and
> if it isn't, it makes a call to ct_irq_enter() that makes RCU watch again.
> But because trace_irq_disable_enabled() now checks if RCU is watching and
> will trigger if it isn't. This is a false warning as the code within
> the block handles this case.
>
> Add a new internal macro __trace_##event##_enabled() that doesn't check if
> RCU is watching, and convert the irq_enable/disable tracepoints over to
> it.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Closes: https://lore.kernel.org/all/CAMuHMdXud_RpWag_hFqa2ByBGRxg6KnxGL1ObCWZrpTsk3TfAw@mail.gmail.com/
> Fixes: 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()")
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Thanks, warning gone on all affected platforms.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH v3] ufs: core: add hba parameter to trace events
From: Peter Wang (王信友) @ 2026-07-02  8:46 UTC (permalink / raw)
  To: rostedt@goodmis.org
  Cc: CC Chou (周志杰), jejb@linux.ibm.com,
	bvanassche@acm.org, linux-scsi@vger.kernel.org,
	Eddie Huang (黃智傑),
	Chaotian Jing (井朝天),
	linux-mediatek@lists.infradead.org,
	Qilin Tan (谭麒麟),
	Yi-fan Peng (彭羿凡),
	Lin Gui (桂林), alim.akhtar@samsung.com,
	linux-trace-kernel@vger.kernel.org,
	Jiajie Hao (郝加节),
	Ed Tsai (蔡宗軒),
	Alice Chao (趙珮均),
	Naomi Chu (朱詠田), wsd_upstream,
	avri.altman@wdc.com, martin.petersen@oracle.com,
	Chun-Hung Wu (巫駿宏),
	Tun-yu Yu (游敦聿)
In-Reply-To: <20260701085740.218cf4d9@gandalf.local.home>

On Wed, 2026-07-01 at 08:57 -0400, Steven Rostedt wrote:
> On Wed, 1 Jul 2026 06:11:37 +0000
> Peter Wang (王信友) <peter.wang@mediatek.com> wrote:
> 
> > However, I am curious: if the HBA is removed, implying that the
> > storage would become unusable, might the system encounter an
> > I/O hang or shutdown, potentially preventing its detection?
> > Perhaps it's a theoretical issue that would not manifest
> > in a real-world situation?
> 
> Note, it doesn't necessarily mean that the device itself was removed.
> The
> issue is that a pointer to an allocated descriptor is saved in the
> ring buffer.
> 
> Maybe once the device is created it will never go way. But what
> happens if
> for some reason the descriptor is freed and reallocated? Now the old
> descriptor pointer is still in the ring buffer.
> 
> What in the logic guarantees that the pointer will never be freed?
> 
> And lets say there is an issue and the hba is freed and you debug
> this by
> dumping the trace buffer via ftrace_dump_on_oops. Now the dump itself
> may
> crash and you don't have a way to debug what happened.
> 
> One other point that causes issues here. It makes user space tracing
> useless. Try tracing this with "trace-cmd record". These events will
> not be
> able to be parsed.
> 
> -- Steve
> 

Hi Steven,

Thank you for the detailed explanation. I have no further questions.

Thanks
Peter




^ permalink raw reply

* Re: [PATCH] tracing: Warn when an event dereferences a pointer in TP_printk()
From: Martin Kaiser @ 2026-07-02  7:48 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
	Frank Li, Vinod Koul
In-Reply-To: <20260630184836.74d477b6@gandalf.local.home>

Thus wrote Steven Rostedt (rostedt@goodmis.org):

> From: Steven Rostedt <rostedt@goodmis.org>

> Currently on boot up and when modules are loaded, the trace event
> infrastructure will examine the TP_printk's of every event looking to see
> if it dereferences pointers on the ring buffer via printk formats like
> "%pB" and such. What it doesn't do is check if the arguments themselves
> do a dereference from a pointer.

> This was brought with a fix[1] to the fsl_edma event that had in the
> arguments of the TP_printk(): "__entry->edma->membase"

> The __entry->edma is a pointer saved in the ring buffer. The dereference
> from TP_printk() happens when the user reads the "trace" file which can be
> seconds, minutes, hours, days, weeks, or even months later! There is no
> guarantee that the __entry->edma pointer will still be pointing to what it
> was when it was recorded, and could crash the kernel when a user reads the
> event.

> Add logic to the test_event_printk() that also checks for this case and
> warn if the event dereferences a pointer from the ring buffer.

> [1] https://lore.kernel.org/all/20260630200022.1826420-1-martin@kaiser.cx/

> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
>  kernel/trace/trace_events.c | 35 +++++++++++++++++++++++++++++------
>  1 file changed, 29 insertions(+), 6 deletions(-)

> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index c46e623e7e0d..3b52bfd8b300 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -400,6 +400,31 @@ static bool process_string(const char *fmt, int len, struct trace_event_call *ca
>  	return true;
>  }

> +static void test_double_dereference(const char *str, int len,
> +				    struct trace_event_call *call)
> +{
> +	const char *ptr;
> +	const char *end = str + len;
> +
> +	ptr = strstr(str, "REC->");
> +
> +	while (ptr && ptr < end) {
> +
> +		ptr += 5;
> +		for (; ptr < end; ptr++) {
> +			if (ptr[0] == '-' && ptr[1] == '>') {
> +				WARN_ONCE(1, "Event %s has double dereference in TP_printk: %.*s\n",
> +					  trace_event_name(call), len, str);
> +				return;
> +			}
> +			if (!isalnum(*ptr) && *ptr != '_')
> +				break;
> +		}
> +
> +		ptr = strstr(ptr, "REC->");
> +	}
> +}
> +
>  static void handle_dereference_arg(const char *arg_str, u64 string_flags, int len,
>  				   u64 *dereference_flags, int arg,
>  				   struct trace_event_call *call)
> @@ -459,12 +484,6 @@ static void test_event_printk(struct trace_event_call *call)
>  				if (in_quote) {
>  					arg = 0;
>  					first = false;
> -					/*
> -					 * If there was no %p* uses
> -					 * the fmt is OK.
> -					 */
> -					if (!dereference_flags)
> -						return;
>  				}
>  			}
>  			if (in_quote) {
> @@ -576,6 +595,8 @@ static void test_event_printk(struct trace_event_call *call)
>  				continue;
>  			}

> +			test_double_dereference(fmt + start_arg, e - start_arg, call);
> +
>  			if (dereference_flags & (1ULL << arg)) {
>  				handle_dereference_arg(fmt + start_arg, string_flags,
>  						       e - start_arg,
> @@ -589,6 +610,8 @@ static void test_event_printk(struct trace_event_call *call)
>  		}
>  	}

> +	test_double_dereference(fmt + start_arg, i - start_arg, call);
> +
>  	if (dereference_flags & (1ULL << arg)) {
>  		handle_dereference_arg(fmt + start_arg, string_flags,
>  				       i - start_arg,
> -- 
> 2.53.0

Looks good to me.

Reviewed-by: Martin Kaiser <martin@kaiser.cx>

^ permalink raw reply

* Re: [PATCHv4 00/13] uprobes/x86: Fix red zone issue for optimized uprobes
From: Peter Zijlstra @ 2026-07-02  7:30 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: Jiri Olsa, Ingo Molnar, Masami Hiramatsu, Oleg Nesterov,
	Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <20260702072004.GA49951@noisy.programming.kicks-ass.net>

On Thu, Jul 02, 2026 at 09:20:04AM +0200, Peter Zijlstra wrote:

> > I'll assume that no one has any objections to route this through
> > bpf-next. We got reviews from Oleg, so that's great. Jiri, seems like
> > you will do small adjustments and send v5, please do, and then unless
> > meanwhile no one raises any issues, this will go through bpf-next.
> > Thanks!
> 
> Is it already applied? If not, I can stick it in tip/perf/core (and the
> first in /urgent).

Oh, I see v5. I'll go grab that then.

^ permalink raw reply

* Re: [PATCH v2 4/4] rv/rtapp: Add wakeup monitor
From: Nam Cao @ 2026-07-02  7:25 UTC (permalink / raw)
  To: Gabriele Monaco
  Cc: Steven Rostedt, linux-trace-kernel, linux-doc, linux-kernel
In-Reply-To: <b33e175467a8cb8011ded2195353bc6743b4cd46.camel@redhat.com>

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.

Nam

^ permalink raw reply

* Re: [PATCHv4 00/13] uprobes/x86: Fix red zone issue for optimized uprobes
From: Peter Zijlstra @ 2026-07-02  7:20 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: Jiri Olsa, Ingo Molnar, Masami Hiramatsu, Oleg Nesterov,
	Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <CAEf4BzYmgj55UnBX2fRoKwtc-97vc7Sf1opWcAXzSKKLr_Ei6A@mail.gmail.com>

On Thu, Jun 25, 2026 at 10:44:18PM -0700, Andrii Nakryiko wrote:
> On Mon, Jun 8, 2026 at 1:48 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Jun 3, 2026 at 11:59 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> > >
> > > On Tue, May 26, 2026 at 10:58:27PM +0200, Jiri Olsa 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 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
> > >
> > > hi,
> > > I think bots did not find anything substantial, I have just small
> > > selftests changes queued for v5
> > >
> > > any other feedback/review would be great
> > >
> >
> > one small nit on only, otherwise LGTM.
> >
> > Peter, Masami, Ingo, should this go through tip tree or should we
> > route this through bpf-next tree? I think we are fine either way, but
> > might be more convenient to route through bpf-next given libbpf and
> > BPF selftest changes.
> >
> 
> I'll assume that no one has any objections to route this through
> bpf-next. We got reviews from Oleg, so that's great. Jiri, seems like
> you will do small adjustments and send v5, please do, and then unless
> meanwhile no one raises any issues, this will go through bpf-next.
> Thanks!

Is it already applied? If not, I can stick it in tip/perf/core (and the
first in /urgent).

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox