* Re: [PATCH v3 01/13] rv: Unify DA event handling functions across monitor types
From: Gabriele Monaco @ 2025-12-22 14:45 UTC (permalink / raw)
To: Nam Cao, linux-kernel, Steven Rostedt, linux-trace-kernel
Cc: Tomas Glozar, Juri Lelli, Clark Williams, John Kacur
In-Reply-To: <871pksk3cg.fsf@yellow.woof>
On Thu, 2025-12-18 at 08:04 +0700, Nam Cao wrote:
> I think this overexplains. I would just explain the "WHY", then the
> general idea how the patch solves the problem. Let the diff speaks for
> the rest.
>
> Perhaps something like:
>
> The DA event handling functions are mostly duplicated for
> differerent monitor types, because per-task monitors' functions
> require a task_struct parameter while the others do not.
>
> Unify the functions, handle the difference by always passing a
> da_id_type which is the task's pid for per-task monitor but is
> ignored for the other types.
>
Good point, I'll squeeze it.
Thanks,
Gabriele
> Regardless:
>
> Reviewed-by: Nam Cao <namcao@linutronix.de>
>
> Nam
^ permalink raw reply
* [syzbot] Monthly trace report (Dec 2025)
From: syzbot @ 2025-12-22 13:07 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, mhiramat, syzkaller-bugs
Hello trace maintainers/developers,
This is a 31-day syzbot report for the trace subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/trace
During the period, 0 new issues were detected and 1 were fixed.
In total, 12 issues are still open and 62 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 101 Yes WARNING in blk_register_tracepoints
https://syzkaller.appspot.com/bug?extid=c54ded83396afee31eb1
<2> 92 Yes WARNING in tracepoint_probe_unregister (3)
https://syzkaller.appspot.com/bug?extid=a1d25e53cd4a10f7f2d3
<3> 65 Yes INFO: task hung in blk_trace_ioctl (4)
https://syzkaller.appspot.com/bug?extid=ed812ed461471ab17a0c
<4> 61 Yes INFO: task hung in blk_trace_remove (2)
https://syzkaller.appspot.com/bug?extid=2373f6be3e6de4f92562
<5> 22 Yes WARNING in get_probe_ref
https://syzkaller.appspot.com/bug?extid=8672dcb9d10011c0a160
<6> 11 Yes INFO: task hung in blk_trace_setup (4)
https://syzkaller.appspot.com/bug?extid=9c1ebb9957045e00ac63
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH] tracing: Do not register unsupported perf events
From: Jiri Olsa @ 2025-12-22 9:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Ian Rogers, Arnaldo Carvalho de Melo, Namhyung Kim
In-Reply-To: <20251216182440.147e4453@gandalf.local.home>
On Tue, Dec 16, 2025 at 06:24:40PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> Synthetic events currently do not have a function to register perf events.
> This leads to calling the tracepoint register functions with a NULL
> function pointer which triggers:
>
> ------------[ cut here ]------------
> WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272
> Modules linked in: kvm_intel kvm irqbypass
> CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> RIP: 0010:tracepoint_add_func+0x357/0x370
> Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f
> RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246
> RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000
> RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8
> RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780
> R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a
> R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78
> FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0
> Call Trace:
> <TASK>
> tracepoint_probe_register+0x5d/0x90
> synth_event_reg+0x3c/0x60
> perf_trace_event_init+0x204/0x340
> perf_trace_init+0x85/0xd0
> perf_tp_event_init+0x2e/0x50
> perf_try_init_event+0x6f/0x230
> ? perf_event_alloc+0x4bb/0xdc0
> perf_event_alloc+0x65a/0xdc0
> __se_sys_perf_event_open+0x290/0x9f0
> do_syscall_64+0x93/0x7b0
> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
> ? trace_hardirqs_off+0x53/0xc0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Instead, have the code return -ENODEV, which doesn't warn and has perf
> error out with:
>
> # perf record -e synthetic:futex_wait
> Error:
> The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).
> "dmesg | grep -i perf" may provide additional information.
>
> Ideally perf should support synthetic events, but for now just fix the
> warning. The support can come later.
>
> Cc: stable@vger.kernel.org
> Fixes: 4b147936fa509 ("tracing: Add support for 'synthetic' events")
> Reported-by: Ian Rogers <irogers@google.com>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
lgtm
Acked-by: Jiri Olsa <jolsa@kernel.org>
jirka
> ---
> kernel/trace/trace_events.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index a5a93d243047..754b14ca87a7 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -710,6 +710,8 @@ int trace_event_reg(struct trace_event_call *call,
>
> #ifdef CONFIG_PERF_EVENTS
> case TRACE_REG_PERF_REGISTER:
> + if (!call->class->perf_probe)
> + return -ENODEV;
> return tracepoint_probe_register(call->tp,
> call->class->perf_probe,
> call);
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH 2/2] bpf: Implement kretprobe fallback for kprobe multi link
From: liujing40 @ 2025-12-22 8:02 UTC (permalink / raw)
To: menglong.dong
Cc: andrii, ast, bpf, daniel, eddyz87, haoluo, john.fastabend, jolsa,
kpsingh, linux-kernel, linux-trace-kernel, liujing.root,
liujing40, martin.lau, mhiramat, sdf, song, yonghong.song
In-Reply-To: <24197762.6Emhk5qWAg@7940hx>
On Fri, 19 Dec 2025 09:57:37 +0800
Menglong Dong <menglong.dong@linux.dev> wrote:
> On 2025/12/18 21:06 liujing40 <liujing.root@gmail.com> write:
> > When fprobe is not available, provide a fallback implementation of
> > kprobe_multi using the traditional kretprobe API.
> >
> > Uses kretprobe's entry_handler and handler callbacks to simulate fprobe's
> > entry/exit functionality.
> >
> > Signed-off-by: Jing Liu <liujing40@xiaomi.com>
> > ---
> > kernel/trace/bpf_trace.c | 307 +++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 295 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 1fd07c10378f..426a1c627508 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -2274,12 +2274,44 @@ struct bpf_session_run_ctx {
> > void *data;
> > };
> >
> > -#ifdef CONFIG_FPROBE
> > +#if defined(CONFIG_FPROBE) || defined(CONFIG_KRETPROBES)
> > +#ifndef CONFIG_FPROBE
> > +struct bpf_kprobe {
> > + struct bpf_kprobe_multi_link *link;
> > + u64 cookie;
> > + struct kretprobe rp;
> > +};
> > +
> > +static void bpf_kprobe_unregister(struct bpf_kprobe *kps, u32 cnt)
> > +{
> > + for (int i = 0; i < cnt; i++)
> > + unregister_kretprobe(&kps[i].rp);
> > +}
> > +
> > +static int bpf_kprobe_register(struct bpf_kprobe *kps, u32 cnt)
> > +{
> > + int ret = 0, i;
> > +
> > + for (i = 0; i < cnt; i++) {
> > + ret = register_kretprobe(&kps[i].rp);
> > + if (ret < 0) {
> > + bpf_kprobe_unregister(kps, i);
> > + break;
> > + }
> > + }
> > + return ret;
> > +}
>
> Hi, Jing. I don't see the point of the fallback logic. If we want to
> use the kprobe-multi, we enable CONFIG_FPROBE. Is there any reason
> that we can't enable CONFIG_FPROBE? As you said, for a "old kernel",
> I think we don't introduce new feature for an old kernel.
>
> Besides, did you measure the performance of attaching bench?
> You will register a kretprobe for each of the target. AFAIK, the
> kprobe will use ftrace for optimization if we hook the entry of the
> target function. So I suspect it will be quite slow here.
>
> Thanks!
> Menglong Dong
The Dynamic ftrace feature is not enabled in Android for security reasons,
forcing us to fall back on kretprobe.
https://source.android.com/docs/core/tests/debug/ftrace#dftrace
I will provide the benchmark test results as soon as possible.
^ permalink raw reply
* Re: [PATCH 2/2] bpf: Implement kretprobe fallback for kprobe multi link
From: liujing40 @ 2025-12-22 8:00 UTC (permalink / raw)
To: rostedt
Cc: alexei.starovoitov, andrii, ast, bpf, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, linux-trace-kernel,
liujing.root, liujing40, martin.lau, mhiramat, sdf, song,
yonghong.song
In-Reply-To: <20251218160925.3c02a721@gandalf.local.home>
On Thu, 18 Dec 2025 16:09:25 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 18 Dec 2025 09:53:16 -0800
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > > +static void bpf_kprobe_unregister(struct bpf_kprobe *kps, u32 cnt)
> > > +{
> > > + for (int i = 0; i < cnt; i++)
> > > + unregister_kretprobe(&kps[i].rp);
> > > +}
> >
> > Nack.
> > This is not a good idea.
> > unregister_kretprobe() calls synchronize_rcu().
> > So the above loop will cause soft lockups for sure.
>
> Looks like it could be replaced with:
>
> unregister_kretprobes(kps, cnt);
>
> Which unregisters an array of kreptrobes and does a single
> synchronize_rcu().
>
> -- Steve
Thanks for the suggestion. I will refactor the loop to use
unregister_kretprobes() for a single RCU sync.
^ permalink raw reply
* Re: [PATCH] rv: Fix documentation reference in da_monitor.h
From: Gabriele Monaco @ 2025-12-22 7:52 UTC (permalink / raw)
To: Shubham Sharma, rostedt; +Cc: linux-trace-kernel, linux-kernel
In-Reply-To: <20251207205546.73946-1-slopixelz@gmail.com>
On Mon, 2025-12-08 at 02:25 +0530, Shubham Sharma wrote:
> Update documentation reference to reflect the file rename.
> Monitor synthesis documentation was renamed in commit f40a7c060207
> (\"Documentation/rv: Prepare monitor synthesis document for LTL inclusion\")
> from da_monitor_synthesis.rst to monitor_synthesis.rst.
>
> Signed-off-by: Shubham Sharma <slopixelz@gmail.com>
Hi Shubham,
thanks for catching this! I see the same problem is visible in the rvgen
comments (tools/verification/rvgen/{__main__.py,rvgen/dot2k.py}) but that's a
separate thing to fix.
The backslashes before the quotes are not required in the commit message, would
you mind removing them:
> commit f40a7c060207
> ("Documentation/rv: Prepare monitor synthesis document for LTL inclusion")
Other than that it looks good.
Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
Thanks,
Gabriele
> ---
> include/rv/da_monitor.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/rv/da_monitor.h b/include/rv/da_monitor.h
> index 0cef64366538..810cfb140131 100644
> --- a/include/rv/da_monitor.h
> +++ b/include/rv/da_monitor.h
> @@ -8,7 +8,7 @@
> * The dot2k tool is available at tools/verification/dot2k/
> *
> * For further information, see:
> - * Documentation/trace/rv/da_monitor_synthesis.rst
> + * Documentation/trace/rv/monitor_synthesis.rst
> */
>
> #include <rv/automata.h>
^ permalink raw reply
* Re: [PATCH v4 6/7] LoongArch: BPF: Enhance the bpf_arch_text_poke() function
From: Chenghao Duan @ 2025-12-22 1:50 UTC (permalink / raw)
To: Hengqi Chen
Cc: yangtiezhu, rostedt, mhiramat, mark.rutland, chenhuacai, kernel,
zhangtianyang, masahiroy, linux-kernel, loongarch, bpf,
youling.tang, jianghaoran, vincent.mc.li, linux-trace-kernel
In-Reply-To: <CAEyhmHRbacxpfTkPJq4MerBupH0bJkFfx8xGUvHMvGOzDDJUow@mail.gmail.com>
On Sat, Dec 20, 2025 at 10:07:25PM +0800, Hengqi Chen wrote:
> On Wed, Dec 17, 2025 at 2:15 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> >
> > Enhance the bpf_arch_text_poke() function to enable accurate location
> > of BPF program entry points.
> >
> > When modifying the entry point of a BPF program, skip the move t0, ra
> > instruction to ensure the correct logic and copy of the jump address.
> >
> > Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> > ---
> > arch/loongarch/net/bpf_jit.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> > index 3dbabacc8856..0c16a1b18e8f 100644
> > --- a/arch/loongarch/net/bpf_jit.c
> > +++ b/arch/loongarch/net/bpf_jit.c
> > @@ -1290,6 +1290,10 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> > void *new_addr)
>
> The signature of bpf_arch_text_poke() was changed in v6.19 ([1]), please rebase.
>
> [1]: https://github.com/torvalds/linux/commit/ae4a3160d19cd16b874737ebc1798c7bc2fe3c9e
Thank you for your review and for pointing out the API change in v6.19.
I believe my patch series already accounts for this. It was developed on
top of commit ae4a3160d19c ("bpf: specify the old and new poke_type for bpf_arch_text_poke"),
so all modifications to bpf_arch_text_poke() call sites within my
patches should already be using the updated signature.
Please let me know if you find any inconsistencies or if further
adjustments are needed.
Best regards,
Chenghao
>
> > {
> > int ret;
> > + unsigned long size = 0;
> > + unsigned long offset = 0;
> > + char namebuf[KSYM_NAME_LEN];
> > + void *image = NULL;
> > bool is_call;
> > u32 old_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> > u32 new_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> > @@ -1297,9 +1301,18 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> > /* Only poking bpf text is supported. Since kernel function entry
> > * is set up by ftrace, we rely on ftrace to poke kernel functions.
> > */
> > - if (!is_bpf_text_address((unsigned long)ip))
> > + if (!__bpf_address_lookup((unsigned long)ip, &size, &offset, namebuf))
> > return -ENOTSUPP;
> >
> > + image = ip - offset;
> > + /* zero offset means we're poking bpf prog entry */
> > + if (offset == 0)
> > + /* skip to the nop instruction in bpf prog entry:
> > + * move t0, ra
> > + * nop
> > + */
> > + ip = image + LOONGARCH_INSN_SIZE;
> > +
> > is_call = old_t == BPF_MOD_CALL;
> > ret = emit_jump_or_nops(old_addr, ip, old_insns, is_call);
> > if (ret)
> > --
> > 2.25.1
> >
^ permalink raw reply
* Re: [PATCH v4 0/2] kallsyms: Always initialize modbuildid
From: Maurice Hieronymus @ 2025-12-21 18:44 UTC (permalink / raw)
To: ast, daniel, john.fastabend, andrii, martin.lau, eddyz87, song,
yonghong.song, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers
Cc: georges.aureau, bpf, linux-kernel, linux-trace-kernel
In-Reply-To: <20251220181838.63242-1-mhi@mailbox.org>
On Sat, 2025-12-20 at 19:18 +0100, Maurice Hieronymus wrote:
> modbuildid is never set when kallsyms_lookup_buildid is returning via
> successful bpf_address_lookup or ftrace_mod_address_lookup.
>
> This leads to an uninitialized pointer dereference on x86 when
> CONFIG_STACKTRACE_BUILD_ID=y inside __sprint_symbol.
>
> Prevent this by always initializing modbuildid.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220717
>
> Changes to v3:
> - Split the changes into separate ftrace and bpf patches
> - Replace IS_ENABLED() with plain #ifdef
>
> Maurice Hieronymus (2):
> kallsyms: Always initialize modbuildid on ftrace address
> kallsyms: Always initialize modbuildid on bpf address
>
> include/linux/filter.h | 6 ++++--
> include/linux/ftrace.h | 4 ++--
> kernel/kallsyms.c | 4 ++--
> kernel/trace/ftrace.c | 8 +++++++-
> 4 files changed, 15 insertions(+), 7 deletions(-)
>
>
> base-commit: dd9b004b7ff3289fb7bae35130c0a5c0537266af
This patch is obsolete and already fixed by [1]
[1]
https://lore.kernel.org/bpf/20251128135920.217303-1-pmladek@suse.com/#t
^ permalink raw reply
* Re: [PATCH v4 2/2] kallsyms: Always initialize modbuildid on bpf address
From: Alexei Starovoitov @ 2025-12-21 18:17 UTC (permalink / raw)
To: Maurice Hieronymus
Cc: Alexei Starovoitov, Daniel Borkmann, John Fastabend,
Andrii Nakryiko, Martin KaFai Lau, Eduard, Song Liu,
Yonghong Song, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Steven Rostedt, Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers,
georges.aureau, bpf, LKML, linux-trace-kernel
In-Reply-To: <20251220181838.63242-3-mhi@mailbox.org>
On Sat, Dec 20, 2025 at 8:19 AM Maurice Hieronymus <mhi@mailbox.org> wrote:
>
> modbuildid is never set when kallsyms_lookup_buildid is returning via
> successful bpf_address_lookup.
>
> This leads to an uninitialized pointer dereference on x86 when
> CONFIG_STACKTRACE_BUILD_ID=y inside __sprint_symbol.
>
> Prevent this by always initializing modbuildid.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220717
> Signed-off-by: Maurice Hieronymus <mhi@mailbox.org>
> ---
> include/linux/filter.h | 6 ++++--
> kernel/kallsyms.c | 2 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index fd54fed8f95f..eb1d1c876503 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -1384,12 +1384,14 @@ struct bpf_prog *bpf_prog_ksym_find(unsigned long addr);
>
> static inline int
> bpf_address_lookup(unsigned long addr, unsigned long *size,
> - unsigned long *off, char **modname, char *sym)
> + unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym)
> {
> int ret = __bpf_address_lookup(addr, size, off, sym);
>
> if (ret && modname)
> *modname = NULL;
> + if (ret && modbuildid)
> + *modbuildid = NULL;
> return ret;
> }
>
> @@ -1455,7 +1457,7 @@ static inline struct bpf_prog *bpf_prog_ksym_find(unsigned long addr)
>
> static inline int
> bpf_address_lookup(unsigned long addr, unsigned long *size,
> - unsigned long *off, char **modname, char *sym)
> + unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym)
No.
Please search the earlier threads where this was discussed.
The patches to fix this were posted and I think they landed
in some tree already.
pw-bot: cr
^ permalink raw reply
* Re: [PATCHv5 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: kernel test robot @ 2025-12-21 11:09 UTC (permalink / raw)
To: Jiri Olsa, Steven Rostedt, Florent Revest, Mark Rutland
Cc: oe-kbuild-all, bpf, linux-kernel, linux-trace-kernel,
linux-arm-kernel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Menglong Dong, Song Liu
In-Reply-To: <20251215211402.353056-10-jolsa@kernel.org>
Hi Jiri,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Jiri-Olsa/ftrace-bpf-Remove-FTRACE_OPS_FL_JMP-ftrace_ops-flag/20251216-052916
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/20251215211402.353056-10-jolsa%40kernel.org
patch subject: [PATCHv5 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
config: arc-allyesconfig (https://download.01.org/0day-ci/archive/20251221/202512211826.gtdm52TX-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251221/202512211826.gtdm52TX-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512211826.gtdm52TX-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/bpf/trampoline.c: In function 'unregister_fentry':
>> kernel/bpf/trampoline.c:367:23: error: implicit declaration of function 'direct_ops_del'; did you mean 'direct_ops_free'? [-Wimplicit-function-declaration]
367 | ret = direct_ops_del(tr, old_addr);
| ^~~~~~~~~~~~~~
| direct_ops_free
kernel/bpf/trampoline.c: In function 'modify_fentry':
>> kernel/bpf/trampoline.c:381:23: error: implicit declaration of function 'direct_ops_mod'; did you mean 'direct_ops_free'? [-Wimplicit-function-declaration]
381 | ret = direct_ops_mod(tr, new_addr, lock_direct_mutex);
| ^~~~~~~~~~~~~~
| direct_ops_free
kernel/bpf/trampoline.c: In function 'register_fentry':
>> kernel/bpf/trampoline.c:404:23: error: implicit declaration of function 'direct_ops_add'; did you mean 'direct_ops_free'? [-Wimplicit-function-declaration]
404 | ret = direct_ops_add(tr, new_addr);
| ^~~~~~~~~~~~~~
| direct_ops_free
vim +367 kernel/bpf/trampoline.c
360
361 static int unregister_fentry(struct bpf_trampoline *tr, u32 orig_flags,
362 void *old_addr)
363 {
364 int ret;
365
366 if (tr->func.ftrace_managed)
> 367 ret = direct_ops_del(tr, old_addr);
368 else
369 ret = bpf_trampoline_update_fentry(tr, orig_flags, old_addr, NULL);
370
371 return ret;
372 }
373
374 static int modify_fentry(struct bpf_trampoline *tr, u32 orig_flags,
375 void *old_addr, void *new_addr,
376 bool lock_direct_mutex)
377 {
378 int ret;
379
380 if (tr->func.ftrace_managed) {
> 381 ret = direct_ops_mod(tr, new_addr, lock_direct_mutex);
382 } else {
383 ret = bpf_trampoline_update_fentry(tr, orig_flags, old_addr,
384 new_addr);
385 }
386 return ret;
387 }
388
389 /* first time registering */
390 static int register_fentry(struct bpf_trampoline *tr, void *new_addr)
391 {
392 void *ip = tr->func.addr;
393 unsigned long faddr;
394 int ret;
395
396 faddr = ftrace_location((unsigned long)ip);
397 if (faddr) {
398 if (!tr->fops)
399 return -ENOTSUPP;
400 tr->func.ftrace_managed = true;
401 }
402
403 if (tr->func.ftrace_managed) {
> 404 ret = direct_ops_add(tr, new_addr);
405 } else {
406 ret = bpf_trampoline_update_fentry(tr, 0, NULL, new_addr);
407 }
408
409 return ret;
410 }
411
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label
From: Wei Yang @ 2025-12-21 1:16 UTC (permalink / raw)
To: Garg, Shivank
Cc: Wei Yang, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Zi Yan, Baolin Wang, Liam R . Howlett, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, linux-mm, linux-kernel,
linux-trace-kernel
In-Reply-To: <63453d94-6410-43fd-8676-dbb04e423b10@amd.com>
On Sun, Dec 21, 2025 at 12:02:11AM +0530, Garg, Shivank wrote:
>
>
>On 12/20/2025 6:08 AM, Wei Yang wrote:
>> On Fri, Dec 19, 2025 at 02:54:40PM +0530, Garg, Shivank wrote:
>>>
>>>
>>> On 12/17/2025 8:18 AM, Wei Yang wrote:
>>>> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>>>>> Replace 'goto skip' with actual logic for better code readability.
>>>>>
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>>>> ---
>>>>> mm/khugepaged.c | 7 ++++---
>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>>>> index 6c8c35d3e0c9..107146f012b1 100644
>>>>> --- a/mm/khugepaged.c
>>>>> +++ b/mm/khugepaged.c
>>>>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>>>>> break;
>>>>> }
>>>>> if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>>>>> -skip:
>>>>> progress++;
>>>>> continue;
>>>>> }
>>>>> hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>>>>> hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>>>>> - if (khugepaged_scan.address > hend)
>>>>> - goto skip;
>>>>> + if (khugepaged_scan.address > hend) {
>>>>> + progress++;
>>>>> + continue;
>>>>> + }
>>>>
>>>> Hi, Shivank
>>>>
>>>> The change here looks good, while I come up with an question.
>>>>
>>>> The @progress here seems record two things:
>>>>
>>>> * number of pages scaned
>>>> * number of vma skipped
>>>>
>>> Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().
>>>
>>
>> Agree.
>>
>>>
>>>> While in very rare case, we may miss to count the second case.
>>>>
>>>> For example, we have following vmas in a process:
>>>>
>>>> vma1 vma2
>>>> +----------------+------------+
>>>> |2M |1M |
>>>> +----------------+------------+
>>>>
>>>> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
>>>> But vma2 is only half of HPAGE_PMD_SIZE.
>>>>
>>>> When scan finish vma1 and start on vma2, we would have hstart = hend =
>>>> address. So we continue here but would not do real scan, since address == hend.
>>>>
>>>> I am thinking whether this could handle it:
>>>>
>>>> if (khugepaged_scan.address > hend || hend <= hstart) {
>>>> progress++;
>>>> continue;
>>>> }
>>>>
>>>> Do you thinks I am correct on this?
>>>
>>> I think you're correct.
>>> IIUC, @progress acts as rate limiter here.
>>>
>>> It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
>>> or by +HPAGE_PMD_NR (if actually scanned).
>>>
>>> So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
>>> at which point it yields and sleeps (wait_event_freezable).
>>>
>>> Without your suggested fix, if a process contains a large number of small VMAs (where
>>> round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
>>> yielding compared to a process with fewer or aligned VMAs.
>>
>> You are right. While I am not sure it exists in reality, but in theory it
>> could be.
>>
>>>
>>> I think your suggestion is ensuring fairness by charging 'progress' count correctly.
>>>
>>
>> Thanks for your confirmation. Would you mind add a cleanup in next version, or
>> you prefer me to send it :-)
>
>Sure, I'll add this fix patch in the next version.
>
Thanks
>Thanks,
>Shivank
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 2/4] cgroup: Introduce cgroup_level() helper
From: kernel test robot @ 2025-12-20 21:49 UTC (permalink / raw)
To: Michal Koutný, linux-block, linux-kernel, cgroups,
linux-trace-kernel, bpf, netfilter-devel, coreteam, netdev
Cc: oe-kbuild-all, Michal Koutný, Yu Kuai, Jens Axboe, Tejun Heo,
Josef Bacik, Johannes Weiner, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Pablo Neira Ayuso
In-Reply-To: <20251217162744.352391-3-mkoutny@suse.com>
Hi Michal,
kernel test robot noticed the following build errors:
[auto build test ERROR on 8f0b4cce4481fb22653697cced8d0d04027cb1e8]
url: https://github.com/intel-lab-lkp/linux/commits/Michal-Koutn/cgroup-Eliminate-cgrp_ancestor_storage-in-cgroup_root/20251218-004346
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20251217162744.352391-3-mkoutny%40suse.com
patch subject: [PATCH 2/4] cgroup: Introduce cgroup_level() helper
config: nios2-allmodconfig (https://download.01.org/0day-ci/archive/20251221/202512210532.ziNaxDJf-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251221/202512210532.ziNaxDJf-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512210532.ziNaxDJf-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
block/blk-iocost.c: In function 'ioc_pd_init':
>> block/blk-iocost.c:3006:60: error: expected ';' before 'for'
3006 | iocg->level = cgroup_level(blkg->blkcg->css.cgroup)
| ^
| ;
3007 |
3008 | for (tblkg = blkg; tblkg; tblkg = tblkg->parent) {
| ~~~
>> block/blk-iocost.c:2988:26: warning: unused variable 'tblkg' [-Wunused-variable]
2988 | struct blkcg_gq *tblkg;
| ^~~~~
vim +3006 block/blk-iocost.c
2981
2982 static void ioc_pd_init(struct blkg_policy_data *pd)
2983 {
2984 struct ioc_gq *iocg = pd_to_iocg(pd);
2985 struct blkcg_gq *blkg = pd_to_blkg(&iocg->pd);
2986 struct ioc *ioc = q_to_ioc(blkg->q);
2987 struct ioc_now now;
> 2988 struct blkcg_gq *tblkg;
2989 unsigned long flags;
2990
2991 ioc_now(ioc, &now);
2992
2993 iocg->ioc = ioc;
2994 atomic64_set(&iocg->vtime, now.vnow);
2995 atomic64_set(&iocg->done_vtime, now.vnow);
2996 atomic64_set(&iocg->active_period, atomic64_read(&ioc->cur_period));
2997 INIT_LIST_HEAD(&iocg->active_list);
2998 INIT_LIST_HEAD(&iocg->walk_list);
2999 INIT_LIST_HEAD(&iocg->surplus_list);
3000 iocg->hweight_active = WEIGHT_ONE;
3001 iocg->hweight_inuse = WEIGHT_ONE;
3002
3003 init_waitqueue_head(&iocg->waitq);
3004 hrtimer_setup(&iocg->waitq_timer, iocg_waitq_timer_fn, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
3005
> 3006 iocg->level = cgroup_level(blkg->blkcg->css.cgroup)
3007
3008 for (tblkg = blkg; tblkg; tblkg = tblkg->parent) {
3009 struct ioc_gq *tiocg = blkg_to_iocg(tblkg);
3010 iocg->ancestors[tiocg->level] = tiocg;
3011 }
3012
3013 spin_lock_irqsave(&ioc->lock, flags);
3014 weight_updated(iocg, &now);
3015 spin_unlock_irqrestore(&ioc->lock, flags);
3016 }
3017
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCHv5 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: kernel test robot @ 2025-12-20 19:38 UTC (permalink / raw)
To: Jiri Olsa, Steven Rostedt, Florent Revest, Mark Rutland
Cc: llvm, oe-kbuild-all, bpf, linux-kernel, linux-trace-kernel,
linux-arm-kernel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Menglong Dong, Song Liu
In-Reply-To: <20251215211402.353056-10-jolsa@kernel.org>
Hi Jiri,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Jiri-Olsa/ftrace-bpf-Remove-FTRACE_OPS_FL_JMP-ftrace_ops-flag/20251216-052916
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/20251215211402.353056-10-jolsa%40kernel.org
patch subject: [PATCHv5 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
config: riscv-allmodconfig (https://download.01.org/0day-ci/archive/20251221/202512210241.4wuAmCHu-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b324c9f4fa112d61a553bf489b5f4f7ceea05ea8)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251221/202512210241.4wuAmCHu-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512210241.4wuAmCHu-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/bpf/trampoline.c:367:9: error: call to undeclared function 'direct_ops_del'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
367 | ret = direct_ops_del(tr, old_addr);
| ^
kernel/bpf/trampoline.c:367:9: note: did you mean 'direct_ops_free'?
kernel/bpf/trampoline.c:298:13: note: 'direct_ops_free' declared here
298 | static void direct_ops_free(struct bpf_trampoline *tr) { }
| ^
>> kernel/bpf/trampoline.c:381:9: error: call to undeclared function 'direct_ops_mod'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
381 | ret = direct_ops_mod(tr, new_addr, lock_direct_mutex);
| ^
kernel/bpf/trampoline.c:381:9: note: did you mean 'direct_ops_free'?
kernel/bpf/trampoline.c:298:13: note: 'direct_ops_free' declared here
298 | static void direct_ops_free(struct bpf_trampoline *tr) { }
| ^
>> kernel/bpf/trampoline.c:404:9: error: call to undeclared function 'direct_ops_add'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
404 | ret = direct_ops_add(tr, new_addr);
| ^
kernel/bpf/trampoline.c:404:9: note: did you mean 'direct_ops_free'?
kernel/bpf/trampoline.c:298:13: note: 'direct_ops_free' declared here
298 | static void direct_ops_free(struct bpf_trampoline *tr) { }
| ^
3 errors generated.
vim +/direct_ops_del +367 kernel/bpf/trampoline.c
360
361 static int unregister_fentry(struct bpf_trampoline *tr, u32 orig_flags,
362 void *old_addr)
363 {
364 int ret;
365
366 if (tr->func.ftrace_managed)
> 367 ret = direct_ops_del(tr, old_addr);
368 else
369 ret = bpf_trampoline_update_fentry(tr, orig_flags, old_addr, NULL);
370
371 return ret;
372 }
373
374 static int modify_fentry(struct bpf_trampoline *tr, u32 orig_flags,
375 void *old_addr, void *new_addr,
376 bool lock_direct_mutex)
377 {
378 int ret;
379
380 if (tr->func.ftrace_managed) {
> 381 ret = direct_ops_mod(tr, new_addr, lock_direct_mutex);
382 } else {
383 ret = bpf_trampoline_update_fentry(tr, orig_flags, old_addr,
384 new_addr);
385 }
386 return ret;
387 }
388
389 /* first time registering */
390 static int register_fentry(struct bpf_trampoline *tr, void *new_addr)
391 {
392 void *ip = tr->func.addr;
393 unsigned long faddr;
394 int ret;
395
396 faddr = ftrace_location((unsigned long)ip);
397 if (faddr) {
398 if (!tr->fops)
399 return -ENOTSUPP;
400 tr->func.ftrace_managed = true;
401 }
402
403 if (tr->func.ftrace_managed) {
> 404 ret = direct_ops_add(tr, new_addr);
405 } else {
406 ret = bpf_trampoline_update_fentry(tr, 0, NULL, new_addr);
407 }
408
409 return ret;
410 }
411
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label
From: Garg, Shivank @ 2025-12-20 18:32 UTC (permalink / raw)
To: Wei Yang
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes, Zi Yan,
Baolin Wang, Liam R . Howlett, Nico Pache, Ryan Roberts, Dev Jain,
Barry Song, Lance Yang, linux-mm, linux-kernel,
linux-trace-kernel
In-Reply-To: <20251220003851.dzsafcxtlbgzwsm6@master>
On 12/20/2025 6:08 AM, Wei Yang wrote:
> On Fri, Dec 19, 2025 at 02:54:40PM +0530, Garg, Shivank wrote:
>>
>>
>> On 12/17/2025 8:18 AM, Wei Yang wrote:
>>> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>>>> Replace 'goto skip' with actual logic for better code readability.
>>>>
>>>> No functional change.
>>>>
>>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>>> ---
>>>> mm/khugepaged.c | 7 ++++---
>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>>> index 6c8c35d3e0c9..107146f012b1 100644
>>>> --- a/mm/khugepaged.c
>>>> +++ b/mm/khugepaged.c
>>>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>>>> break;
>>>> }
>>>> if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>>>> -skip:
>>>> progress++;
>>>> continue;
>>>> }
>>>> hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>>>> hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>>>> - if (khugepaged_scan.address > hend)
>>>> - goto skip;
>>>> + if (khugepaged_scan.address > hend) {
>>>> + progress++;
>>>> + continue;
>>>> + }
>>>
>>> Hi, Shivank
>>>
>>> The change here looks good, while I come up with an question.
>>>
>>> The @progress here seems record two things:
>>>
>>> * number of pages scaned
>>> * number of vma skipped
>>>
>> Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().
>>
>
> Agree.
>
>>
>>> While in very rare case, we may miss to count the second case.
>>>
>>> For example, we have following vmas in a process:
>>>
>>> vma1 vma2
>>> +----------------+------------+
>>> |2M |1M |
>>> +----------------+------------+
>>>
>>> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
>>> But vma2 is only half of HPAGE_PMD_SIZE.
>>>
>>> When scan finish vma1 and start on vma2, we would have hstart = hend =
>>> address. So we continue here but would not do real scan, since address == hend.
>>>
>>> I am thinking whether this could handle it:
>>>
>>> if (khugepaged_scan.address > hend || hend <= hstart) {
>>> progress++;
>>> continue;
>>> }
>>>
>>> Do you thinks I am correct on this?
>>
>> I think you're correct.
>> IIUC, @progress acts as rate limiter here.
>>
>> It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
>> or by +HPAGE_PMD_NR (if actually scanned).
>>
>> So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
>> at which point it yields and sleeps (wait_event_freezable).
>>
>> Without your suggested fix, if a process contains a large number of small VMAs (where
>> round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
>> yielding compared to a process with fewer or aligned VMAs.
>
> You are right. While I am not sure it exists in reality, but in theory it
> could be.
>
>>
>> I think your suggestion is ensuring fairness by charging 'progress' count correctly.
>>
>
> Thanks for your confirmation. Would you mind add a cleanup in next version, or
> you prefer me to send it :-)
Sure, I'll add this fix patch in the next version.
Thanks,
Shivank
^ permalink raw reply
* [PATCH v4 2/2] kallsyms: Always initialize modbuildid on bpf address
From: Maurice Hieronymus @ 2025-12-20 18:18 UTC (permalink / raw)
To: ast, daniel, john.fastabend, andrii, martin.lau, eddyz87, song,
yonghong.song, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers
Cc: georges.aureau, bpf, linux-kernel, linux-trace-kernel, mhi
In-Reply-To: <20251220181838.63242-1-mhi@mailbox.org>
modbuildid is never set when kallsyms_lookup_buildid is returning via
successful bpf_address_lookup.
This leads to an uninitialized pointer dereference on x86 when
CONFIG_STACKTRACE_BUILD_ID=y inside __sprint_symbol.
Prevent this by always initializing modbuildid.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220717
Signed-off-by: Maurice Hieronymus <mhi@mailbox.org>
---
include/linux/filter.h | 6 ++++--
kernel/kallsyms.c | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index fd54fed8f95f..eb1d1c876503 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -1384,12 +1384,14 @@ struct bpf_prog *bpf_prog_ksym_find(unsigned long addr);
static inline int
bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
+ unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym)
{
int ret = __bpf_address_lookup(addr, size, off, sym);
if (ret && modname)
*modname = NULL;
+ if (ret && modbuildid)
+ *modbuildid = NULL;
return ret;
}
@@ -1455,7 +1457,7 @@ static inline struct bpf_prog *bpf_prog_ksym_find(unsigned long addr)
static inline int
bpf_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
+ unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym)
{
return 0;
}
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 5ca69eafda7a..b1516d3fa9c5 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -378,7 +378,7 @@ static int kallsyms_lookup_buildid(unsigned long addr,
modname, modbuildid, namebuf);
if (!ret)
ret = bpf_address_lookup(addr, symbolsize,
- offset, modname, namebuf);
+ offset, modname, modbuildid, namebuf);
if (!ret)
ret = ftrace_mod_address_lookup(addr, symbolsize,
--
2.50.1
^ permalink raw reply related
* [PATCH v4 1/2] kallsyms: Always initialize modbuildid on ftrace address
From: Maurice Hieronymus @ 2025-12-20 18:18 UTC (permalink / raw)
To: ast, daniel, john.fastabend, andrii, martin.lau, eddyz87, song,
yonghong.song, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers
Cc: georges.aureau, bpf, linux-kernel, linux-trace-kernel, mhi
In-Reply-To: <20251220181838.63242-1-mhi@mailbox.org>
modbuildid is never set when kallsyms_lookup_buildid is returning via
successful ftrace_mod_address_lookup.
This leads to an uninitialized pointer dereference on x86 when
CONFIG_STACKTRACE_BUILD_ID=y inside __sprint_symbol.
Prevent this by always initializing modbuildid.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220717
Signed-off-by: Maurice Hieronymus <mhi@mailbox.org>
---
include/linux/ftrace.h | 4 ++--
kernel/kallsyms.c | 2 +-
kernel/trace/ftrace.c | 8 +++++++-
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 770f0dc993cc..ed673fa2536b 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -87,11 +87,11 @@ struct ftrace_hash;
defined(CONFIG_DYNAMIC_FTRACE)
int
ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym);
+ unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym);
#else
static inline int
ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
+ unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym)
{
return 0;
}
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 049e296f586c..5ca69eafda7a 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -382,7 +382,7 @@ static int kallsyms_lookup_buildid(unsigned long addr,
if (!ret)
ret = ftrace_mod_address_lookup(addr, symbolsize,
- offset, modname, namebuf);
+ offset, modname, modbuildid, namebuf);
return ret;
}
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index ef2d5dca6f70..6eba92a52261 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -7752,7 +7752,7 @@ ftrace_func_address_lookup(struct ftrace_mod_map *mod_map,
int
ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
- unsigned long *off, char **modname, char *sym)
+ unsigned long *off, char **modname, const unsigned char **modbuildid, char *sym)
{
struct ftrace_mod_map *mod_map;
int ret = 0;
@@ -7764,6 +7764,12 @@ ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
if (ret) {
if (modname)
*modname = mod_map->mod->name;
+ if (modbuildid)
+#ifdef CONFIG_STACKTRACE_BUILD_ID
+ *modbuildid = mod_map->mod->build_id;
+#else
+ *modbuildid = NULL;
+#endif
break;
}
}
--
2.50.1
^ permalink raw reply related
* [PATCH v4 0/2] kallsyms: Always initialize modbuildid
From: Maurice Hieronymus @ 2025-12-20 18:18 UTC (permalink / raw)
To: ast, daniel, john.fastabend, andrii, martin.lau, eddyz87, song,
yonghong.song, kpsingh, sdf, haoluo, jolsa, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers
Cc: georges.aureau, bpf, linux-kernel, linux-trace-kernel, mhi
modbuildid is never set when kallsyms_lookup_buildid is returning via
successful bpf_address_lookup or ftrace_mod_address_lookup.
This leads to an uninitialized pointer dereference on x86 when
CONFIG_STACKTRACE_BUILD_ID=y inside __sprint_symbol.
Prevent this by always initializing modbuildid.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220717
Changes to v3:
- Split the changes into separate ftrace and bpf patches
- Replace IS_ENABLED() with plain #ifdef
Maurice Hieronymus (2):
kallsyms: Always initialize modbuildid on ftrace address
kallsyms: Always initialize modbuildid on bpf address
include/linux/filter.h | 6 ++++--
include/linux/ftrace.h | 4 ++--
kernel/kallsyms.c | 4 ++--
kernel/trace/ftrace.c | 8 +++++++-
4 files changed, 15 insertions(+), 7 deletions(-)
base-commit: dd9b004b7ff3289fb7bae35130c0a5c0537266af
--
2.50.1
^ permalink raw reply
* Re: [PATCH 2/4] cgroup: Introduce cgroup_level() helper
From: kernel test robot @ 2025-12-20 14:59 UTC (permalink / raw)
To: Michal Koutný, linux-block, linux-kernel, cgroups,
linux-trace-kernel, bpf, netfilter-devel, coreteam, netdev
Cc: oe-kbuild-all, Michal Koutný, Yu Kuai, Jens Axboe, Tejun Heo,
Josef Bacik, Johannes Weiner, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Pablo Neira Ayuso
In-Reply-To: <20251217162744.352391-3-mkoutny@suse.com>
Hi Michal,
kernel test robot noticed the following build errors:
[auto build test ERROR on 8f0b4cce4481fb22653697cced8d0d04027cb1e8]
url: https://github.com/intel-lab-lkp/linux/commits/Michal-Koutn/cgroup-Eliminate-cgrp_ancestor_storage-in-cgroup_root/20251218-004346
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20251217162744.352391-3-mkoutny%40suse.com
patch subject: [PATCH 2/4] cgroup: Introduce cgroup_level() helper
config: sparc64-randconfig-r134-20251218 (https://download.01.org/0day-ci/archive/20251220/202512202230.1uoB5chV-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251220/202512202230.1uoB5chV-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512202230.1uoB5chV-lkp@intel.com/
All errors (new ones prefixed by >>):
>> block/blk-iocost.c:3006:53: error: expected ';' after expression
3006 | iocg->level = cgroup_level(blkg->blkcg->css.cgroup)
| ^
| ;
1 error generated.
vim +3006 block/blk-iocost.c
2981
2982 static void ioc_pd_init(struct blkg_policy_data *pd)
2983 {
2984 struct ioc_gq *iocg = pd_to_iocg(pd);
2985 struct blkcg_gq *blkg = pd_to_blkg(&iocg->pd);
2986 struct ioc *ioc = q_to_ioc(blkg->q);
2987 struct ioc_now now;
2988 struct blkcg_gq *tblkg;
2989 unsigned long flags;
2990
2991 ioc_now(ioc, &now);
2992
2993 iocg->ioc = ioc;
2994 atomic64_set(&iocg->vtime, now.vnow);
2995 atomic64_set(&iocg->done_vtime, now.vnow);
2996 atomic64_set(&iocg->active_period, atomic64_read(&ioc->cur_period));
2997 INIT_LIST_HEAD(&iocg->active_list);
2998 INIT_LIST_HEAD(&iocg->walk_list);
2999 INIT_LIST_HEAD(&iocg->surplus_list);
3000 iocg->hweight_active = WEIGHT_ONE;
3001 iocg->hweight_inuse = WEIGHT_ONE;
3002
3003 init_waitqueue_head(&iocg->waitq);
3004 hrtimer_setup(&iocg->waitq_timer, iocg_waitq_timer_fn, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
3005
> 3006 iocg->level = cgroup_level(blkg->blkcg->css.cgroup)
3007
3008 for (tblkg = blkg; tblkg; tblkg = tblkg->parent) {
3009 struct ioc_gq *tiocg = blkg_to_iocg(tblkg);
3010 iocg->ancestors[tiocg->level] = tiocg;
3011 }
3012
3013 spin_lock_irqsave(&ioc->lock, flags);
3014 weight_updated(iocg, &now);
3015 spin_unlock_irqrestore(&ioc->lock, flags);
3016 }
3017
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 6/7] LoongArch: BPF: Enhance the bpf_arch_text_poke() function
From: Hengqi Chen @ 2025-12-20 14:07 UTC (permalink / raw)
To: Chenghao Duan
Cc: yangtiezhu, rostedt, mhiramat, mark.rutland, chenhuacai, kernel,
zhangtianyang, masahiroy, linux-kernel, loongarch, bpf,
youling.tang, jianghaoran, vincent.mc.li, linux-trace-kernel
In-Reply-To: <20251217061435.802204-7-duanchenghao@kylinos.cn>
On Wed, Dec 17, 2025 at 2:15 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> Enhance the bpf_arch_text_poke() function to enable accurate location
> of BPF program entry points.
>
> When modifying the entry point of a BPF program, skip the move t0, ra
> instruction to ensure the correct logic and copy of the jump address.
>
> Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> ---
> arch/loongarch/net/bpf_jit.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index 3dbabacc8856..0c16a1b18e8f 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c
> @@ -1290,6 +1290,10 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> void *new_addr)
The signature of bpf_arch_text_poke() was changed in v6.19 ([1]), please rebase.
[1]: https://github.com/torvalds/linux/commit/ae4a3160d19cd16b874737ebc1798c7bc2fe3c9e
> {
> int ret;
> + unsigned long size = 0;
> + unsigned long offset = 0;
> + char namebuf[KSYM_NAME_LEN];
> + void *image = NULL;
> bool is_call;
> u32 old_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> u32 new_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> @@ -1297,9 +1301,18 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> /* Only poking bpf text is supported. Since kernel function entry
> * is set up by ftrace, we rely on ftrace to poke kernel functions.
> */
> - if (!is_bpf_text_address((unsigned long)ip))
> + if (!__bpf_address_lookup((unsigned long)ip, &size, &offset, namebuf))
> return -ENOTSUPP;
>
> + image = ip - offset;
> + /* zero offset means we're poking bpf prog entry */
> + if (offset == 0)
> + /* skip to the nop instruction in bpf prog entry:
> + * move t0, ra
> + * nop
> + */
> + ip = image + LOONGARCH_INSN_SIZE;
> +
> is_call = old_t == BPF_MOD_CALL;
> ret = emit_jump_or_nops(old_addr, ip, old_insns, is_call);
> if (ret)
> --
> 2.25.1
>
^ permalink raw reply
* [RFC PATCH bpf 2/2] selftests/bpf: add regression tests for snprintf and get_stack helpers
From: Zesen Liu @ 2025-12-20 11:35 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan
Cc: bpf, linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Zesen Liu, Shuran Liu, Peili Gao, Haoran Ni
In-Reply-To: <20251220-helper_proto-v1-0-2206e0d9422d@gmail.com>
Add regression tests for bpf_snprintf(), bpf_snprintf_btf(), and
bpf_get_stack() to cover incorrect verifier assumptions caused by
incorrect function prototypes.
These tests reproduce the scenario where the verifier previously
incorrectly assumed that the destination buffer remained unwritten
across the helper call. The tests call these helpers and verify that
subsequent reads see the updated data, ensuring that the verifier
correctly marks the memory as clobbered and does not optimize away
the reads based on stale assumptions.
Co-developed-by: Shuran Liu <electronlsr@gmail.com>
Signed-off-by: Shuran Liu <electronlsr@gmail.com>
Co-developed-by: Peili Gao <gplhust955@gmail.com>
Signed-off-by: Peili Gao <gplhust955@gmail.com>
Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Zesen Liu <ftyghome@gmail.com>
---
tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c | 15 +++++++++++++--
tools/testing/selftests/bpf/prog_tests/snprintf.c | 6 ++++++
tools/testing/selftests/bpf/prog_tests/snprintf_btf.c | 3 +++
tools/testing/selftests/bpf/progs/netif_receive_skb.c | 13 ++++++++++++-
tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 11 ++++++++++-
tools/testing/selftests/bpf/progs/test_snprintf.c | 12 ++++++++++++
6 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c b/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
index 858e0575f502..7c2774b49138 100644
--- a/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
+++ b/tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c
@@ -87,13 +87,13 @@ void test_get_stack_raw_tp(void)
const char *file = "./test_get_stack_rawtp.bpf.o";
const char *file_err = "./test_get_stack_rawtp_err.bpf.o";
const char *prog_name = "bpf_prog1";
- int i, err, prog_fd, exp_cnt = MAX_CNT_RAWTP;
+ int i, err, prog_fd, exp_cnt = MAX_CNT_RAWTP, key = 0, valid_top_stack = 0;
struct perf_buffer *pb = NULL;
struct bpf_link *link = NULL;
struct timespec tv = {0, 10};
struct bpf_program *prog;
struct bpf_object *obj;
- struct bpf_map *map;
+ struct bpf_map *map, *bss_map;
cpu_set_t cpu_set;
err = bpf_prog_test_load(file_err, BPF_PROG_TYPE_RAW_TRACEPOINT, &obj, &prog_fd);
@@ -135,6 +135,17 @@ void test_get_stack_raw_tp(void)
for (i = 0; i < MAX_CNT_RAWTP; i++)
nanosleep(&tv, NULL);
+ bss_map = bpf_object__find_map_by_name(obj, ".bss");
+ if (CHECK(!bss_map, "find .bss map", "not found\n"))
+ goto close_prog;
+
+ err = bpf_map_lookup_elem(bpf_map__fd(bss_map), &key, &valid_top_stack);
+ if (CHECK(err, "lookup .bss", "err %d errno %d\n", err, errno))
+ goto close_prog;
+
+ if (!ASSERT_EQ(valid_top_stack, 1, "valid_top_stack"))
+ goto close_prog;
+
while (exp_cnt > 0) {
err = perf_buffer__poll(pb, 100);
if (err < 0 && CHECK(err < 0, "pb__poll", "err %d\n", err))
diff --git a/tools/testing/selftests/bpf/prog_tests/snprintf.c b/tools/testing/selftests/bpf/prog_tests/snprintf.c
index 594441acb707..80d6f2655b5f 100644
--- a/tools/testing/selftests/bpf/prog_tests/snprintf.c
+++ b/tools/testing/selftests/bpf/prog_tests/snprintf.c
@@ -33,6 +33,9 @@
#define EXP_NO_BUF_RET 29
+#define EXP_STACK_OUT "stack_out"
+#define EXP_STACK_RET sizeof(EXP_STACK_OUT)
+
static void test_snprintf_positive(void)
{
char exp_addr_out[] = EXP_ADDR_OUT;
@@ -79,6 +82,9 @@ static void test_snprintf_positive(void)
ASSERT_EQ(skel->bss->nobuf_ret, EXP_NO_BUF_RET, "no_buf_ret");
+ ASSERT_EQ(skel->bss->stack_ret, EXP_STACK_RET, "stack_ret");
+ ASSERT_STREQ(skel->bss->stack_out, EXP_STACK_OUT, "stack_out");
+
cleanup:
test_snprintf__destroy(skel);
}
diff --git a/tools/testing/selftests/bpf/prog_tests/snprintf_btf.c b/tools/testing/selftests/bpf/prog_tests/snprintf_btf.c
index dd41b826be30..a2e400a4880d 100644
--- a/tools/testing/selftests/bpf/prog_tests/snprintf_btf.c
+++ b/tools/testing/selftests/bpf/prog_tests/snprintf_btf.c
@@ -55,6 +55,9 @@ void serial_test_snprintf_btf(void)
bss->ran_subtests))
goto cleanup;
+ if (!ASSERT_EQ(bss->stack_out_test_passed, 1, "stack output test failed"))
+ goto cleanup;
+
cleanup:
netif_receive_skb__destroy(skel);
}
diff --git a/tools/testing/selftests/bpf/progs/netif_receive_skb.c b/tools/testing/selftests/bpf/progs/netif_receive_skb.c
index 9e067dcbf607..f78d5f56f6c9 100644
--- a/tools/testing/selftests/bpf/progs/netif_receive_skb.c
+++ b/tools/testing/selftests/bpf/progs/netif_receive_skb.c
@@ -12,9 +12,11 @@
long ret = 0;
int num_subtests = 0;
int ran_subtests = 0;
+int stack_out_test_passed = 0;
bool skip = false;
-#define STRSIZE 2048
+#define STRSIZE 2048
+#define STACK_STRSIZE 64
#define EXPECTED_STRSIZE 256
#if defined(bpf_target_s390)
@@ -98,6 +100,7 @@ int BPF_PROG(trace_netif_receive_skb, struct sk_buff *skb)
__u32 key = 0;
int i, __ret;
char *str;
+ char stack_out[STACK_STRSIZE] = { };
#if __has_builtin(__builtin_btf_type_id)
str = bpf_map_lookup_elem(&strdata, &key);
@@ -124,6 +127,13 @@ int BPF_PROG(trace_netif_receive_skb, struct sk_buff *skb)
ret = -ERANGE;
}
+ /* Check when writing to a buffer on the stack */
+ p.type_id = bpf_core_type_id_kernel(struct sk_buff);
+ p.ptr = skb;
+ ret = bpf_snprintf_btf(stack_out, STACK_STRSIZE, &p, sizeof(p), 0);
+ if (ret >= 0 && stack_out[0] != '\0')
+ stack_out_test_passed = 1;
+
/* Verify type display for various types. */
/* simple int */
@@ -242,6 +252,7 @@ int BPF_PROG(trace_netif_receive_skb, struct sk_buff *skb)
TEST_BTF(str, struct bpf_insn, BTF_F_NONAME, "{1,0x2,0x3,4,5,}",
{.code = 1, .dst_reg = 0x2, .src_reg = 0x3, .off = 4,
.imm = 5,});
+
#else
skip = true;
#endif
diff --git a/tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c b/tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c
index b6a6eb279e54..57723dc823a0 100644
--- a/tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c
+++ b/tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c
@@ -54,14 +54,17 @@ struct {
__type(value, __u64[2 * MAX_STACK_RAWTP]);
} rawdata_map SEC(".maps");
+int valid_top_stack = 0;
+
SEC("raw_tracepoint/sys_enter")
int bpf_prog1(void *ctx)
{
int max_len, max_buildid_len, total_size;
struct stack_trace_t *data;
- long usize, ksize;
+ long usize, ksize, top_usize;
void *raw_data;
__u32 key = 0;
+ __u64 top_user_stack = 0;
data = bpf_map_lookup_elem(&stackdata_map, &key);
if (!data)
@@ -88,6 +91,12 @@ int bpf_prog1(void *ctx)
if (usize < 0)
return 0;
+ /* checks if the verifier correctly marks the stack variable as written. */
+ top_usize = bpf_get_stack(ctx, &top_user_stack, sizeof(__u64),
+ BPF_F_USER_STACK);
+ if (top_usize > 0 && top_user_stack != 0)
+ valid_top_stack = 1;
+
ksize = bpf_get_stack(ctx, raw_data + usize, max_len - usize, 0);
if (ksize < 0)
return 0;
diff --git a/tools/testing/selftests/bpf/progs/test_snprintf.c b/tools/testing/selftests/bpf/progs/test_snprintf.c
index 8fda07544023..ce78fd7add03 100644
--- a/tools/testing/selftests/bpf/progs/test_snprintf.c
+++ b/tools/testing/selftests/bpf/progs/test_snprintf.c
@@ -32,6 +32,9 @@ long noarg_ret = 0;
long nobuf_ret = 0;
+char stack_out[64] = {};
+long stack_ret = 0;
+
extern const void schedule __ksym;
SEC("raw_tp/sys_enter")
@@ -42,6 +45,7 @@ int handler(const void *ctx)
const __u8 ex_ipv6[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1};
static const char str1[] = "str1";
static const char longstr[] = "longstr";
+ char buf[64] = {};
if ((int)bpf_get_current_pid_tgid() != pid)
return 0;
@@ -71,6 +75,14 @@ int handler(const void *ctx)
/* No buffer */
nobuf_ret = BPF_SNPRINTF(NULL, 0, "only interested in length %d", 60);
+ /* Write to a buffer on the stack */
+ stack_ret = BPF_SNPRINTF(buf, sizeof(buf), "stack_out");
+ /* The condition is necessary to check if the verifier
+ * correctly marks the stack memory as written.
+ */
+ if (buf[0] != '\0')
+ __builtin_memcpy(stack_out, buf, 64);
+
return 0;
}
--
2.43.0
^ permalink raw reply related
* [RFC PATCH bpf 1/2] bpf: Fix memory access tags in helper prototypes
From: Zesen Liu @ 2025-12-20 11:35 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan
Cc: bpf, linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Zesen Liu, Shuran Liu, Peili Gao, Haoran Ni
In-Reply-To: <20251220-helper_proto-v1-0-2206e0d9422d@gmail.com>
After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"),
the verifier started relying on the access type tags in helper
function prototypes to perform memory access optimizations.
Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the
corresponding MEM_RDONLY or MEM_WRITE tags. This omission causes the
verifier to incorrectly assume that the buffer contents are unchanged
across the helper call. Consequently, the verifier may optimize away
subsequent reads based on this wrong assumption, leading to correctness
issues.
Similar issues were recently addressed for specific helpers in commit
ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer")
and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args").
Fix these prototypes by adding the correct memory access tags.
Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking")
Co-developed-by: Shuran Liu <electronlsr@gmail.com>
Signed-off-by: Shuran Liu <electronlsr@gmail.com>
Co-developed-by: Peili Gao <gplhust955@gmail.com>
Signed-off-by: Peili Gao <gplhust955@gmail.com>
Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com>
Signed-off-by: Zesen Liu <ftyghome@gmail.com>
---
kernel/bpf/helpers.c | 2 +-
kernel/trace/bpf_trace.c | 6 +++---
net/core/filter.c | 8 ++++----
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index db72b96f9c8c..f66284f8ec2c 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1077,7 +1077,7 @@ const struct bpf_func_proto bpf_snprintf_proto = {
.func = bpf_snprintf,
.gpl_only = true,
.ret_type = RET_INTEGER,
- .arg1_type = ARG_PTR_TO_MEM_OR_NULL,
+ .arg1_type = ARG_PTR_TO_MEM_OR_NULL | MEM_WRITE,
.arg2_type = ARG_CONST_SIZE_OR_ZERO,
.arg3_type = ARG_PTR_TO_CONST_STR,
.arg4_type = ARG_PTR_TO_MEM | PTR_MAYBE_NULL | MEM_RDONLY,
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index fe28d86f7c35..59c2394981c7 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1022,7 +1022,7 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = {
.func = bpf_snprintf_btf,
.gpl_only = false,
.ret_type = RET_INTEGER,
- .arg1_type = ARG_PTR_TO_MEM,
+ .arg1_type = ARG_PTR_TO_MEM | MEM_WRITE,
.arg2_type = ARG_CONST_SIZE,
.arg3_type = ARG_PTR_TO_MEM | MEM_RDONLY,
.arg4_type = ARG_CONST_SIZE,
@@ -1526,7 +1526,7 @@ static const struct bpf_func_proto bpf_read_branch_records_proto = {
.gpl_only = true,
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_CTX,
- .arg2_type = ARG_PTR_TO_MEM_OR_NULL,
+ .arg2_type = ARG_PTR_TO_MEM_OR_NULL | MEM_WRITE,
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
.arg4_type = ARG_ANYTHING,
};
@@ -1661,7 +1661,7 @@ static const struct bpf_func_proto bpf_get_stack_proto_raw_tp = {
.gpl_only = true,
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_CTX,
- .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
+ .arg2_type = ARG_PTR_TO_UNINIT_MEM,
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
.arg4_type = ARG_ANYTHING,
};
diff --git a/net/core/filter.c b/net/core/filter.c
index 616e0520a0bb..6e07bb994aa7 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6399,7 +6399,7 @@ static const struct bpf_func_proto bpf_xdp_fib_lookup_proto = {
.gpl_only = true,
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_CTX,
- .arg2_type = ARG_PTR_TO_MEM,
+ .arg2_type = ARG_PTR_TO_MEM | MEM_WRITE,
.arg3_type = ARG_CONST_SIZE,
.arg4_type = ARG_ANYTHING,
};
@@ -6454,7 +6454,7 @@ static const struct bpf_func_proto bpf_skb_fib_lookup_proto = {
.gpl_only = true,
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_CTX,
- .arg2_type = ARG_PTR_TO_MEM,
+ .arg2_type = ARG_PTR_TO_MEM | MEM_WRITE,
.arg3_type = ARG_CONST_SIZE,
.arg4_type = ARG_ANYTHING,
};
@@ -8010,7 +8010,7 @@ static const struct bpf_func_proto bpf_tcp_raw_gen_syncookie_ipv4_proto = {
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_FIXED_SIZE_MEM,
.arg1_size = sizeof(struct iphdr),
- .arg2_type = ARG_PTR_TO_MEM,
+ .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
};
@@ -8042,7 +8042,7 @@ static const struct bpf_func_proto bpf_tcp_raw_gen_syncookie_ipv6_proto = {
.ret_type = RET_INTEGER,
.arg1_type = ARG_PTR_TO_FIXED_SIZE_MEM,
.arg1_size = sizeof(struct ipv6hdr),
- .arg2_type = ARG_PTR_TO_MEM,
+ .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
.arg3_type = ARG_CONST_SIZE_OR_ZERO,
};
--
2.43.0
^ permalink raw reply related
* [RFC bpf PATCH 0/2] bpf: Fix memory access tags in helper prototypes
From: Zesen Liu @ 2025-12-20 11:35 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan
Cc: bpf, linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Zesen Liu, Shuran Liu, Peili Gao, Haoran Ni
Hi,
This series adds missing memory access tags (MEM_RDONLY or MEM_WRITE) to
several bpf helper function prototypes that use ARG_PTR_TO_MEM but lack the
correct type annotation.
Missing memory access tags in helper prototypes can lead to critical
correctness issues when the verifier tries to perform code optimization.
After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type
tracking"), the verifier relies on the memory access tags, rather than
treating all arguments in helper functions as potentially modifying the
pointed-to memory.
We have already seen several reports regarding this:
- commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's
output buffer") adds MEM_WRITE to bpf_d_path;
- commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name
args") adds MEM_WRITE to bpf_sysctl_get_name.
This series looks through all prototypes in the kernel and completes the
tags. In addition, this series also adds selftests for some of these
functions.
I marked the series as RFC since the introduced selftests are fragile and
ad hoc (similar to the previously added selftests). The original goal of
these tests is to reproduce the case where the verifier wrongly optimizes
reads after the helper function is called. However, triggering the error
often requires carefully designed code patterns. For example, I had to
explicitly use "if (xx != 0)" in my attached tests, because using memcmp
will not reproduce the issue. This makes the reproduction heavily dependent
on the verifier's internal optimization logic and clutters the selftests
with specific, unnatural patterns.
Some cases are also hard to trigger by selftests. For example, I couldn't
find a triggering pattern for bpf_read_branch_records, since the
execution of program seems to be messed up by wrong tags. For
bpf_skb_fib_lookup, I also failed to reproduce it because the argument
needs content on entry, but the verifier seems to only enable this
optimization for fully empty buffers.
Since adding selftests does not help with existing issues or prevent future
occurrences of similar problems, I believe one way to resolve it is to
statically restrict ARG_PTR_TO_MEM from appearing without memory access
tags. Using ARG_PTR_TO_MEM alone without tags is nonsensical because:
- If the helper does not change the argument, missing MEM_RDONLY causes
the verifier to incorrectly reject a read-only buffer.
- If the helper does change the argument, missing MEM_WRITE causes the
verifier to incorrectly assume the memory is unchanged, leading to
potential errors.
I am still wondering, if we agree on the above, how should we enforce this
restriction? Should we let ARG_PTR_TO_MEM imply MEM_WRITE semantics by
default, and change ARG_PTR_TO_MEM | MEM_RDONLY to ARG_CONST_PTR_TO_MEM? Or
should we add a check in the verifier to ensure ARG_PTR_TO_MEM always comes
with an access tag (though this seems to only catch errors at
runtime/testing)?
Any insights and comments are welcome. If the individual fix patches for
the prototypes look correct, I would also really appreciate it if they
could be merged ahead of the discussion.
Thanks,
Zesen Liu
Signed-off-by: Zesen Liu <ftyghome@gmail.com>
---
Zesen Liu (2):
bpf: Fix memory access tags in helper prototypes
selftests/bpf: add regression tests for snprintf and get_stack helpers
kernel/bpf/helpers.c | 2 +-
kernel/trace/bpf_trace.c | 6 +++---
net/core/filter.c | 8 ++++----
tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c | 15 +++++++++++++--
tools/testing/selftests/bpf/prog_tests/snprintf.c | 6 ++++++
tools/testing/selftests/bpf/prog_tests/snprintf_btf.c | 3 +++
tools/testing/selftests/bpf/progs/netif_receive_skb.c | 13 ++++++++++++-
tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 11 ++++++++++-
tools/testing/selftests/bpf/progs/test_snprintf.c | 12 ++++++++++++
9 files changed, 64 insertions(+), 12 deletions(-)
---
base-commit: 22cc16c04b7893d8fc22810599f49a305d600b9e
change-id: 20251220-helper_proto-fb6e64182467
Best regards,
--
Zesen Liu <ftyghome@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label
From: Wei Yang @ 2025-12-20 0:38 UTC (permalink / raw)
To: Garg, Shivank
Cc: Wei Yang, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Zi Yan, Baolin Wang, Liam R . Howlett, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, linux-mm, linux-kernel,
linux-trace-kernel
In-Reply-To: <c7c1d62c-7d27-4b73-8173-0493adc66cfc@amd.com>
On Fri, Dec 19, 2025 at 02:54:40PM +0530, Garg, Shivank wrote:
>
>
>On 12/17/2025 8:18 AM, Wei Yang wrote:
>> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>>> Replace 'goto skip' with actual logic for better code readability.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>> ---
>>> mm/khugepaged.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index 6c8c35d3e0c9..107146f012b1 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>>> break;
>>> }
>>> if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>>> -skip:
>>> progress++;
>>> continue;
>>> }
>>> hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>>> hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>>> - if (khugepaged_scan.address > hend)
>>> - goto skip;
>>> + if (khugepaged_scan.address > hend) {
>>> + progress++;
>>> + continue;
>>> + }
>>
>> Hi, Shivank
>>
>> The change here looks good, while I come up with an question.
>>
>> The @progress here seems record two things:
>>
>> * number of pages scaned
>> * number of vma skipped
>>
>Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().
>
Agree.
>
>> While in very rare case, we may miss to count the second case.
>>
>> For example, we have following vmas in a process:
>>
>> vma1 vma2
>> +----------------+------------+
>> |2M |1M |
>> +----------------+------------+
>>
>> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
>> But vma2 is only half of HPAGE_PMD_SIZE.
>>
>> When scan finish vma1 and start on vma2, we would have hstart = hend =
>> address. So we continue here but would not do real scan, since address == hend.
>>
>> I am thinking whether this could handle it:
>>
>> if (khugepaged_scan.address > hend || hend <= hstart) {
>> progress++;
>> continue;
>> }
>>
>> Do you thinks I am correct on this?
>
>I think you're correct.
>IIUC, @progress acts as rate limiter here.
>
>It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
>or by +HPAGE_PMD_NR (if actually scanned).
>
>So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
>at which point it yields and sleeps (wait_event_freezable).
>
>Without your suggested fix, if a process contains a large number of small VMAs (where
>round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
>yielding compared to a process with fewer or aligned VMAs.
You are right. While I am not sure it exists in reality, but in theory it
could be.
>
>I think your suggestion is ensuring fairness by charging 'progress' count correctly.
>
Thanks for your confirmation. Would you mind add a cleanup in next version, or
you prefer me to send it :-)
>Thanks,
>Shivank
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH V2] blktrace: log dropped REQ_OP_ZONE_XXX events ver1
From: Damien Le Moal @ 2025-12-19 23:55 UTC (permalink / raw)
To: Chaitanya Kulkarni, johannes.thumshirn
Cc: axboe, rostedt, mhiramat, mathieu.desnoyers, martin.petersen,
linux-block, linux-trace-kernel
In-Reply-To: <20251028173209.2859-1-ckulkarnilinux@gmail.com>
On 10/29/25 02:32, Chaitanya Kulkarni wrote:
> Add informational messages during blktrace setup when version 1 tools
> are used on kernels with CONFIG_BLK_DEV_ZONED enabled. This alerts users
> that REQ_OP_ZONE_* events will be dropped and suggests upgrading to
> blktrace tools version 2 or later.
>
> The warning is printed once during trace setup to inform users about
> the limitation without spamming the logs during tracing operations.
> Version 2 blktrace tools properly handle zone management operations
> (zone reset, zone open, zone close, zone finish, zone append) that
> were added for zoned block devices.
>
> Example output:
>
> blktests (master) # ./check blktrace
> blktrace/001 (blktrace zone management command tracing) [passed]
> runtime 0.110s ... 3.917s
> blktrace/002 (blktrace ftrace corruption with sysfs trace) [passed]
> runtime 0.333s ... 0.608s
> blktests (master) # dmesg -c
> [ 57.610592] blktrace: nullb0: blktrace events for REQ_OP_ZONE_XXX will be dropped
> [ 57.610603] blktrace: use blktrace tools version >= 2 to track REQ_OP_ZONE_XXX
>
> This helps users understand why zone operation traces may be missing
> when using older blktrace tool versions with modern kernels that
> support REQ_OP_ZONE_XXX in blktrace.
>
> Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
> ---
> v1->v2 :-
>
> Remove the extra () around IS_ENABLED(CONFIG_BLK_DEV_ZONED). (Jens)
> Add a space after device name in first pr_info(). (Jens)
>
> ---
> kernel/trace/blktrace.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index e4f26ddb7ee2..4a37d9aa0481 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -739,6 +739,12 @@ static void blk_trace_setup_finalize(struct request_queue *q,
> */
> strreplace(buts->name, '/', '_');
>
> + if (version == 1 && IS_ENABLED(CONFIG_BLK_DEV_ZONED)) {
> + pr_info("%s: blktrace events for REQ_OP_ZONE_XXX will be dropped\n",
> + name);
> + pr_info("use blktrace tools version >= 2 to track REQ_OP_ZONE_XXX\n");
Please change REQ_OP_ZONE_XXX to "zone operations" in these messages. That is a
little more general, so better I think since we also trace zone write
plug/unplug events, which are not REQ_OP_ZONE_XXX.
With that done,
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
> + }
> +
> bt->version = version;
> bt->act_mask = buts->act_mask;
> if (!bt->act_mask)
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* Re: [PATCH V2] blktrace: log dropped REQ_OP_ZONE_XXX events ver1
From: Chaitanya Kulkarni @ 2025-12-19 23:50 UTC (permalink / raw)
To: Johannes Thumshirn, Chaitanya Kulkarni
Cc: axboe@kernel.dk, dlemoal@kernel.org, rostedt@goodmis.org,
mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
martin.petersen@oracle.com, linux-block@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, Chaitanya Kulkarni
In-Reply-To: <fc5f6ed4-5bd3-4c4d-82c3-cdab26dcbf94@wdc.com>
On 10/28/25 23:47, Johannes Thumshirn wrote:
> On 10/28/25 6:32 PM, Chaitanya Kulkarni wrote:
>> + if (version == 1 && IS_ENABLED(CONFIG_BLK_DEV_ZONED)) {
>> + pr_info("%s: blktrace events for REQ_OP_ZONE_XXX will be dropped\n",
>> + name);
>> + pr_info("use blktrace tools version >= 2 to track REQ_OP_ZONE_XXX\n");
> Jens hasn't merged the user-space part yet and I'm not sure he'll assign
> a dedicated version number for it. So I'd say hold this until he has.
>
Now Jen's has merged the userspace part, may I please get a reviewed-by if this
looks good?
-ck
^ 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