* Re: [PATCHv5 00/13] uprobes/x86: Fix red zone issue for optimized uprobes
From: Andrii Nakryiko @ 2026-07-01 23:13 UTC (permalink / raw)
To: Jiri Olsa
Cc: Oleg Nesterov, Peter Zijlstra, Ingo Molnar, Masami Hiramatsu,
Andrii Nakryiko, bpf, linux-trace-kernel
In-Reply-To: <20260701111337.53943-1-jolsa@kernel.org>
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?
> Andrii Nakryiko (1):
> selftests/bpf: Add tests for uprobe nop10 red zone clobbering
>
> Jiri Olsa (12):
> uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline
> uprobes/x86: Remove struct uprobe_trampoline object
> uprobes/x86: Do not leak trampoline vma mapping on optimization failure
> uprobes/x86: Allow to copy uprobe trampolines on fork
> uprobes/x86: Move optimized uprobe from nop5 to nop10
> libbpf: Change has_nop_combo to work on top of nop10
> libbpf: Detect uprobe syscall with new error
> selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch
> selftests/bpf: Change uprobe syscall tests to use nop10
> selftests/bpf: Change uprobe/usdt trigger bench code to use nop10
> selftests/bpf: Add reattach tests for uprobe syscall
> selftests/bpf: Add tests for forked/cloned optimized uprobes
>
> arch/x86/kernel/uprobes.c | 416 +++++++++++++++++++++++++++++++++++++++++++-----------------------------
> include/linux/uprobes.h | 5 -
> kernel/events/uprobes.c | 10 --
> kernel/fork.c | 1 -
> tools/lib/bpf/features.c | 4 +-
> tools/lib/bpf/usdt.c | 16 +--
> tools/testing/selftests/bpf/bench.c | 20 ++--
> tools/testing/selftests/bpf/benchs/bench_trigger.c | 38 +++----
> tools/testing/selftests/bpf/benchs/run_bench_uprobes.sh | 2 +-
> tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c | 326 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
> tools/testing/selftests/bpf/prog_tests/usdt.c | 74 +++++++++++--
> tools/testing/selftests/bpf/progs/test_usdt.c | 25 +++++
> tools/testing/selftests/bpf/usdt.h | 2 +-
> tools/testing/selftests/bpf/usdt_2.c | 15 ++-
> 14 files changed, 698 insertions(+), 256 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Alexei Starovoitov @ 2026-07-02 0:01 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, Shuah Khan, Mathieu Desnoyers, LKML,
linux-trace-kernel, open list:KERNEL SELFTEST FRAMEWORK, bpf
In-Reply-To: <20260702074007.e1047c9d66cbcecc7d4ab3a9@kernel.org>
On Wed, Jul 1, 2026 at 3:40 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Wed, 01 Jul 2026 11:41:26 -0700
> "Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
>
> >
> > Nack.
> > I really don't like it.
> > There were days in the past when the kernel generating bpf directly was appealing.
> > These days are gone. Performance improvements for fetchargs is not a good reason
> > to add all this complexity and bypass verifier checks.
> > bpf insns should come from user space.
>
> Thanks for your comment!
> OK, I don't mind because this is a kind of investigation project. And some
> people had asked me about the same idea, now I can tell them the result.
>
> I'm satisfied with the current outcome, as this development process gave me
> insight into the implementation of BPF and demonstrated the potential for
> optimization via JIT. :)
>
> And also, as noted in the cover letter, the current performance of fetcharg
> is better than I thought, and is good enough for debugging. :)
>
> BTW, I'm also interested in calling the verifier on this generated code.
> Even it it is not merged, I think showing the correct way to implement it
> will be useful in the future.
The whole feature you're trying to do is imo reinvention of the wheel.
bpf could do that kind of filtering years ago.
I don't buy the excuse that embedded environments without any
kind of user space needs this facility.
^ permalink raw reply
* Re: [RFC PATCH 2/4] tracing/probes: Compile all fetchargs into a single BPF program per event
From: Masami Hiramatsu @ 2026-07-02 1:01 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, Shuah Khan, Mathieu Desnoyers, LKML,
linux-trace-kernel, open list:KERNEL SELFTEST FRAMEWORK, bpf
In-Reply-To: <CAADnVQLUniyTM64gHrLzgjWiNZTB82tT0LCxh8D29YfXG7cZ6w@mail.gmail.com>
On Wed, 1 Jul 2026 17:01:01 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Wed, Jul 1, 2026 at 3:40 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > On Wed, 01 Jul 2026 11:41:26 -0700
> > "Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
> >
> > >
> > > Nack.
> > > I really don't like it.
> > > There were days in the past when the kernel generating bpf directly was appealing.
> > > These days are gone. Performance improvements for fetchargs is not a good reason
> > > to add all this complexity and bypass verifier checks.
> > > bpf insns should come from user space.
> >
> > Thanks for your comment!
> > OK, I don't mind because this is a kind of investigation project. And some
> > people had asked me about the same idea, now I can tell them the result.
> >
> > I'm satisfied with the current outcome, as this development process gave me
> > insight into the implementation of BPF and demonstrated the potential for
> > optimization via JIT. :)
> >
> > And also, as noted in the cover letter, the current performance of fetcharg
> > is better than I thought, and is good enough for debugging. :)
> >
> > BTW, I'm also interested in calling the verifier on this generated code.
> > Even it it is not merged, I think showing the correct way to implement it
> > will be useful in the future.
>
> The whole feature you're trying to do is imo reinvention of the wheel.
> bpf could do that kind of filtering years ago.
> I don't buy the excuse that embedded environments without any
> kind of user space needs this facility.
>
Yeah, I understood it. I have no intention to merge this series.
This is totally just for fun and my interest about BPF.
But thanks for your comments. It is good to hear your thought in the RFC
stage. I can stop this series here with peace of mind. :)
Thank you!
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/1] tracing: Prevent out-of-bounds read in glob matching
From: Masami Hiramatsu @ 2026-07-02 1:15 UTC (permalink / raw)
To: Ren Wei
Cc: linux-kernel, linux-trace-kernel, rostedt, mhiramat,
mathieu.desnoyers, akpm, namhyung, yuantan098, yifanwucs,
tomapufckgml, zcliangcn, bird, hhhuang
In-Reply-To: <da1aaf125fc3b63320b0c540fd6afa7c3d5b4f1a.1782836943.git.hhhuang@smu.edu.sg>
On Wed, 1 Jul 2026 18:28:46 +0800
Ren Wei <n05ec@lzu.edu.cn> wrote:
> From: Huihui Huang <hhhuang@smu.edu.sg>
>
> String event fields are not necessarily NUL-terminated, so the filter
> predicate functions (filter_pred_string(), filter_pred_strloc() and
> filter_pred_strrelloc()) pass the field length to the regex match
> callbacks, and the length-aware matchers honour it.
>
> regex_match_glob() was the exception: it ignored the length and called
> glob_match(), which scans the string until it hits a NUL byte. Some
> string fields are not NUL-terminated. One example is the dynamic char
> array of the xfs_* namespace tracepoints, which is copied without a
> trailing NUL. For such a field, glob matching reads past the end of
> the event field, causing a KASAN slab-out-of-bounds read in
> glob_match(), reached via regex_match_glob() and filter_match_preds()
> from the xfs_lookup tracepoint.
>
> Add a length-bounded glob_match_len() and use it from regex_match_glob()
> so glob matching always stops at the field boundary. The matching loop
> is factored into a shared helper so glob_match() keeps its behaviour.
>
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thank you,
> Fixes: 60f1d5e3bac4 ("ftrace: Support full glob matching")
> Cc: stable@vger.kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> include/linux/glob.h | 1 +
> kernel/trace/trace_events_filter.c | 6 ++----
> lib/glob.c | 31 ++++++++++++++++++++++++++++--
> 3 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/glob.h b/include/linux/glob.h
> index 861327b33e..91595e7509 100644
> --- a/include/linux/glob.h
> +++ b/include/linux/glob.h
> @@ -6,5 +6,6 @@
> #include <linux/compiler.h> /* For __pure */
>
> bool __pure glob_match(char const *pat, char const *str);
> +bool __pure glob_match_len(char const *pat, char const *str, size_t len);
>
> #endif /* _LINUX_GLOB_H */
> diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
> index 609325f579..6385cd662d 100644
> --- a/kernel/trace/trace_events_filter.c
> +++ b/kernel/trace/trace_events_filter.c
> @@ -1056,11 +1056,9 @@ static int regex_match_end(char *str, struct regex *r, int len)
> return 0;
> }
>
> -static int regex_match_glob(char *str, struct regex *r, int len __maybe_unused)
> +static int regex_match_glob(char *str, struct regex *r, int len)
> {
> - if (glob_match(r->pattern, str))
> - return 1;
> - return 0;
> + return glob_match_len(r->pattern, str, len) ? 1 : 0;
> }
>
> /**
> diff --git a/lib/glob.c b/lib/glob.c
> index 7aca76c25b..c80d9dd736 100644
> --- a/lib/glob.c
> +++ b/lib/glob.c
> @@ -11,6 +11,9 @@
> MODULE_DESCRIPTION("glob(7) matching");
> MODULE_LICENSE("Dual MIT/GPL");
>
> +static bool __pure glob_match_str(char const *pat, char const *str,
> + char const *str_end);
> +
> /**
> * glob_match - Shell-style pattern matching, like !fnmatch(pat, str, 0)
> * @pat: Shell-style pattern to match, e.g. "*.[ch]".
> @@ -40,6 +43,29 @@ MODULE_LICENSE("Dual MIT/GPL");
> * An opening bracket without a matching close is matched literally.
> */
> bool __pure glob_match(char const *pat, char const *str)
> +{
> + return glob_match_str(pat, str, NULL);
> +}
> +EXPORT_SYMBOL(glob_match);
> +
> +/**
> + * glob_match_len - glob match against a length-bounded string
> + * @pat: Shell-style pattern to match.
> + * @str: String to match. Need not be NUL-terminated.
> + * @len: Number of bytes of @str that may be read.
> + *
> + * Like glob_match(), but @str is only read up to @len bytes, so it can be
> + * used on buffers that are not NUL-terminated (e.g. trace event fields).
> + * A NUL byte within @len still terminates the string.
> + */
> +bool __pure glob_match_len(char const *pat, char const *str, size_t len)
> +{
> + return glob_match_str(pat, str, str + len);
> +}
> +EXPORT_SYMBOL(glob_match_len);
> +
> +static bool __pure glob_match_str(char const *pat, char const *str,
> + char const *str_end)
> {
> /*
> * Backtrack to previous * on mismatch and retry starting one
> @@ -55,9 +81,11 @@ bool __pure glob_match(char const *pat, char const *str)
> * on mismatch, or true after matching the trailing nul bytes.
> */
> for (;;) {
> - unsigned char c = *str++;
> + unsigned char c = (str_end && str >= str_end) ? '\0' : *str;
> unsigned char d = *pat++;
>
> + str++;
> +
> switch (d) {
> case '?': /* Wildcard: anything but nul */
> if (c == '\0')
> @@ -125,4 +153,3 @@ bool __pure glob_match(char const *pat, char const *str)
> }
> }
> }
> -EXPORT_SYMBOL(glob_match);
> --
> 2.50.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH v2] selftests/ftrace: fix spelling error in poll test comment
From: Wang Yan @ 2026-07-02 1:56 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, shuah
Cc: linux-trace-kernel, linux-kselftest, linux-kernel, Wang Yan
Fix typo "happned" -> "happened" in ftrace poll test comment.
Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
---
tools/testing/selftests/ftrace/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/poll.c b/tools/testing/selftests/ftrace/poll.c
index 53258f7515e7..4da86a20dc85 100644
--- a/tools/testing/selftests/ftrace/poll.c
+++ b/tools/testing/selftests/ftrace/poll.c
@@ -66,7 +66,7 @@ int main(int argc, char *argv[])
}
close(pfd.fd);
- /* If timeout happned (ret == 0), exit code is 1 */
+ /* If timeout happened (ret == 0), exit code is 1 */
if (ret == 0)
return 1;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] selftests/ftrace: fix spelling error in poll test comment
From: Masami Hiramatsu @ 2026-07-02 5:27 UTC (permalink / raw)
To: shuah, Wang Yan
Cc: rostedt, mathieu.desnoyers, linux-trace-kernel, linux-kselftest,
linux-kernel
In-Reply-To: <20260702015634.366201-1-wangyan01@kylinos.cn>
Hi,
This looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Shuah, can you pick this through your tree?
Thank you,
On Thu, 2 Jul 2026 09:56:34 +0800
Wang Yan <wangyan01@kylinos.cn> wrote:
> Fix typo "happned" -> "happened" in ftrace poll test comment.
>
> Signed-off-by: Wang Yan <wangyan01@kylinos.cn>
> ---
> tools/testing/selftests/ftrace/poll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/ftrace/poll.c b/tools/testing/selftests/ftrace/poll.c
> index 53258f7515e7..4da86a20dc85 100644
> --- a/tools/testing/selftests/ftrace/poll.c
> +++ b/tools/testing/selftests/ftrace/poll.c
> @@ -66,7 +66,7 @@ int main(int argc, char *argv[])
> }
> close(pfd.fd);
>
> - /* If timeout happned (ret == 0), exit code is 1 */
> + /* If timeout happened (ret == 0), exit code is 1 */
> if (ret == 0)
> return 1;
>
> --
> 2.25.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 12/13] rv: Fix read_lock scope in per-task DA cleanup
From: Gabriele Monaco @ 2026-07-02 6:31 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-kernel, linux-trace-kernel, Wen Yang, Nam Cao
In-Reply-To: <20260701152705.6dc9d8f2@gandalf.local.home>
On Wed, 2026-07-01 at 15:27 -0400, Steven Rostedt wrote:
> On Mon, 1 Jun 2026 17:38:39 +0200
> Gabriele Monaco <gmonaco@redhat.com> wrote:
>
> > The da_monitor_reset_all() function for per-task monitors takes
> > tasklist_lock while iterating over tasks, then keeps it also while
> > iterating over idle tasks (one per CPU). The latter is not necessary
> > since the lock needs to guard only for_each_process_thread().
> >
> > Use a scoped_guard for more compact syntax and adjust the scope only
> > where the lock is necessary.
> >
> > Reviewed-by: Wen Yang <wen.yang@linux.dev>
> > Reviewed-by: Nam Cao <namcao@linutronix.de>
> > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
>
> Hmm, this and patch 13 didn't get applied. Do you plan on sending them later?
Yes, I didn't add them to the pull request since they weren't quite fixes, then
ended up not sending a "normal" pull request for 7.2 just for these.
I'm going to put them together for the next round.
Thanks,
Gabriele
^ 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
* 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: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] 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: [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: 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 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: 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: [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: [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: [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: [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 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 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 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 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 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 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox