* [PATCH v3] kprobes: Use dedicated kthread for kprobe optimizer
From: Masami Hiramatsu (Google) @ 2026-01-21 1:08 UTC (permalink / raw)
To: Steven Rostedt, Naveen N Rao, David S . Miller, Masami Hiramatsu
Cc: linux-kernel, linux-trace-kernel
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Instead of using generic workqueue, use a dedicated kthread for optimizing
kprobes, because it can wait (sleep) for a long time inside the process
by synchronize_rcu_task(). This means other works can be stopped until it
finishes.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
Changes in v3:
- Wait events in interruptible state for avoiding hung_task.
Changes in v2:
- Make the kthread unfreezable same as workqueue.
- Add kthread_should_stop() check right before calling optimizer too.
- Initialize optimizer_state to OPTIMIZER_ST_IDLE instead of 0.
---
kernel/kprobes.c | 106 ++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 86 insertions(+), 20 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index ab8f9fc1f0d1..71e8d6e81eee 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/sysctl.h>
#include <linux/kdebug.h>
+#include <linux/kthread.h>
#include <linux/memory.h>
#include <linux/ftrace.h>
#include <linux/cpu.h>
@@ -40,6 +41,7 @@
#include <linux/perf_event.h>
#include <linux/execmem.h>
#include <linux/cleanup.h>
+#include <linux/wait.h>
#include <asm/sections.h>
#include <asm/cacheflush.h>
@@ -514,8 +516,17 @@ static LIST_HEAD(optimizing_list);
static LIST_HEAD(unoptimizing_list);
static LIST_HEAD(freeing_list);
-static void kprobe_optimizer(struct work_struct *work);
-static DECLARE_DELAYED_WORK(optimizing_work, kprobe_optimizer);
+static struct task_struct *kprobe_optimizer_task;
+static wait_queue_head_t kprobe_optimizer_wait;
+static atomic_t optimizer_state;
+enum {
+ OPTIMIZER_ST_IDLE = 0,
+ OPTIMIZER_ST_KICKED = 1,
+ OPTIMIZER_ST_FLUSHING = 2,
+};
+
+static DECLARE_COMPLETION(optimizer_completion);
+
#define OPTIMIZE_DELAY 5
/*
@@ -597,14 +608,10 @@ static void do_free_cleaned_kprobes(void)
}
}
-/* Start optimizer after OPTIMIZE_DELAY passed */
-static void kick_kprobe_optimizer(void)
-{
- schedule_delayed_work(&optimizing_work, OPTIMIZE_DELAY);
-}
+static void kick_kprobe_optimizer(void);
/* Kprobe jump optimizer */
-static void kprobe_optimizer(struct work_struct *work)
+static void kprobe_optimizer(void)
{
guard(mutex)(&kprobe_mutex);
@@ -635,9 +642,53 @@ static void kprobe_optimizer(struct work_struct *work)
do_free_cleaned_kprobes();
}
- /* Step 5: Kick optimizer again if needed */
+ /* Step 5: Kick optimizer again if needed. But if there is a flush requested, */
+ if (completion_done(&optimizer_completion))
+ complete(&optimizer_completion);
+
if (!list_empty(&optimizing_list) || !list_empty(&unoptimizing_list))
- kick_kprobe_optimizer();
+ kick_kprobe_optimizer(); /*normal kick*/
+}
+
+static int kprobe_optimizer_thread(void *data)
+{
+ while (!kthread_should_stop()) {
+ /* To avoid hung_task, wait in interruptible state. */
+ wait_event_interruptible(kprobe_optimizer_wait,
+ atomic_read(&optimizer_state) != OPTIMIZER_ST_IDLE ||
+ kthread_should_stop());
+
+ if (kthread_should_stop())
+ break;
+
+ /*
+ * If it was a normal kick, wait for OPTIMIZE_DELAY.
+ * This wait can be interrupted by a flush request.
+ */
+ if (atomic_read(&optimizer_state) == 1)
+ wait_event_interruptible_timeout(
+ kprobe_optimizer_wait,
+ atomic_read(&optimizer_state) == OPTIMIZER_ST_FLUSHING ||
+ kthread_should_stop(),
+ OPTIMIZE_DELAY);
+
+ if (kthread_should_stop())
+ break;
+
+ atomic_set(&optimizer_state, OPTIMIZER_ST_IDLE);
+
+ kprobe_optimizer();
+ }
+ return 0;
+}
+
+/* Start optimizer after OPTIMIZE_DELAY passed */
+static void kick_kprobe_optimizer(void)
+{
+ lockdep_assert_held(&kprobe_mutex);
+ if (atomic_cmpxchg(&optimizer_state,
+ OPTIMIZER_ST_IDLE, OPTIMIZER_ST_KICKED) == OPTIMIZER_ST_IDLE)
+ wake_up(&kprobe_optimizer_wait);
}
static void wait_for_kprobe_optimizer_locked(void)
@@ -645,13 +696,17 @@ static void wait_for_kprobe_optimizer_locked(void)
lockdep_assert_held(&kprobe_mutex);
while (!list_empty(&optimizing_list) || !list_empty(&unoptimizing_list)) {
- mutex_unlock(&kprobe_mutex);
-
- /* This will also make 'optimizing_work' execute immmediately */
- flush_delayed_work(&optimizing_work);
- /* 'optimizing_work' might not have been queued yet, relax */
- cpu_relax();
+ init_completion(&optimizer_completion);
+ /*
+ * Set state to OPTIMIZER_ST_FLUSHING and wake up the thread if it's
+ * idle. If it's already kicked, it will see the state change.
+ */
+ if (atomic_xchg_acquire(&optimizer_state,
+ OPTIMIZER_ST_FLUSHING) != OPTIMIZER_ST_FLUSHING)
+ wake_up(&kprobe_optimizer_wait);
+ mutex_unlock(&kprobe_mutex);
+ wait_for_completion(&optimizer_completion);
mutex_lock(&kprobe_mutex);
}
}
@@ -1010,8 +1065,21 @@ static void __disarm_kprobe(struct kprobe *p, bool reopt)
*/
}
+static void __init init_optprobe(void)
+{
+#ifdef __ARCH_WANT_KPROBES_INSN_SLOT
+ /* Init 'kprobe_optinsn_slots' for allocation */
+ kprobe_optinsn_slots.insn_size = MAX_OPTINSN_SIZE;
+#endif
+
+ init_waitqueue_head(&kprobe_optimizer_wait);
+ atomic_set(&optimizer_state, OPTIMIZER_ST_IDLE);
+ kprobe_optimizer_task = kthread_run(kprobe_optimizer_thread, NULL,
+ "kprobe-optimizer");
+}
#else /* !CONFIG_OPTPROBES */
+#define init_optprobe() do {} while (0)
#define optimize_kprobe(p) do {} while (0)
#define unoptimize_kprobe(p, f) do {} while (0)
#define kill_optimized_kprobe(p) do {} while (0)
@@ -2694,10 +2762,8 @@ static int __init init_kprobes(void)
/* By default, kprobes are armed */
kprobes_all_disarmed = false;
-#if defined(CONFIG_OPTPROBES) && defined(__ARCH_WANT_KPROBES_INSN_SLOT)
- /* Init 'kprobe_optinsn_slots' for allocation */
- kprobe_optinsn_slots.insn_size = MAX_OPTINSN_SIZE;
-#endif
+ /* Initialize the optimization infrastructure */
+ init_optprobe();
err = arch_init_kprobes();
if (!err)
^ permalink raw reply related
* Re: [PATCH bpf-next v3 0/2] bpf: Fix memory access flags in helper prototypes
From: patchwork-bot+netdevbpf @ 2026-01-21 1:20 UTC (permalink / raw)
To: Zesen Liu
Cc: ast, daniel, andrii, martin.lau, eddyz87, song, yonghong.song,
john.fastabend, kpsingh, sdf, haoluo, jolsa, mattbobrowski,
rostedt, mhiramat, mathieu.desnoyers, davem, edumazet, kuba,
pabeni, horms, dxu, bpf, linux-kernel, linux-trace-kernel, netdev,
electronlsr, gplhust955, haoran.ni.cs
In-Reply-To: <20260120-helper_proto-v3-0-27b0180b4e77@gmail.com>
Hello:
This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Tue, 20 Jan 2026 16:28:45 +0800 you wrote:
> Hi,
>
> This series adds missing memory access flags (MEM_RDONLY or MEM_WRITE) to
> several bpf helper function prototypes that use ARG_PTR_TO_MEM but lack the
> correct flag. It also adds a new check in verifier to ensure the flag is
> specified.
>
> [...]
Here is the summary with links:
- [bpf-next,v3,1/2] bpf: Fix memory access flags in helper prototypes
https://git.kernel.org/bpf/bpf-next/c/802eef5afb18
- [bpf-next,v3,2/2] bpf: Require ARG_PTR_TO_MEM with memory flag
https://git.kernel.org/bpf/bpf-next/c/ed4724212f6f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf-next v4 1/2] bpf: support bpf_get_func_arg() for BPF_TRACE_RAW_TP
From: Menglong Dong @ 2026-01-21 2:01 UTC (permalink / raw)
To: Menglong Dong, Andrii Nakryiko
Cc: ast, andrii, yonghong.song, daniel, john.fastabend, martin.lau,
eddyz87, song, kpsingh, sdf, haoluo, jolsa, mattbobrowski,
rostedt, mhiramat, mathieu.desnoyers, bpf, linux-kernel,
linux-trace-kernel
In-Reply-To: <CAEf4BzZUA+5jsYGN7dA1qEXyZKZvBnESX=8fuJHYmhOVm0_QEQ@mail.gmail.com>
On 2026/1/21 08:38 Andrii Nakryiko <andrii.nakryiko@gmail.com> write:
> On Mon, Jan 19, 2026 at 11:31 PM Menglong Dong <menglong8.dong@gmail.com> wrote:
> >
> > For now, bpf_get_func_arg() and bpf_get_func_arg_cnt() is not supported by
> > the BPF_TRACE_RAW_TP, which is not convenient to get the argument of the
> > tracepoint, especially for the case that the position of the arguments in
> > a tracepoint can change.
> >
> > The target tracepoint BTF type id is specified during loading time,
> > therefore we can get the function argument count from the function
> > prototype instead of the stack.
> >
> > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > ---
> > v4:
> > - fix the error of using bpf_get_func_arg() for BPF_TRACE_ITER
> >
> > v3:
> > - remove unnecessary NULL checking for prog->aux->attach_func_proto
> >
> > v2:
> > - for nr_args, skip first 'void *__data' argument in btf_trace_##name
> > typedef
> > ---
> > kernel/bpf/verifier.c | 32 ++++++++++++++++++++++++++++----
> > kernel/trace/bpf_trace.c | 4 ++++
> > 2 files changed, 32 insertions(+), 4 deletions(-)
> >
>
> other than stylistical choices, looks good to me
>
> Acked-by: Andrii Nakryiko <andrii@kernel.org>
>
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 9de0ec0c3ed9..0b281b7c41eb 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -23323,8 +23323,20 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > /* Implement bpf_get_func_arg inline. */
> > if (prog_type == BPF_PROG_TYPE_TRACING &&
> > insn->imm == BPF_FUNC_get_func_arg) {
> > - /* Load nr_args from ctx - 8 */
> > - insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > + if (eatype == BPF_TRACE_RAW_TP) {
> > + int nr_args = btf_type_vlen(prog->aux->attach_func_proto);
> > +
> > + /*
> > + * skip first 'void *__data' argument in btf_trace_##name
> > + * typedef
> > + */
> > + nr_args--;
> > + /* Save nr_args to reg0 */
> > + insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args);
> > + } else {
> > + /* Load nr_args from ctx - 8 */
> > + insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > + }
> > insn_buf[1] = BPF_JMP32_REG(BPF_JGE, BPF_REG_2, BPF_REG_0, 6);
> > insn_buf[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 3);
> > insn_buf[3] = BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_1);
> > @@ -23376,8 +23388,20 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > /* Implement get_func_arg_cnt inline. */
> > if (prog_type == BPF_PROG_TYPE_TRACING &&
> > insn->imm == BPF_FUNC_get_func_arg_cnt) {
> > - /* Load nr_args from ctx - 8 */
> > - insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > + if (eatype == BPF_TRACE_RAW_TP) {
> > + int nr_args = btf_type_vlen(prog->aux->attach_func_proto);
> > +
> > + /*
> > + * skip first 'void *__data' argument in btf_trace_##name
> > + * typedef
> > + */
> > + nr_args--;
> > + /* Save nr_args to reg0 */
> > + insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args);
>
> nit: isn't this just a very verbose way of writing:
>
> int nr_args = btf_type_vlen(prog->aux->attach_func_proto);
> /* skip 'void *__data' in btf_trace_##name() and save to reg0 */
> insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args - 1);
>
> even if you want to preserve nr_args-- for clarity, at least make that
> 4-line comment into a single-line one, please
>
> > + } else {
> > + /* Load nr_args from ctx - 8 */
> > + insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > + }
> >
> > new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, 1);
> > if (!new_prog)
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index f73e08c223b5..0efdad3adcce 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -1734,10 +1734,14 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> > case BPF_FUNC_d_path:
> > return &bpf_d_path_proto;
> > case BPF_FUNC_get_func_arg:
> > + if (prog->expected_attach_type == BPF_TRACE_RAW_TP)
> > + return &bpf_get_func_arg_proto;
> > return bpf_prog_has_trampoline(prog) ? &bpf_get_func_arg_proto : NULL;
> > case BPF_FUNC_get_func_ret:
> > return bpf_prog_has_trampoline(prog) ? &bpf_get_func_ret_proto : NULL;
> > case BPF_FUNC_get_func_arg_cnt:
> > + if (prog->expected_attach_type == BPF_TRACE_RAW_TP)
> > + return &bpf_get_func_arg_cnt_proto;
> > return bpf_prog_has_trampoline(prog) ? &bpf_get_func_arg_cnt_proto : NULL;
>
> hm, wouldn't "has trampoline or is raw_tp" a more logical grouping?
>
> if (bpf_prog_has_trampoline(prog) || prog->expected_attach_type ==
> BPF_TRACE_RAW_TP)
> return &bpf_get_func_arg_cnt_proto;
> return NULL;
>
> maybe you'll need to wrap that condition, but still, at least no one
> has to double check that we return exactly the same prototype in both
> cases, no?
Yeah, it looks better. I tried to write it as:
return (bpf_prog_has_trampoline(prog) || prog->expected_attach_type == BPF_TRACE_RAW_TP) ? &bpf_get_func_arg_cnt_proto : NULL;
but found it ugly.
The way you mentioned looks nice ;)
I'll do it next version.
Thanks!
Menglong Dong
>
>
> > case BPF_FUNC_get_attach_cookie:
> > if (prog->type == BPF_PROG_TYPE_TRACING &&
> > --
> > 2.52.0
> >
>
^ permalink raw reply
* Re: [PATCH net-next v4] page_pool: Add page_pool_release_stalled tracepoint
From: Leon Hwang @ 2026-01-21 2:17 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Jesper Dangaard Brouer, Ilias Apalodimas, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, kerneljasonxing,
lance.yang, jiayuan.chen, linux-kernel, linux-trace-kernel,
Leon Huang Fu
In-Reply-To: <20260120152934.2eb16a11@kernel.org>
On 21/1/26 07:29, Jakub Kicinski wrote:
> On Tue, 20 Jan 2026 11:16:20 +0800 Leon Hwang wrote:
>> I encountered the 'pr_warn()' messages during Mellanox NIC flapping on a
>> system using the 'mlx5_core' driver (kernel 6.6). The root cause turned
>> out to be an application-level issue: the IBM/sarama “Client SeekBroker
>> Connection Leak” [1].
>
> The scenario you are describing matches the situations we run into
> at Meta. With the upstream kernel you can find that the pages are
> leaking based on stats, and if you care use drgn to locate them
> (in the recv queue).
>
Thanks, that makes sense.
drgn indeed sounds helpful for locating the pages once it is confirmed
that the inflight pages are being held by the socket receive queue.
Before reaching that point, however, it was quite difficult to pinpoint
where those inflight pages were stuck. I was wondering whether there is
any other handy tool or method to help locate them earlier.
> The 6.6 kernel did not have page pool stats. I feel quite odd about
> adding more uAPI because someone is running a 2+ years old kernel
> and doesn't have access to the already existing facilities.
After checking the code again, I realized that the 6.6 kernel does
have page pool stats support.
Unfortunately, CONFIG_PAGE_POOL_STATS was not enabled in our Shopee
deployment, which is why those facilities were not available to us.
In any case, I understand your concern. I won’t pursue adding this
tracepoint further if it’s not something you’d like to see upstream.
Thanks,
Leon
^ permalink raw reply
* Re: [PATCH v2] scripts/tracepoint-update: fix memory leak in add_string() on failure
From: Masami Hiramatsu @ 2026-01-21 2:22 UTC (permalink / raw)
To: Weigang He
Cc: Steven Rostedt, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260119114542.1714405-1-geoffreyhe2@gmail.com>
On Mon, 19 Jan 2026 11:45:42 +0000
Weigang He <geoffreyhe2@gmail.com> wrote:
> When realloc() fails in add_string(), the function returns -1 but leaves
> *vals pointing to the previously allocated memory. This can cause memory
> leaks in callers like make_trace_array() that return on error without
> freeing the partially built array.
>
> Fix this by freeing *vals and setting it to NULL when realloc() fails.
> This makes the error handling self-contained in add_string() so callers
> don't need to handle cleanup on failure.
This looks not enough. If the memory allocation is failed, it should NOT
continue anything.
I think we need to make the command itself failure when it fails to
allocate memory, as below:
diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
index 90046aedc97b..1b4129a21942 100644
--- a/scripts/tracepoint-update.c
+++ b/scripts/tracepoint-update.c
@@ -94,7 +94,7 @@ static void make_trace_array(struct elf_tracepoint *etrace)
if (!len)
continue;
if (add_string(str, &vals, &count) < 0)
- return;
+ exit(EXIT_FAILURE);
}
/* If CONFIG_TRACEPOINT_VERIFY_USED is not set, there's nothing to do */
Thank you,
>
> This bug is found by my static analysis tool and my code review.
>
> Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
> ---
> scripts/tracepoint-update.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
> index 90046aedc97b9..5cf43c0aac891 100644
> --- a/scripts/tracepoint-update.c
> +++ b/scripts/tracepoint-update.c
> @@ -49,6 +49,8 @@ static int add_string(const char *str, const char ***vals, int *count)
> array = realloc(array, sizeof(char *) * size);
> if (!array) {
> fprintf(stderr, "Failed memory allocation\n");
> + free(*vals);
> + *vals = NULL;
> return -1;
> }
> *vals = array;
> --
> 2.34.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply related
* Re: [PATCH] scripts/tracepoint-update: fix memory leak in make_trace_array()
From: Masami Hiramatsu @ 2026-01-21 2:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Weigang He, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Tuo Li
In-Reply-To: <20260118105457.755291a5@robin>
On Sun, 18 Jan 2026 10:54:57 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sun, 18 Jan 2026 13:02:47 +0000
> Weigang He <geoffreyhe2@gmail.com> wrote:
>
> > In make_trace_array(), if add_string() fails after some successful
> > iterations, the function returns without freeing the 'vals' array that
> > was allocated by previous add_string() calls.
> >
> > The add_string() function uses realloc() internally with a local
> > temporary variable, which means the original pointer is preserved on
> > allocation failure. When make_trace_array() returns early on error,
> > the previously allocated memory is leaked.
> >
> > Fix this by freeing 'vals' before returning on the error path.
> >
> > This bug is found by my static analysis tool and my code review.
> >
> > Signed-off-by: Tuo Li <islituo@gmail.com>
> > ---
> > scripts/tracepoint-update.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
> > index 90046aedc97b9..7bc9d66229ddf 100644
> > --- a/scripts/tracepoint-update.c
> > +++ b/scripts/tracepoint-update.c
> > @@ -93,8 +93,10 @@ static void make_trace_array(struct elf_tracepoint *etrace)
> > for_each_shdr_str(len, ehdr, check_data_sec) {
> > if (!len)
> > continue;
> > - if (add_string(str, &vals, &count) < 0)
> > + if (add_string(str, &vals, &count) < 0) {
> > + free(vals);
> > return;
> > + }
> > }
>
> It would make much more sense to have add_string() free vals, and set
> vals to NULL on error.
I think it should be failed if it fails to add string. Can it
continue checking tracepoints even after the error?
Thank you,
>
> -- Steve
>
>
> >
> > /* If CONFIG_TRACEPOINT_VERIFY_USED is not set, there's nothing to do */
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH bpf-next v5 0/2] bpf: support bpf_get_func_arg() for BPF_TRACE_RAW_TP
From: Menglong Dong @ 2026-01-21 4:43 UTC (permalink / raw)
To: ast, andrii, yonghong.song
Cc: daniel, john.fastabend, martin.lau, eddyz87, song, kpsingh, sdf,
haoluo, jolsa, mattbobrowski, rostedt, mhiramat,
mathieu.desnoyers, bpf, linux-kernel, linux-trace-kernel
Support bpf_get_func_arg() for BPF_TRACE_RAW_TP by getting the function
argument count from "prog->aux->attach_func_proto" during verifier inline.
Changes v5 -> v4:
* some format adjustment in the 1st patch
* v4: https://lore.kernel.org/bpf/20260120073046.324342-1-dongml2@chinatelecom.cn/
Changes v4 -> v3:
* fix the error of using bpf_get_func_arg() for BPF_TRACE_ITER
* v3: https://lore.kernel.org/bpf/20260119023732.130642-1-dongml2@chinatelecom.cn/
Changes v3 -> v2:
* remove unnecessary NULL checking for prog->aux->attach_func_proto
* v2: https://lore.kernel.org/bpf/20260116071739.121182-1-dongml2@chinatelecom.cn/
Changes v2 -> v1:
* for nr_args, skip first 'void *__data' argument in btf_trace_##name
typedef
* check the result4 and result5 in the selftests
* v1: https://lore.kernel.org/bpf/20260116035024.98214-1-dongml2@chinatelecom.cn/
Menglong Dong (2):
bpf: support bpf_get_func_arg() for BPF_TRACE_RAW_TP
selftests/bpf: test bpf_get_func_arg() for tp_btf
kernel/bpf/verifier.c | 22 ++++++++--
kernel/trace/bpf_trace.c | 10 ++++-
.../bpf/prog_tests/get_func_args_test.c | 3 ++
.../selftests/bpf/progs/get_func_args_test.c | 44 +++++++++++++++++++
.../bpf/test_kmods/bpf_testmod-events.h | 10 +++++
.../selftests/bpf/test_kmods/bpf_testmod.c | 4 ++
6 files changed, 87 insertions(+), 6 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH bpf-next v5 1/2] bpf: support bpf_get_func_arg() for BPF_TRACE_RAW_TP
From: Menglong Dong @ 2026-01-21 4:43 UTC (permalink / raw)
To: ast, andrii, yonghong.song
Cc: daniel, john.fastabend, martin.lau, eddyz87, song, kpsingh, sdf,
haoluo, jolsa, mattbobrowski, rostedt, mhiramat,
mathieu.desnoyers, bpf, linux-kernel, linux-trace-kernel
In-Reply-To: <20260121044348.113201-1-dongml2@chinatelecom.cn>
For now, bpf_get_func_arg() and bpf_get_func_arg_cnt() is not supported by
the BPF_TRACE_RAW_TP, which is not convenient to get the argument of the
tracepoint, especially for the case that the position of the arguments in
a tracepoint can change.
The target tracepoint BTF type id is specified during loading time,
therefore we can get the function argument count from the function
prototype instead of the stack.
Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
---
v5:
- some format adjustment
v4:
- fix the error of using bpf_get_func_arg() for BPF_TRACE_ITER
v3:
- remove unnecessary NULL checking for prog->aux->attach_func_proto
v2:
- for nr_args, skip first 'void *__data' argument in btf_trace_##name
typedef
---
kernel/bpf/verifier.c | 22 ++++++++++++++++++----
kernel/trace/bpf_trace.c | 10 ++++++++--
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 9de0ec0c3ed9..c3f8870ac5dc 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -23323,8 +23323,15 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
/* Implement bpf_get_func_arg inline. */
if (prog_type == BPF_PROG_TYPE_TRACING &&
insn->imm == BPF_FUNC_get_func_arg) {
- /* Load nr_args from ctx - 8 */
- insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
+ if (eatype == BPF_TRACE_RAW_TP) {
+ int nr_args = btf_type_vlen(prog->aux->attach_func_proto);
+
+ /* skip 'void *__data' in btf_trace_##name() and save to reg0 */
+ insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args - 1);
+ } else {
+ /* Load nr_args from ctx - 8 */
+ insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
+ }
insn_buf[1] = BPF_JMP32_REG(BPF_JGE, BPF_REG_2, BPF_REG_0, 6);
insn_buf[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_2, 3);
insn_buf[3] = BPF_ALU64_REG(BPF_ADD, BPF_REG_2, BPF_REG_1);
@@ -23376,8 +23383,15 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
/* Implement get_func_arg_cnt inline. */
if (prog_type == BPF_PROG_TYPE_TRACING &&
insn->imm == BPF_FUNC_get_func_arg_cnt) {
- /* Load nr_args from ctx - 8 */
- insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
+ if (eatype == BPF_TRACE_RAW_TP) {
+ int nr_args = btf_type_vlen(prog->aux->attach_func_proto);
+
+ /* skip 'void *__data' in btf_trace_##name() and save to reg0 */
+ insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args - 1);
+ } else {
+ /* Load nr_args from ctx - 8 */
+ insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
+ }
new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, 1);
if (!new_prog)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f73e08c223b5..73c8f92c5d65 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1734,11 +1734,17 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
case BPF_FUNC_d_path:
return &bpf_d_path_proto;
case BPF_FUNC_get_func_arg:
- return bpf_prog_has_trampoline(prog) ? &bpf_get_func_arg_proto : NULL;
+ if (bpf_prog_has_trampoline(prog) ||
+ prog->expected_attach_type == BPF_TRACE_RAW_TP)
+ return &bpf_get_func_arg_proto;
+ return NULL;
case BPF_FUNC_get_func_ret:
return bpf_prog_has_trampoline(prog) ? &bpf_get_func_ret_proto : NULL;
case BPF_FUNC_get_func_arg_cnt:
- return bpf_prog_has_trampoline(prog) ? &bpf_get_func_arg_cnt_proto : NULL;
+ if (bpf_prog_has_trampoline(prog) ||
+ prog->expected_attach_type == BPF_TRACE_RAW_TP)
+ return &bpf_get_func_arg_cnt_proto;
+ return NULL;
case BPF_FUNC_get_attach_cookie:
if (prog->type == BPF_PROG_TYPE_TRACING &&
prog->expected_attach_type == BPF_TRACE_RAW_TP)
--
2.52.0
^ permalink raw reply related
* [PATCH bpf-next v5 2/2] selftests/bpf: test bpf_get_func_arg() for tp_btf
From: Menglong Dong @ 2026-01-21 4:43 UTC (permalink / raw)
To: ast, andrii, yonghong.song
Cc: daniel, john.fastabend, martin.lau, eddyz87, song, kpsingh, sdf,
haoluo, jolsa, mattbobrowski, rostedt, mhiramat,
mathieu.desnoyers, bpf, linux-kernel, linux-trace-kernel
In-Reply-To: <20260121044348.113201-1-dongml2@chinatelecom.cn>
Test bpf_get_func_arg() and bpf_get_func_arg_cnt() for tp_btf. The code
is most copied from test1 and test2.
Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
---
.../bpf/prog_tests/get_func_args_test.c | 3 ++
.../selftests/bpf/progs/get_func_args_test.c | 44 +++++++++++++++++++
.../bpf/test_kmods/bpf_testmod-events.h | 10 +++++
.../selftests/bpf/test_kmods/bpf_testmod.c | 4 ++
4 files changed, 61 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/get_func_args_test.c b/tools/testing/selftests/bpf/prog_tests/get_func_args_test.c
index 64a9c95d4acf..fadee95d3ae8 100644
--- a/tools/testing/selftests/bpf/prog_tests/get_func_args_test.c
+++ b/tools/testing/selftests/bpf/prog_tests/get_func_args_test.c
@@ -33,11 +33,14 @@ void test_get_func_args_test(void)
ASSERT_EQ(topts.retval >> 16, 1, "test_run");
ASSERT_EQ(topts.retval & 0xffff, 1234 + 29, "test_run");
+ ASSERT_OK(trigger_module_test_read(1), "trigger_read");
ASSERT_EQ(skel->bss->test1_result, 1, "test1_result");
ASSERT_EQ(skel->bss->test2_result, 1, "test2_result");
ASSERT_EQ(skel->bss->test3_result, 1, "test3_result");
ASSERT_EQ(skel->bss->test4_result, 1, "test4_result");
+ ASSERT_EQ(skel->bss->test5_result, 1, "test5_result");
+ ASSERT_EQ(skel->bss->test6_result, 1, "test6_result");
cleanup:
get_func_args_test__destroy(skel);
diff --git a/tools/testing/selftests/bpf/progs/get_func_args_test.c b/tools/testing/selftests/bpf/progs/get_func_args_test.c
index e0f34a55e697..5b7233afef05 100644
--- a/tools/testing/selftests/bpf/progs/get_func_args_test.c
+++ b/tools/testing/selftests/bpf/progs/get_func_args_test.c
@@ -121,3 +121,47 @@ int BPF_PROG(fexit_test, int _a, int *_b, int _ret)
test4_result &= err == 0 && ret == 1234;
return 0;
}
+
+__u64 test5_result = 0;
+SEC("tp_btf/bpf_testmod_fentry_test1_tp")
+int BPF_PROG(tp_test1)
+{
+ __u64 cnt = bpf_get_func_arg_cnt(ctx);
+ __u64 a = 0, z = 0;
+ __s64 err;
+
+ test5_result = cnt == 1;
+
+ err = bpf_get_func_arg(ctx, 0, &a);
+ test5_result &= err == 0 && ((int) a == 1);
+
+ /* not valid argument */
+ err = bpf_get_func_arg(ctx, 1, &z);
+ test5_result &= err == -EINVAL;
+
+ return 0;
+}
+
+__u64 test6_result = 0;
+SEC("tp_btf/bpf_testmod_fentry_test2_tp")
+int BPF_PROG(tp_test2)
+{
+ __u64 cnt = bpf_get_func_arg_cnt(ctx);
+ __u64 a = 0, b = 0, z = 0;
+ __s64 err;
+
+ test6_result = cnt == 2;
+
+ /* valid arguments */
+ err = bpf_get_func_arg(ctx, 0, &a);
+ test6_result &= err == 0 && (int) a == 2;
+
+ err = bpf_get_func_arg(ctx, 1, &b);
+ test6_result &= err == 0 && b == 3;
+
+ /* not valid argument */
+ err = bpf_get_func_arg(ctx, 2, &z);
+ test6_result &= err == -EINVAL;
+
+ return 0;
+}
diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod-events.h b/tools/testing/selftests/bpf/test_kmods/bpf_testmod-events.h
index aeef86b3da74..45a5e41f3a92 100644
--- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod-events.h
+++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod-events.h
@@ -63,6 +63,16 @@ BPF_TESTMOD_DECLARE_TRACE(bpf_testmod_test_writable_bare,
sizeof(struct bpf_testmod_test_writable_ctx)
);
+DECLARE_TRACE(bpf_testmod_fentry_test1,
+ TP_PROTO(int a),
+ TP_ARGS(a)
+);
+
+DECLARE_TRACE(bpf_testmod_fentry_test2,
+ TP_PROTO(int a, u64 b),
+ TP_ARGS(a, b)
+);
+
#endif /* _BPF_TESTMOD_EVENTS_H */
#undef TRACE_INCLUDE_PATH
diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
index bc07ce9d5477..f3698746f033 100644
--- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
+++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
@@ -396,11 +396,15 @@ __weak noinline struct file *bpf_testmod_return_ptr(int arg)
noinline int bpf_testmod_fentry_test1(int a)
{
+ trace_bpf_testmod_fentry_test1_tp(a);
+
return a + 1;
}
noinline int bpf_testmod_fentry_test2(int a, u64 b)
{
+ trace_bpf_testmod_fentry_test2_tp(a, b);
+
return a + b;
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 26/26] rv/rvgen: extract node marker string to class constant
From: Gabriele Monaco @ 2026-01-21 6:16 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <aW_PXmp9T4Hz25rt@fedora>
On Tue, 2026-01-20 at 15:56 -0300, Wander Lairson Costa wrote:
> I created the patches on top of linux-trace/tools/for-next. Is this the
> wrong branch?
>
Oh that tree is tricky, usually RV pull requests go to latency/for-next , that's
where you can find it this time (Steve created the specific rv/fixes and rv/for-
next but hasn't used them recently).
Anyway they're all linked to linux-next, so that's usually a safe bet.
Thanks,
Gabriele
^ permalink raw reply
* Re: [PATCH 17/26] rv/rvgen: fix possibly unbound variable in ltl2k
From: Gabriele Monaco @ 2026-01-21 6:31 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <aW_Q6ixdtMqnzfhU@fedora>
On Tue, 2026-01-20 at 16:38 -0300, Wander Lairson Costa wrote:
> On Tue, Jan 20, 2026 at 01:30:35PM +0100, Gabriele Monaco wrote:
>
> > You basically want i to be the length of the longest prefix common to at
> > least
> > another atom.
> >
> > You could assign i to some python trick doing the exact same thing the loop
> > does, like:
> >
> > i = next((i for i in range(len(atom), -1, -1)
> > if sum(a.startswith(atom[:i]) for a in atoms) > 1))
> >
> > next() is basically doing the break at the first occurrence from the
> > generator,
> > just now your i doesn't live (only) inside the loop.
> >
> > So now you save 2 lines and get any C developer scratch their head when they
> > look at the code, but hey, pyright is happy!
> >
>
> Or just leave the assignment.
>
> > If you do find the trick with next() readable or have any better idea, feel
> > free
> > to try though.
> >
>
> Definitely the next() trick is not worth to make pyright happy.
Alright, thinking on this again next() is the python way to do if(...) break ,
it looked a bit odd to me only because I didn't know about it, but if you're
using python iterators, it kinda makes sense.
Anyway I'm fine also with the dull assignment, there's no need to argue on this.
Thanks,
Gabriele
>
> > Thanks,
> > Gabriele
> >
> > > I will modify it in v2.
> > >
> > > >
> > > > Thanks,
> > > > Gabriele
> > > >
> > > > [1] - https://github.com/microsoft/pyright/issues/844
> > > >
> > > > >
> > > > > Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> > > > > ---
> > > > > tools/verification/rvgen/rvgen/ltl2k.py | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/tools/verification/rvgen/rvgen/ltl2k.py
> > > > > b/tools/verification/rvgen/rvgen/ltl2k.py
> > > > > index fa9ea6d597095..94dc64af1716d 100644
> > > > > --- a/tools/verification/rvgen/rvgen/ltl2k.py
> > > > > +++ b/tools/verification/rvgen/rvgen/ltl2k.py
> > > > > @@ -45,6 +45,7 @@ def abbreviate_atoms(atoms: list[str]) -> list[str]:
> > > > >
> > > > > abbrs = []
> > > > > for atom in atoms:
> > > > > + i = 0
> > > > > for i in range(len(atom), -1, -1):
> > > > > if sum(a.startswith(atom[:i]) for a in atoms) > 1:
> > > > > break
> > > >
> >
^ permalink raw reply
* Re: [PATCH 1/2] rtla/timerlat: Add --stack-format option
From: Wander Lairson Costa @ 2026-01-21 12:39 UTC (permalink / raw)
To: Tomas Glozar
Cc: Steven Rostedt, Costa Shulyupin, Crystal Wood, John Kacur,
Luis Goncalves, LKML, Linux Trace Kernel
In-Reply-To: <20260119115222.744150-1-tglozar@redhat.com>
On Mon, Jan 19, 2026 at 8:53 AM Tomas Glozar <tglozar@redhat.com> wrote:
>
> In the current implementation, the auto-analysis code for printing the
> stack captured in the tracefs buffer of the aa instance stops at the
> first encountered address that cannot be resolved into a function
> symbol.
>
> This is not always the desired behavior on all platforms; sometimes,
> there might be resolvable entries after unresolvable ones, and
> sometimes, the user might want to inspect the raw pointers for the
> unresolvable entries.
>
> Add a new option, --stack-format, with three values:
>
> - truncate: stop at first unresolvable entry. This is the current
> behavior, and is kept as the default.
> - skip: skip unresolvable entries, but do not stop on them.
> - full: print all entries, including unresolvable ones.
>
> To make this work, the "size" field of the stack entry is now also read
> and used as the maximum number of entries to print, capped at 64, since
> that is the fixed length of the "caller" field.
>
[...]
> +int parse_stack_format(char *arg)
> +{
For the sake of function interface, it would be better to
parse_stack_format() return enum stack_format...
> + if (!strcmp(arg, "truncate"))
> + return STACK_FORMAT_TRUNCATE;
> + if (!strcmp(arg, "skip"))
> + return STACK_FORMAT_SKIP;
> + if (!strcmp(arg, "full"))
> + return STACK_FORMAT_FULL;
> +
> + debug_msg("Error parsing the stack format %s\n", arg);
> + return -1;
... and add a new entry to the enum STACK_FORMAT_INVALID = -1...
> +}
> +
> /*
> * parse_duration - parse duration with s/m/h/d suffix converting it to seconds
> */
> diff --git a/tools/tracing/rtla/src/utils.h b/tools/tracing/rtla/src/utils.h
> index f7c2a52a0ab5..80d5ec0cf934 100644
> --- a/tools/tracing/rtla/src/utils.h
> +++ b/tools/tracing/rtla/src/utils.h
> @@ -62,8 +62,15 @@ struct sched_attr {
> };
> #endif /* SCHED_ATTR_SIZE_VER0 */
>
> +enum stack_format {
> + STACK_FORMAT_TRUNCATE,
> + STACK_FORMAT_SKIP,
> + STACK_FORMAT_FULL
... here
[...]
^ permalink raw reply
* Re: [PATCH 2/2] Documentation/rtla: Document --stack-format option
From: Wander Lairson Costa @ 2026-01-21 12:41 UTC (permalink / raw)
To: Tomas Glozar
Cc: Steven Rostedt, Costa Shulyupin, Crystal Wood, John Kacur,
Luis Goncalves, LKML, Linux Trace Kernel
In-Reply-To: <20260119115222.744150-2-tglozar@redhat.com>
On Mon, Jan 19, 2026 at 8:53 AM Tomas Glozar <tglozar@redhat.com> wrote:
>
[...]
> +
> +**--stack-format** *format*
> +
> + Adjust the format of the stack trace printed during auto-analysis.
> +
> + The supported values for *format* are:
> +
> + * **truncate** Print the stack trace up to the first unknown address (default).
> + * **skip** Skip unknown addresses.
> + * **full** Print the entire stack trace, including unknown addresses.
> +
> + For unknown addresses, the raw pointer is printed.
> --
> 2.52.0
>
Reviewed-by: Wander Lairson Costa <wander@redhat.com>
^ permalink raw reply
* Re: [PATCH 09/26] rv/rvgen: replace inline NotImplemented with decorator
From: Gabriele Monaco @ 2026-01-21 13:43 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <20260119205601.105821-10-wander@redhat.com>
On Mon, 2026-01-19 at 17:45 -0300, Wander Lairson Costa wrote:
>
[...]
> + @not_implemented
> + def fill_tracepoint_detach_helper(self): ...
[...]
> + @not_implemented
> def normalize(self):
> - raise NotImplementedError
> + ...
Is there a reason why you didn't collapse it all on the same line here (like you
did above)?
@not_implemented
def normalize(self): ...
I see it's probably better to break the line if there is a type annotation
making the line longer. Did you keep it separated because you will add
annotation in a separate patch?
Anyway this is minor and the change is good, thanks.
Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
> diff --git a/tools/verification/rvgen/rvgen/utils.py
> b/tools/verification/rvgen/rvgen/utils.py
> new file mode 100644
> index 0000000000000..e09c943693edf
> --- /dev/null
> +++ b/tools/verification/rvgen/rvgen/utils.py
> @@ -0,0 +1,36 @@
> +#!/usr/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +
> +def not_implemented(func):
> + """
> + Decorator to mark functions as not yet implemented.
> +
> + This decorator wraps a function and raises a NotImplementedError when the
> + function is called, rather than executing the function body. This is
> useful
> + for defining interface methods or placeholder functions that need to be
> + implemented later.
> +
> + Args:
> + func: The function to be wrapped.
> +
> + Returns:
> + A wrapper function that raises NotImplementedError when called.
> +
> + Raises:
> + NotImplementedError: Always raised when the decorated function is
> called.
> + The exception includes the function name and any arguments that
> were
> + passed to the function.
> +
> + Example:
> + @not_implemented
> + def future_feature(arg1, arg2):
> + pass
> +
> + # Calling future_feature will raise:
> + # NotImplementedError('future_feature', arg1_value, arg2_value)
> + """
> + def inner(*args, **kwargs):
> + raise NotImplementedError(func.__name__, *args, **kwargs)
> +
> + return inner
^ permalink raw reply
* Re: [PATCH 18/26] rv/rvgen: add fill_tracepoint_args_skel stub to ltl2k
From: Gabriele Monaco @ 2026-01-21 13:57 UTC (permalink / raw)
To: Wander Lairson Costa, Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <20260119205601.105821-19-wander@redhat.com>
On Mon, 2026-01-19 at 17:45 -0300, Wander Lairson Costa wrote:
> The ltl2k class inherits from Monitor which requires subclasses to
> implement fill_tracepoint_args_skel(). However, the ltl2k template
> uses hardcoded tracepoint arguments rather than the placeholders that
> this method would fill. The base class fill_trace_h() method calls
> fill_tracepoint_args_skel() unconditionally, which was exposed when
> the @not_implemented decorator was introduced.
>
> Add a stub implementation that returns an empty string. Since the
> ltl2k trace.h template does not contain the placeholder strings that
> would be replaced, the empty return value has no effect on the
> generated output while satisfying the base class interface contract.
>
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Mmh, this is a bit fishy though.
We the patch using the decorator seems fine, but highlights how this method
isn't meant to be in Monitor if not all monitors use it..
Adding a stub here is just sweeping dust under the carpet.
Here should probably keep the common part of fill_trace_h() in Monitor (e.g.
replacing MODEL_NAME and other common things) and create specific
implementations in dot2k and ltl2k for what is not common while calling the
super() counterpart for the rest.
Does it make sense to you?
Thanks,
Gabriele
> ---
> tools/verification/rvgen/rvgen/ltl2k.py | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/verification/rvgen/rvgen/ltl2k.py
> b/tools/verification/rvgen/rvgen/ltl2k.py
> index 94dc64af1716d..f1eafc16c754b 100644
> --- a/tools/verification/rvgen/rvgen/ltl2k.py
> +++ b/tools/verification/rvgen/rvgen/ltl2k.py
> @@ -257,6 +257,9 @@ class ltl2k(generator.Monitor):
>
> return '\n'.join(buf)
>
> + def fill_tracepoint_args_skel(self, tp_type) -> str:
> + return ""
> +
> def fill_monitor_class_type(self):
> return "LTL_MON_EVENTS_ID"
>
^ permalink raw reply
* Re: [PATCH 19/26] rv/rvgen: add abstract method stubs to Container class
From: Gabriele Monaco @ 2026-01-21 13:59 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <20260119205601.105821-20-wander@redhat.com>
On Mon, 2026-01-19 at 17:45 -0300, Wander Lairson Costa wrote:
> The Container class extends RVGenerator but was missing implementations
> for several abstract methods decorated with @not_implemented in the base
> class. This could lead to NotImplementedError exceptions if code paths
> attempt to call these methods on Container instances.
>
> Add empty-string returning stub implementations for
> fill_tracepoint_handlers_skel,
> fill_tracepoint_attach_probe, fill_tracepoint_detach_helper, and
> fill_monitor_class_type. These empty returns are semantically correct
> since Container is a grouping mechanism for organizing monitors, not an
> actual monitor that generates tracepoint-specific C code.
>
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> ---
Just like the previous patch, the NotImplementedError here highlights a weakness
in the design we should improve instead of cover.
If all those fillers don't make sense for containers, we should instead move
them to Monitor and leave RVGenerator alone.
Thanks,
Gabriele
> tools/verification/rvgen/rvgen/container.py | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/tools/verification/rvgen/rvgen/container.py
> b/tools/verification/rvgen/rvgen/container.py
> index 51f188530b4dd..65df21dfd17b2 100644
> --- a/tools/verification/rvgen/rvgen/container.py
> +++ b/tools/verification/rvgen/rvgen/container.py
> @@ -30,3 +30,15 @@ class Container(generator.RVGenerator):
> self._kconfig_marker(), container_marker)
> return result
> return result + container_marker
> +
> + def fill_tracepoint_handlers_skel(self) -> str:
> + return ""
> +
> + def fill_tracepoint_attach_probe(self) -> str:
> + return ""
> +
> + def fill_tracepoint_detach_helper(self) -> str:
> + return ""
> +
> + def fill_monitor_class_type(self) -> str:
> + return ""
^ permalink raw reply
* [PATCH] tracing: Disable trace_printk buffer on warning too
From: Steven Rostedt @ 2026-01-21 14:38 UTC (permalink / raw)
To: LKML, Linux Trace Kernel
Cc: Masami Hiramatsu, Mathieu Desnoyers, Mark Rutland
From: Steven Rostedt <rostedt@goodmis.org>
When /proc/sys/kernel/traceoff_on_warning is set to 1, the top level
tracing buffer is disabled when a warning happens. This is very useful
when debugging and want the tracing buffer to stop taking new data when a
warning triggers keeping the events that lead up to the warning from being
overwritten.
Now that there is also a persistent ring buffer and an option to have
trace_printk go to that buffer, the same holds true for that buffer. A
warning could happen just before a crash but still write enough events to
lose the events that lead up to the first warning that was the reason for
the crash.
When /proc/sys/kernel/traceoff_on_warning is set to 1 and a warning is
triggered, not only disable the top level tracing buffer, but also disable
the buffer that trace_printk()s are written to.
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/trace.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index baec63134ab6..1be88395421c 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1666,9 +1666,18 @@ EXPORT_SYMBOL_GPL(tracing_off);
void disable_trace_on_warning(void)
{
if (__disable_trace_on_warning) {
+ struct trace_array *tr = READ_ONCE(printk_trace);
+
trace_array_printk_buf(global_trace.array_buffer.buffer, _THIS_IP_,
"Disabling tracing due to warning\n");
tracing_off();
+
+ /* Disable trace_printk() buffer too */
+ if (tr != &global_trace) {
+ trace_array_printk_buf(tr->array_buffer.buffer, _THIS_IP_,
+ "Disabling tracing due to warning\n");
+ tracer_tracing_off(tr);
+ }
}
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] scripts/tracepoint-update: fix memory leak in make_trace_array()
From: Steven Rostedt @ 2026-01-21 14:41 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Weigang He, Mathieu Desnoyers, linux-kernel, linux-trace-kernel,
Tuo Li
In-Reply-To: <20260121113035.20f1f464c5f416998d577784@kernel.org>
On Wed, 21 Jan 2026 11:30:35 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > It would make much more sense to have add_string() free vals, and set
> > vals to NULL on error.
>
> I think it should be failed if it fails to add string. Can it
> continue checking tracepoints even after the error?
This patch is simply fixing a memory leak on failure (which isn't really a
big deal since this is just a user space tool that runs for a short time
during build). Returning a failure here is out of scope of this patch.
Feel free to send an RFC patch that returns a failure built on top of this
patch, and we can discuss if that should be done or not for that change.
-- Steve
^ permalink raw reply
* Re: [PATCH v5 0/6] Unload linux/kernel.h
From: Steven Rostedt @ 2026-01-21 14:53 UTC (permalink / raw)
To: Yury Norov, Andrew Morton
Cc: Andy Shevchenko, Masami Hiramatsu, Mathieu Desnoyers,
Christophe Leroy, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Joel Fernandes, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel,
Yury Norov (NVIDIA)
In-Reply-To: <aWpwHbrvQ2MMGgH-@yury>
On Fri, 16 Jan 2026 12:06:37 -0500
Yury Norov <ynorov@nvidia.com> wrote:
> > Thanks! Which tree should it go through?
>
> Andrew or Steven maybe? As a last resort, I can move it myself.
I think it makes the most sense for Andrew to take it.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH bpf-next v5 0/2] bpf: support bpf_get_func_arg() for BPF_TRACE_RAW_TP
From: patchwork-bot+netdevbpf @ 2026-01-21 17:40 UTC (permalink / raw)
To: Menglong Dong
Cc: ast, andrii, yonghong.song, daniel, john.fastabend, martin.lau,
eddyz87, song, kpsingh, sdf, haoluo, jolsa, mattbobrowski,
rostedt, mhiramat, mathieu.desnoyers, bpf, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260121044348.113201-1-dongml2@chinatelecom.cn>
Hello:
This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Wed, 21 Jan 2026 12:43:46 +0800 you wrote:
> Support bpf_get_func_arg() for BPF_TRACE_RAW_TP by getting the function
> argument count from "prog->aux->attach_func_proto" during verifier inline.
>
> Changes v5 -> v4:
> * some format adjustment in the 1st patch
> * v4: https://lore.kernel.org/bpf/20260120073046.324342-1-dongml2@chinatelecom.cn/
>
> [...]
Here is the summary with links:
- [bpf-next,v5,1/2] bpf: support bpf_get_func_arg() for BPF_TRACE_RAW_TP
https://git.kernel.org/bpf/bpf-next/c/85c7f9147147
- [bpf-next,v5,2/2] selftests/bpf: test bpf_get_func_arg() for tp_btf
https://git.kernel.org/bpf/bpf-next/c/1ed797764315
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 09/26] rv/rvgen: replace inline NotImplemented with decorator
From: Wander Lairson Costa @ 2026-01-21 17:49 UTC (permalink / raw)
To: Gabriele Monaco
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <123046455f123d9964970dd8fcf87f2c0b780fda.camel@redhat.com>
On Wed, Jan 21, 2026 at 02:43:59PM +0100, Gabriele Monaco wrote:
> On Mon, 2026-01-19 at 17:45 -0300, Wander Lairson Costa wrote:
> >
> [...]
> > + @not_implemented
> > + def fill_tracepoint_detach_helper(self): ...
> [...]
> > + @not_implemented
> > def normalize(self):
> > - raise NotImplementedError
> > + ...
>
> Is there a reason why you didn't collapse it all on the same line here (like you
> did above)?
>
> @not_implemented
> def normalize(self): ...
>
> I see it's probably better to break the line if there is a type annotation
> making the line longer. Did you keep it separated because you will add
> annotation in a separate patch?
>
I did review the commit before sending to make this coeherent among the
changes. This might be have scaped my review.
> Anyway this is minor and the change is good, thanks.
>
> Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
>
> > diff --git a/tools/verification/rvgen/rvgen/utils.py
> > b/tools/verification/rvgen/rvgen/utils.py
> > new file mode 100644
> > index 0000000000000..e09c943693edf
> > --- /dev/null
> > +++ b/tools/verification/rvgen/rvgen/utils.py
> > @@ -0,0 +1,36 @@
> > +#!/usr/bin/env python3
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +
> > +
> > +def not_implemented(func):
> > + """
> > + Decorator to mark functions as not yet implemented.
> > +
> > + This decorator wraps a function and raises a NotImplementedError when the
> > + function is called, rather than executing the function body. This is
> > useful
> > + for defining interface methods or placeholder functions that need to be
> > + implemented later.
> > +
> > + Args:
> > + func: The function to be wrapped.
> > +
> > + Returns:
> > + A wrapper function that raises NotImplementedError when called.
> > +
> > + Raises:
> > + NotImplementedError: Always raised when the decorated function is
> > called.
> > + The exception includes the function name and any arguments that
> > were
> > + passed to the function.
> > +
> > + Example:
> > + @not_implemented
> > + def future_feature(arg1, arg2):
> > + pass
> > +
> > + # Calling future_feature will raise:
> > + # NotImplementedError('future_feature', arg1_value, arg2_value)
> > + """
> > + def inner(*args, **kwargs):
> > + raise NotImplementedError(func.__name__, *args, **kwargs)
> > +
> > + return inner
>
^ permalink raw reply
* Re: [PATCH 18/26] rv/rvgen: add fill_tracepoint_args_skel stub to ltl2k
From: Wander Lairson Costa @ 2026-01-21 17:53 UTC (permalink / raw)
To: Gabriele Monaco
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <1f168ff5ffb531570fd83e3f398380e8df053275.camel@redhat.com>
On Wed, Jan 21, 2026 at 02:57:02PM +0100, Gabriele Monaco wrote:
> On Mon, 2026-01-19 at 17:45 -0300, Wander Lairson Costa wrote:
> > The ltl2k class inherits from Monitor which requires subclasses to
> > implement fill_tracepoint_args_skel(). However, the ltl2k template
> > uses hardcoded tracepoint arguments rather than the placeholders that
> > this method would fill. The base class fill_trace_h() method calls
> > fill_tracepoint_args_skel() unconditionally, which was exposed when
> > the @not_implemented decorator was introduced.
> >
> > Add a stub implementation that returns an empty string. Since the
> > ltl2k trace.h template does not contain the placeholder strings that
> > would be replaced, the empty return value has no effect on the
> > generated output while satisfying the base class interface contract.
> >
> > Signed-off-by: Wander Lairson Costa <wander@redhat.com>
>
> Mmh, this is a bit fishy though.
> We the patch using the decorator seems fine, but highlights how this method
> isn't meant to be in Monitor if not all monitors use it..
> Adding a stub here is just sweeping dust under the carpet.
>
> Here should probably keep the common part of fill_trace_h() in Monitor (e.g.
> replacing MODEL_NAME and other common things) and create specific
> implementations in dot2k and ltl2k for what is not common while calling the
> super() counterpart for the rest.
>
> Does it make sense to you?
>
Yes, that is exactly my idea. Since the patch series were getting too
long and my brain too rot, I thought would be better addressing this in
a following up patch series. But I can work in the next version if you
are not ok with that approach.
> Thanks,
> Gabriele
>
> > ---
> > tools/verification/rvgen/rvgen/ltl2k.py | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/tools/verification/rvgen/rvgen/ltl2k.py
> > b/tools/verification/rvgen/rvgen/ltl2k.py
> > index 94dc64af1716d..f1eafc16c754b 100644
> > --- a/tools/verification/rvgen/rvgen/ltl2k.py
> > +++ b/tools/verification/rvgen/rvgen/ltl2k.py
> > @@ -257,6 +257,9 @@ class ltl2k(generator.Monitor):
> >
> > return '\n'.join(buf)
> >
> > + def fill_tracepoint_args_skel(self, tp_type) -> str:
> > + return ""
> > +
> > def fill_monitor_class_type(self):
> > return "LTL_MON_EVENTS_ID"
> >
>
^ permalink raw reply
* Re: [PATCH 19/26] rv/rvgen: add abstract method stubs to Container class
From: Wander Lairson Costa @ 2026-01-21 17:56 UTC (permalink / raw)
To: Gabriele Monaco
Cc: Steven Rostedt, Nam Cao, open list,
open list:RUNTIME VERIFICATION (RV)
In-Reply-To: <69298b5dcfda02051c5c1fe995efc333f980664f.camel@redhat.com>
On Wed, Jan 21, 2026 at 02:59:09PM +0100, Gabriele Monaco wrote:
> On Mon, 2026-01-19 at 17:45 -0300, Wander Lairson Costa wrote:
> > The Container class extends RVGenerator but was missing implementations
> > for several abstract methods decorated with @not_implemented in the base
> > class. This could lead to NotImplementedError exceptions if code paths
> > attempt to call these methods on Container instances.
> >
> > Add empty-string returning stub implementations for
> > fill_tracepoint_handlers_skel,
> > fill_tracepoint_attach_probe, fill_tracepoint_detach_helper, and
> > fill_monitor_class_type. These empty returns are semantically correct
> > since Container is a grouping mechanism for organizing monitors, not an
> > actual monitor that generates tracepoint-specific C code.
> >
> > Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> > ---
>
> Just like the previous patch, the NotImplementedError here highlights a weakness
> in the design we should improve instead of cover.
> If all those fillers don't make sense for containers, we should instead move
> them to Monitor and leave RVGenerator alone.
>
Yes, I agree. The design has a separate of concerns problem. The
previous comment apply here as well.
> Thanks,
> Gabriele
>
> > tools/verification/rvgen/rvgen/container.py | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/tools/verification/rvgen/rvgen/container.py
> > b/tools/verification/rvgen/rvgen/container.py
> > index 51f188530b4dd..65df21dfd17b2 100644
> > --- a/tools/verification/rvgen/rvgen/container.py
> > +++ b/tools/verification/rvgen/rvgen/container.py
> > @@ -30,3 +30,15 @@ class Container(generator.RVGenerator):
> > self._kconfig_marker(), container_marker)
> > return result
> > return result + container_marker
> > +
> > + def fill_tracepoint_handlers_skel(self) -> str:
> > + return ""
> > +
> > + def fill_tracepoint_attach_probe(self) -> str:
> > + return ""
> > +
> > + def fill_tracepoint_detach_helper(self) -> str:
> > + return ""
> > +
> > + def fill_monitor_class_type(self) -> str:
> > + return ""
>
^ permalink raw reply
* Re: iommu: Fix NULL pointer deref when io_page_fault tracepoint fires
From: Steven Rostedt @ 2026-01-21 21:26 UTC (permalink / raw)
To: Daniel Thompson
Cc: Markus Elfring, linux-trace-kernel, linux-arm-kernel,
Masami Hiramatsu, Mathieu Desnoyers, LKML, Robin Murphy,
Will Deacon
In-Reply-To: <aW5YnTnOJ2dJNuhq@aspen.lan>
On Mon, 19 Jan 2026 16:15:25 +0000
Daniel Thompson <daniel@riscstar.com> wrote:
> I dislike the proposed new summary. I think keeping "io_page_fault"
> in the summary is a much better use of characters than spelling
> dereference in full.
Agreed. You may safely ignore the comments outside of adding a "Fixes" tag.
That probably should be done.
As for your patch:
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* [PATCH v4 0/3] PCI Controller event and LTSSM tracepoint support
From: Shawn Lin @ 2026-01-22 2:02 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bjorn Helgaas
Cc: linux-rockchip, linux-pci, linux-trace-kernel, linux-doc,
Steven Rostedt, Masami Hiramatsu, Shawn Lin
This patch-set adds new pci controller event and LTSSM tracepoint used by host drivers
which provide LTSSM trace functionality. The first user is pcie-dw-rockchip with a 256
Bytes FIFO for recording LTSSM transition.
Testing
=========
This series was tested on RK3588/RK3588s EVB1 with NVMe SSD connected to PCIe3 and PCIe2
root ports.
echo 1 > /sys/kernel/debug/tracing/events/pci_controller/pcie_ltssm_state_transition/enable
cat /sys/kernel/debug/tracing/trace_pipe
# tracer: nop
#
# entries-in-buffer/entries-written: 64/64 #P:8
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
kworker/0:0-9 [000] ..... 5.600194: pcie_ltssm_state_transition: dev: a40000000.pcie state: DETECT_ACT rate: Unknown
kworker/0:0-9 [000] ..... 5.600198: pcie_ltssm_state_transition: dev: a40000000.pcie state: DETECT_WAIT rate: Unknown
kworker/0:0-9 [000] ..... 5.600199: pcie_ltssm_state_transition: dev: a40000000.pcie state: DETECT_ACT rate: Unknown
kworker/0:0-9 [000] ..... 5.600201: pcie_ltssm_state_transition: dev: a40000000.pcie state: POLL_ACTIVE rate: Unknown
kworker/0:0-9 [000] ..... 5.600202: pcie_ltssm_state_transition: dev: a40000000.pcie state: POLL_CONFIG rate: Unknown
kworker/0:0-9 [000] ..... 5.600204: pcie_ltssm_state_transition: dev: a40000000.pcie state: CFG_LINKWD_START rate: Unknown
kworker/0:0-9 [000] ..... 5.600206: pcie_ltssm_state_transition: dev: a40000000.pcie state: CFG_LINKWD_ACEPT rate: Unknown
kworker/0:0-9 [000] ..... 5.600207: pcie_ltssm_state_transition: dev: a40000000.pcie state: CFG_LANENUM_WAI rate: Unknown
kworker/0:0-9 [000] ..... 5.600208: pcie_ltssm_state_transition: dev: a40000000.pcie state: CFG_LANENUM_ACEPT rate: Unknown
kworker/0:0-9 [000] ..... 5.600210: pcie_ltssm_state_transition: dev: a40000000.pcie state: CFG_COMPLETE rate: Unknown
kworker/0:0-9 [000] ..... 5.600212: pcie_ltssm_state_transition: dev: a40000000.pcie state: CFG_IDLE rate: Unknown
kworker/0:0-9 [000] ..... 5.600213: pcie_ltssm_state_transition: dev: a40000000.pcie state: L0 rate: 2.5 GT/s
kworker/0:0-9 [000] ..... 5.600214: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_LOCK rate: Unknown
kworker/0:0-9 [000] ..... 5.600216: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_RCVRCFG rate: Unknown
kworker/0:0-9 [000] ..... 5.600217: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_SPEED rate: Unknown
kworker/0:0-9 [000] ..... 5.600218: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_LOCK rate: Unknown
kworker/0:0-9 [000] ..... 5.600220: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_EQ1 rate: Unknown
kworker/0:0-9 [000] ..... 5.600221: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_EQ2 rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600222: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_EQ3 rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600224: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_LOCK rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600225: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_RCVRCFG rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600226: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_IDLE rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600227: pcie_ltssm_state_transition: dev: a40000000.pcie state: L0 rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600228: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_LOCK rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600229: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_RCVRCFG rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600231: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_IDLE rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600232: pcie_ltssm_state_transition: dev: a40000000.pcie state: L0 rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600233: pcie_ltssm_state_transition: dev: a40000000.pcie state: L123_SEND_EIDLE rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600234: pcie_ltssm_state_transition: dev: a40000000.pcie state: L1_IDLE rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600236: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_LOCK rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600237: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_RCVRCFG rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600238: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_IDLE rate: 8.0 GT/s
kworker/0:0-9 [000] ..... 5.600239: pcie_ltssm_state_transition: dev: a40000000.pcie state: L0 rate: 8.0 GT/s
Changes in v4:
- use TRACE_EVENT_FN to notify when to start and stop the tracepoint,
and export pci_ltssm_tp_enabled() for host drivers to use
- skip trace if pci_ltssm_tp_enabled() is false.(Steven)
- wrap into 80 columns(Bjorn)
Changes in v3:
- add TRACE_DEFINE_ENUM for all enums(Steven Rostedt)
- Add toctree entry in Documentation/trace/index.rst(Bagas Sanjaya)
- fix mismatch section underline length(Bagas Sanjaya)
- Make example snippets in code block(Bagas Sanjaya)
- warp context into 80 columns and fix the file name(Bjorn)
- reorder variables(Mani)
- rename loop to i; rename en to enable(Mani)
- use FIELD_GET(Mani)
- add comment about how the FIFO works(Mani)
Changes in v2:
- use tracepoint
Shawn Lin (3):
PCI: trace: Add PCI controller LTSSM transition tracepoint
Documentation: tracing: Add PCI controller event documentation
PCI: dw-rockchip: Add pcie_ltssm_state_transition trace support
Documentation/trace/events-pci-controller.rst | 42 ++++++++++
Documentation/trace/index.rst | 1 +
drivers/pci/controller/dwc/pcie-dw-rockchip.c | 111 ++++++++++++++++++++++++++
drivers/pci/trace.c | 20 +++++
include/linux/pci.h | 4 +
include/trace/events/pci_controller.h | 57 +++++++++++++
6 files changed, 235 insertions(+)
create mode 100644 Documentation/trace/events-pci-controller.rst
create mode 100644 include/trace/events/pci_controller.h
--
2.7.4
^ 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