* FAILED: Patch "function_graph: Restore direct mode when callbacks drop to one" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, hu.shengming; +Cc: Steven Rostedt (Google), linux-trace-kernel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 53b2fae90ff01fede6520ca744ed5e8e366497ba Mon Sep 17 00:00:00 2001
From: Shengming Hu <hu.shengming@zte.com.cn>
Date: Fri, 13 Feb 2026 14:29:32 +0800
Subject: [PATCH] function_graph: Restore direct mode when callbacks drop to
one
When registering a second fgraph callback, direct path is disabled and
array loop is used instead. When ftrace_graph_active falls back to one,
we try to re-enable direct mode via ftrace_graph_enable_direct(true, ...).
But ftrace_graph_enable_direct() incorrectly disables the static key
rather than enabling it. This leaves fgraph_do_direct permanently off
after first multi-callback transition, so direct fast mode is never
restored.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260213142932519cuWSpEXeS4-UnCvNXnK2P@zte.com.cn
Fixes: cc60ee813b503 ("function_graph: Use static_call and branch to optimize entry function")
Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/fgraph.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
index cc48d16be43e0..4df766c690f92 100644
--- a/kernel/trace/fgraph.c
+++ b/kernel/trace/fgraph.c
@@ -1303,7 +1303,7 @@ static void ftrace_graph_enable_direct(bool enable_branch, struct fgraph_ops *go
static_call_update(fgraph_func, func);
static_call_update(fgraph_retfunc, retfunc);
if (enable_branch)
- static_branch_disable(&fgraph_do_direct);
+ static_branch_enable(&fgraph_do_direct);
}
static void ftrace_graph_disable_direct(bool disable_branch)
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "tracing: Fix to set write permission to per-cpu buffer_size_kb" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:28 UTC (permalink / raw)
To: stable, mhiramat
Cc: Mathieu Desnoyers, Steven Rostedt (Google), linux-trace-kernel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From f844282deed7481cf2f813933229261e27306551 Mon Sep 17 00:00:00 2001
From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Date: Tue, 10 Feb 2026 17:43:36 +0900
Subject: [PATCH] tracing: Fix to set write permission to per-cpu
buffer_size_kb
Since the per-cpu buffer_size_kb file is writable for changing
per-cpu ring buffer size, the file should have the write access
permission.
Cc: stable@vger.kernel.org
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://patch.msgid.link/177071301597.2293046.11683339475076917920.stgit@mhiramat.tok.corp.google.com
Fixes: 21ccc9cd7211 ("tracing: Disable "other" permission bits in the tracefs files")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 845b8a165daf3..fd470675809b3 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -8613,7 +8613,7 @@ tracing_init_tracefs_percpu(struct trace_array *tr, long cpu)
trace_create_cpu_file("stats", TRACE_MODE_READ, d_cpu,
tr, cpu, &tracing_stats_fops);
- trace_create_cpu_file("buffer_size_kb", TRACE_MODE_READ, d_cpu,
+ trace_create_cpu_file("buffer_size_kb", TRACE_MODE_WRITE, d_cpu,
tr, cpu, &tracing_entries_fops);
if (tr->range_addr_start)
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "uprobes: Fix incorrect lockdep condition in filter_chain()" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:25 UTC (permalink / raw)
To: stable, leitao
Cc: Peter Zijlstra (Intel), Oleg Nesterov, Andrii Nakryiko,
Masami Hiramatsu (Google), linux-perf-users, linux-trace-kernel
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From a56a38fd9196fc89401e498d70b7aa9c9679fa6e Mon Sep 17 00:00:00 2001
From: Breno Leitao <leitao@debian.org>
Date: Wed, 28 Jan 2026 10:16:11 -0800
Subject: [PATCH] uprobes: Fix incorrect lockdep condition in filter_chain()
The list_for_each_entry_rcu() in filter_chain() uses
rcu_read_lock_trace_held() as the lockdep condition, but the function
holds consumer_rwsem, not the RCU trace lock.
This gives me the following output when running with some locking debug
option enabled:
kernel/events/uprobes.c:1141 RCU-list traversed in non-reader section!!
filter_chain
register_for_each_vma
uprobe_unregister_nosync
__probe_event_disable
Remove the incorrect lockdep condition since the rwsem provides
sufficient protection for the list traversal.
Fixes: cc01bd044e6a ("uprobes: travers uprobe's consumer list locklessly under SRCU protection")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260128-uprobe_rcu-v2-1-994ea6d32730@debian.org
---
kernel/events/uprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index dfbce021fb027..424ef2235b07e 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1138,7 +1138,7 @@ static bool filter_chain(struct uprobe *uprobe, struct mm_struct *mm)
bool ret = false;
down_read(&uprobe->consumer_rwsem);
- list_for_each_entry_rcu(uc, &uprobe->consumers, cons_node, rcu_read_lock_trace_held()) {
+ list_for_each_entry(uc, &uprobe->consumers, cons_node) {
ret = consumer_filter(uc, mm);
if (ret)
break;
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "x86/uprobes: Fix XOL allocation failure for 32-bit tasks" failed to apply to 6.12-stable tree
From: Sasha Levin @ 2026-03-01 1:21 UTC (permalink / raw)
To: stable, oleg
Cc: Paulo Andrade, Peter Zijlstra (Intel), linux-trace-kernel,
linux-perf-users
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From d55c571e4333fac71826e8db3b9753fadfbead6a Mon Sep 17 00:00:00 2001
From: Oleg Nesterov <oleg@redhat.com>
Date: Sun, 11 Jan 2026 16:00:37 +0100
Subject: [PATCH] x86/uprobes: Fix XOL allocation failure for 32-bit tasks
This script
#!/usr/bin/bash
echo 0 > /proc/sys/kernel/randomize_va_space
echo 'void main(void) {}' > TEST.c
# -fcf-protection to ensure that the 1st endbr32 insn can't be emulated
gcc -m32 -fcf-protection=branch TEST.c -o test
bpftrace -e 'uprobe:./test:main {}' -c ./test
"hangs", the probed ./test task enters an endless loop.
The problem is that with randomize_va_space == 0
get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not
just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this addr is used
by the stack vma.
arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and
in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE.
vm_unmapped_area() happily returns the high address > TASK_SIZE and then
get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)"
check.
handle_swbp() doesn't report this failure (probably it should) and silently
restarts the probed insn. Endless loop.
I think that the right fix should change the x86 get_unmapped_area() paths
to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if
CONFIG_X86_X32_ABI=y, in_x32_syscall() falsely returns true in this case
because ->orig_ax = -1.
But we need a simple fix for -stable, so this patch just sets TS_COMPAT if
the probed task is 32-bit to make in_ia32_syscall() true.
Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()")
Reported-by: Paulo Andrade <pandrade@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com
---
arch/x86/kernel/uprobes.c | 24 ++++++++++++++++++++++++
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 10 +++++++---
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 7be8e361ca55b..619dddf54424e 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -1823,3 +1823,27 @@ bool is_uprobe_at_func_entry(struct pt_regs *regs)
return false;
}
+
+#ifdef CONFIG_IA32_EMULATION
+unsigned long arch_uprobe_get_xol_area(void)
+{
+ struct thread_info *ti = current_thread_info();
+ unsigned long vaddr;
+
+ /*
+ * HACK: we are not in a syscall, but x86 get_unmapped_area() paths
+ * ignore TIF_ADDR32 and rely on in_32bit_syscall() to calculate
+ * vm_unmapped_area_info.high_limit.
+ *
+ * The #ifdef above doesn't cover the CONFIG_X86_X32_ABI=y case,
+ * but in this case in_32bit_syscall() -> in_x32_syscall() always
+ * (falsely) returns true because ->orig_ax == -1.
+ */
+ if (test_thread_flag(TIF_ADDR32))
+ ti->status |= TS_COMPAT;
+ vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
+ ti->status &= ~TS_COMPAT;
+
+ return vaddr;
+}
+#endif
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index ee3d36eda45dd..f548fea2adec8 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -242,6 +242,7 @@ extern void arch_uprobe_clear_state(struct mm_struct *mm);
extern void arch_uprobe_init_state(struct mm_struct *mm);
extern void handle_syscall_uprobe(struct pt_regs *regs, unsigned long bp_vaddr);
extern void arch_uprobe_optimize(struct arch_uprobe *auprobe, unsigned long vaddr);
+extern unsigned long arch_uprobe_get_xol_area(void);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index a7d7d83ca1d78..dfbce021fb027 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1694,6 +1694,12 @@ static const struct vm_special_mapping xol_mapping = {
.mremap = xol_mremap,
};
+unsigned long __weak arch_uprobe_get_xol_area(void)
+{
+ /* Try to map as high as possible, this is only a hint. */
+ return get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
+}
+
/* Slot allocation for XOL */
static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
{
@@ -1709,9 +1715,7 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
}
if (!area->vaddr) {
- /* Try to map as high as possible, this is only a hint. */
- area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
- PAGE_SIZE, 0, 0);
+ area->vaddr = arch_uprobe_get_xol_area();
if (IS_ERR_VALUE(area->vaddr)) {
ret = area->vaddr;
goto fail;
--
2.51.0
^ permalink raw reply related
* FAILED: Patch "x86/uprobes: Fix XOL allocation failure for 32-bit tasks" failed to apply to 6.18-stable tree
From: Sasha Levin @ 2026-03-01 1:15 UTC (permalink / raw)
To: stable, oleg
Cc: Paulo Andrade, Peter Zijlstra (Intel), linux-trace-kernel,
linux-perf-users
The patch below does not apply to the 6.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From d55c571e4333fac71826e8db3b9753fadfbead6a Mon Sep 17 00:00:00 2001
From: Oleg Nesterov <oleg@redhat.com>
Date: Sun, 11 Jan 2026 16:00:37 +0100
Subject: [PATCH] x86/uprobes: Fix XOL allocation failure for 32-bit tasks
This script
#!/usr/bin/bash
echo 0 > /proc/sys/kernel/randomize_va_space
echo 'void main(void) {}' > TEST.c
# -fcf-protection to ensure that the 1st endbr32 insn can't be emulated
gcc -m32 -fcf-protection=branch TEST.c -o test
bpftrace -e 'uprobe:./test:main {}' -c ./test
"hangs", the probed ./test task enters an endless loop.
The problem is that with randomize_va_space == 0
get_unmapped_area(TASK_SIZE - PAGE_SIZE) called by xol_add_vma() can not
just return the "addr == TASK_SIZE - PAGE_SIZE" hint, this addr is used
by the stack vma.
arch_get_unmapped_area_topdown() doesn't take TIF_ADDR32 into account and
in_32bit_syscall() is false, this leads to info.high_limit > TASK_SIZE.
vm_unmapped_area() happily returns the high address > TASK_SIZE and then
get_unmapped_area() returns -ENOMEM after the "if (addr > TASK_SIZE - len)"
check.
handle_swbp() doesn't report this failure (probably it should) and silently
restarts the probed insn. Endless loop.
I think that the right fix should change the x86 get_unmapped_area() paths
to rely on TIF_ADDR32 rather than in_32bit_syscall(). Note also that if
CONFIG_X86_X32_ABI=y, in_x32_syscall() falsely returns true in this case
because ->orig_ax = -1.
But we need a simple fix for -stable, so this patch just sets TS_COMPAT if
the probed task is 32-bit to make in_ia32_syscall() true.
Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()")
Reported-by: Paulo Andrade <pandrade@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/aV5uldEvV7pb4RA8@redhat.com/
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/aWO7Fdxn39piQnxu@redhat.com
---
arch/x86/kernel/uprobes.c | 24 ++++++++++++++++++++++++
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 10 +++++++---
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 7be8e361ca55b..619dddf54424e 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -1823,3 +1823,27 @@ bool is_uprobe_at_func_entry(struct pt_regs *regs)
return false;
}
+
+#ifdef CONFIG_IA32_EMULATION
+unsigned long arch_uprobe_get_xol_area(void)
+{
+ struct thread_info *ti = current_thread_info();
+ unsigned long vaddr;
+
+ /*
+ * HACK: we are not in a syscall, but x86 get_unmapped_area() paths
+ * ignore TIF_ADDR32 and rely on in_32bit_syscall() to calculate
+ * vm_unmapped_area_info.high_limit.
+ *
+ * The #ifdef above doesn't cover the CONFIG_X86_X32_ABI=y case,
+ * but in this case in_32bit_syscall() -> in_x32_syscall() always
+ * (falsely) returns true because ->orig_ax == -1.
+ */
+ if (test_thread_flag(TIF_ADDR32))
+ ti->status |= TS_COMPAT;
+ vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
+ ti->status &= ~TS_COMPAT;
+
+ return vaddr;
+}
+#endif
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index ee3d36eda45dd..f548fea2adec8 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -242,6 +242,7 @@ extern void arch_uprobe_clear_state(struct mm_struct *mm);
extern void arch_uprobe_init_state(struct mm_struct *mm);
extern void handle_syscall_uprobe(struct pt_regs *regs, unsigned long bp_vaddr);
extern void arch_uprobe_optimize(struct arch_uprobe *auprobe, unsigned long vaddr);
+extern unsigned long arch_uprobe_get_xol_area(void);
#else /* !CONFIG_UPROBES */
struct uprobes_state {
};
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index a7d7d83ca1d78..dfbce021fb027 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1694,6 +1694,12 @@ static const struct vm_special_mapping xol_mapping = {
.mremap = xol_mremap,
};
+unsigned long __weak arch_uprobe_get_xol_area(void)
+{
+ /* Try to map as high as possible, this is only a hint. */
+ return get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE, PAGE_SIZE, 0, 0);
+}
+
/* Slot allocation for XOL */
static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
{
@@ -1709,9 +1715,7 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area)
}
if (!area->vaddr) {
- /* Try to map as high as possible, this is only a hint. */
- area->vaddr = get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE,
- PAGE_SIZE, 0, 0);
+ area->vaddr = arch_uprobe_get_xol_area();
if (IS_ERR_VALUE(area->vaddr)) {
ret = area->vaddr;
goto fail;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next v2 09/10] documentation: networking: add shared devlink documentation
From: Jakub Kicinski @ 2026-02-28 23:05 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-10-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:21 +0100 Jiri Pirko wrote:
> +Shared devlink instances allow multiple physical functions (PFs) on the same
> +chip to share an additional devlink instance for chip-wide operations. This
> +is implemented within individual drivers alongside the individual PF devlink
> +instances, not replacing them.
Sounds like you want to preclude what was the goal in the discussion
with Przemek you quoted - a shared instance _only_ case. We don't have
to implement it today, but I think it's an entirely sane direction.
So the docs should not state otherwise.
^ permalink raw reply
* Re: [PATCH net-next v2 08/10] devlink: introduce shared devlink instance for PFs on same chip
From: Jakub Kicinski @ 2026-02-28 23:03 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-9-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:20 +0100 Jiri Pirko wrote:
> +struct devlink_shd {
> + struct list_head list; /* Node in shd list */
> + const char *id; /* Identifier string (e.g., serial number) */
> + refcount_t refcount; /* Reference count */
> + char priv[] __aligned(NETDEV_ALIGN); /* Driver private data */
> +};
As pointed out by AI you promised a size member and a __counted_by()
annotation :)
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2 07/10] devlink: allow devlink instance allocation without a backing device
From: Jakub Kicinski @ 2026-02-28 23:01 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-8-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:19 +0100 Jiri Pirko wrote:
> - dev_warn(port->devlink->dev, "Type was not set for devlink port.");
> + if (port->devlink->dev)
> + dev_warn(port->devlink->dev,
> + "Type was not set for devlink port.");
since I'm already nit-picking - maybe we should have a helper for this
case an pr_warn() the message if dev is NULL?
^ permalink raw reply
* Re: [PATCH net-next v2 06/10] devlink: add devlink_dev_driver_name() helper and use it in trace events
From: Jakub Kicinski @ 2026-02-28 22:58 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-7-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:18 +0100 Jiri Pirko wrote:
> +const char *devlink_dev_driver_name(const struct devlink *devlink)
> +{
> + struct device *dev = devlink->dev;
> +
> + return dev ? dev->driver->name : NULL;
> +}
> +EXPORT_SYMBOL_GPL(devlink_dev_driver_name);
You say we need this in prep for shared instances, which is fair, but
shared instances should presumably share across the same driver, most
of the time? So perhaps we should do a similar thing here as you did to
the bus/dev name? Maybe when shared instance is allocated:
devlink->driver_name = kasprintf("%s+", dev->driver);
And then:
+const char *devlink_dev_driver_name(const struct devlink *devlink)
+{
+ struct device *dev = devlink->dev;
+
+ return dev ? dev->driver->name : devlink->driver_name;
+}
+EXPORT_SYMBOL_GPL(devlink_dev_driver_name);
?
^ permalink raw reply
* Re: [PATCH net-next v2 04/10] devlink: allow to use devlink index as a command handle
From: Jakub Kicinski @ 2026-02-28 22:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, pabeni, horms, donald.hunter, corbet,
skhan, saeedm, leon, tariqt, mbloch, przemyslaw.kitszel, mschmidt,
andrew+netdev, rostedt, mhiramat, mathieu.desnoyers, chuck.lever,
matttbe, cjubran, daniel.zahka, linux-doc, linux-rdma,
linux-trace-kernel
In-Reply-To: <20260225133422.290965-5-jiri@resnulli.us>
On Wed, 25 Feb 2026 14:34:16 +0100 Jiri Pirko wrote:
> + if (attrs[DEVLINK_ATTR_INDEX]) {
> + index = nla_get_uint(attrs[DEVLINK_ATTR_INDEX]);
> + devlink = devlinks_xa_lookup_get(net, index);
> + if (!devlink)
> + return ERR_PTR(-ENODEV);
> + goto found;
> + }
> +
> if (!attrs[DEVLINK_ATTR_BUS_NAME] || !attrs[DEVLINK_ATTR_DEV_NAME])
> return ERR_PTR(-EINVAL);
If both INDEX and BUS_NAME + DEV_NAME are provided we should check
that they point to the same device? Or reject user space passing both?
^ permalink raw reply
* Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: Steven Rostedt @ 2026-02-28 20:39 UTC (permalink / raw)
To: Jiri Olsa
Cc: Ihor Solodrai, Florent Revest, Mark Rutland, bpf, linux-kernel,
linux-trace-kernel, linux-arm-kernel, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu,
Kumar Kartikeya Dwivedi
In-Reply-To: <aaILlSuEgaYDq41r@krava>
On Fri, 27 Feb 2026 22:24:37 +0100
Jiri Olsa <olsajiri@gmail.com> wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 827fb9a0bf0d..e333749a5896 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
> new_filter_hash = old_filter_hash;
> }
> } else {
As this looks to fix the issue, just add:
guard(mutex)(&ftrace_lock);
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
> @@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
> ops->func_hash->filter_hash = NULL;
> }
> } else {
And here too.
As there's nothing after the comment and before the end of the block.
-- Steve
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
-- Steve
^ permalink raw reply
* Re: [PATCH v4 3/5] mm: convert compaction to zone lock wrappers
From: SeongJae Park @ 2026-02-28 16:31 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Zi Yan, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
"linux-cxl
In-Reply-To: <3a09e46f52cf9f709b0725bc2b648cc5212843b2.1772206930.git.d@ilvokhin.com>
On Fri, 27 Feb 2026 16:00:25 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> Compaction uses compact_lock_irqsave(), which currently operates
> on a raw spinlock_t pointer so it can be used for both zone->lock
> and lruvec->lru_lock. Since zone lock operations are now wrapped,
> compact_lock_irqsave() can no longer directly operate on a
> spinlock_t when the lock belongs to a zone.
>
> Split the helper into compact_zone_lock_irqsave() and
> compact_lruvec_lock_irqsave(), duplicating the small amount of
> shared logic. As there are only two call sites and both statically
> know the lock type, this avoids introducing additional abstraction
> or runtime dispatch in the compaction path.
>
> No functional change intended.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH v4 1/5] mm: introduce zone lock wrappers
From: SeongJae Park @ 2026-02-28 16:23 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Zi Yan, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
"linux-cxl
In-Reply-To: <849dee9c47df1e6fba97c9933af0d5a08b8e15d3.1772206930.git.d@ilvokhin.com>
On Fri, 27 Feb 2026 16:00:23 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> Add thin wrappers around zone lock acquire/release operations. This
> prepares the code for future tracepoint instrumentation without
> modifying individual call sites.
>
> Centralizing zone lock operations behind wrappers allows future
> instrumentation or debugging hooks to be added without touching
> all users.
>
> No functional change intended. The wrappers are introduced in
> preparation for subsequent patches and are not yet used.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close
From: Qing Wang @ 2026-02-28 8:59 UTC (permalink / raw)
To: vdonnefort
Cc: linux-kernel, linux-trace-kernel, mathieu.desnoyers, mhiramat,
rostedt, syzbot+3b5dd2030fe08afdf65d, wangqing7171
In-Reply-To: <aaF-bhAIhCgusG9k@google.com>
On Fri, 27 Feb 2026 at 19:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> As we are applying restrictive rules for this mapping, I believe setting VM_IO
> might be a better fix.
Restrictive rules for this mapping is a better idea, I agreed with it.
--
Qing
^ permalink raw reply
* Re: [PATCH v4 4/5] mm: rename zone->lock to zone->_lock
From: Zi Yan @ 2026-02-28 1:17 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
SeongJae Park
In-Reply-To: <d61500c5784c64e971f4d328c57639303c475f81.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> This intentionally breaks direct users of zone->lock at compile time so
> all call sites are converted to the zone lock wrappers. Without the
> rename, present and future out-of-tree code could continue using
> spin_lock(&zone->lock) and bypass the wrappers and tracing
> infrastructure.
>
> No functional change intended.
>
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Acked-by: SeongJae Park <sj@kernel.org>
> ---
> include/linux/mmzone.h | 7 +++++--
> include/linux/mmzone_lock.h | 12 ++++++------
> mm/compaction.c | 4 ++--
> mm/internal.h | 2 +-
> mm/page_alloc.c | 16 ++++++++--------
> mm/page_isolation.c | 4 ++--
> mm/page_owner.c | 2 +-
> 7 files changed, 25 insertions(+), 22 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v4 3/5] mm: convert compaction to zone lock wrappers
From: Zi Yan @ 2026-02-28 1:16 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm
In-Reply-To: <3a09e46f52cf9f709b0725bc2b648cc5212843b2.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> Compaction uses compact_lock_irqsave(), which currently operates
> on a raw spinlock_t pointer so it can be used for both zone->lock
> and lruvec->lru_lock. Since zone lock operations are now wrapped,
> compact_lock_irqsave() can no longer directly operate on a
> spinlock_t when the lock belongs to a zone.
>
> Split the helper into compact_zone_lock_irqsave() and
> compact_lruvec_lock_irqsave(), duplicating the small amount of
> shared logic. As there are only two call sites and both statically
> know the lock type, this avoids introducing additional abstraction
> or runtime dispatch in the compaction path.
>
> No functional change intended.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> ---
> mm/compaction.c | 33 ++++++++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v4 2/5] mm: convert zone lock users to wrappers
From: Zi Yan @ 2026-02-28 1:14 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm,
SeongJae Park
In-Reply-To: <d26a43ebed2f0f1edb9cfe4fbed16dd31c7a069c.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> Replace direct zone lock acquire/release operations with the
> newly introduced wrappers.
>
> The changes are purely mechanical substitutions. No functional change
> intended. Locking semantics and ordering remain unchanged.
>
> The compaction path is left unchanged for now and will be
> handled separately in the following patch due to additional
> non-trivial modifications.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> ---
> kernel/power/snapshot.c | 5 +--
> mm/compaction.c | 25 +++++++-------
> mm/memory_hotplug.c | 9 ++---
> mm/mm_init.c | 3 +-
> mm/page_alloc.c | 73 +++++++++++++++++++++--------------------
> mm/page_isolation.c | 19 ++++++-----
> mm/page_reporting.c | 13 ++++----
> mm/show_mem.c | 5 +--
> mm/shuffle.c | 9 ++---
> mm/vmscan.c | 5 +--
> mm/vmstat.c | 9 ++---
> 11 files changed, 94 insertions(+), 81 deletions(-)
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH v4 1/5] mm: introduce zone lock wrappers
From: Zi Yan @ 2026-02-28 1:13 UTC (permalink / raw)
To: Dmitry Ilvokhin
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Rafael J. Wysocki, Pavel Machek, Len Brown, Brendan Jackman,
Johannes Weiner, Oscar Salvador, Qi Zheng, Shakeel Butt,
linux-kernel, linux-mm, linux-trace-kernel, linux-pm, linux-cxl,
kernel-team
In-Reply-To: <849dee9c47df1e6fba97c9933af0d5a08b8e15d3.1772206930.git.d@ilvokhin.com>
On 27 Feb 2026, at 11:00, Dmitry Ilvokhin wrote:
> Add thin wrappers around zone lock acquire/release operations. This
> prepares the code for future tracepoint instrumentation without
> modifying individual call sites.
>
> Centralizing zone lock operations behind wrappers allows future
> instrumentation or debugging hooks to be added without touching
> all users.
>
> No functional change intended. The wrappers are introduced in
> preparation for subsequent patches and are not yet used.
>
> Signed-off-by: Dmitry Ilvokhin <d@ilvokhin.com>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> ---
> MAINTAINERS | 1 +
> include/linux/mmzone_lock.h | 38 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
> create mode 100644 include/linux/mmzone_lock.h
>
Acked-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* Re: [PATCH] tracing/osnoise: Add option to align tlat threads
From: Crystal Wood @ 2026-02-27 23:49 UTC (permalink / raw)
To: Tomas Glozar, Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, John Kacur, Luis Goncalves, Costa Shulyupin,
Wander Lairson Costa, LKML, linux-trace-kernel
In-Reply-To: <20260227150420.319528-1-tglozar@redhat.com>
On Fri, 2026-02-27 at 16:04 +0100, Tomas Glozar wrote:
> Add an option called TIMERLAT_ALIGN to osnoise/options, together with a
> corresponding setting osnoise/timerlat_align_us.
>
> This option sets the alignment of wakeup times between different
> timerlat threads, similarly to cyclictest's -A/--aligned option. If
> TIMERLAT_ALIGN is set, the first thread that reaches the first cycle
> records its first wake-up time. Each following thread sets its first
> wake-up time to a fixed offset from the recorded time, and incremenets
> it by the same offset.
Why not just set the initial timer expiration to be
"period + cpu * align_us"? Then you wouldn't need any interaction
between CPUs.
> kernel/trace/trace_osnoise.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
Documentation needs to be updated as well.
Should mention that updating align_us while the timer is running won't
take effect immediately (unlike period, which does).
> diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
> index dee610e465b9..df1d4529d226 100644
> --- a/kernel/trace/trace_osnoise.c
> +++ b/kernel/trace/trace_osnoise.c
> @@ -58,6 +58,7 @@ enum osnoise_options_index {
> OSN_PANIC_ON_STOP,
> OSN_PREEMPT_DISABLE,
> OSN_IRQ_DISABLE,
> + OSN_TIMERLAT_ALIGN,
> OSN_MAX
> };
>
> @@ -66,7 +67,8 @@ static const char * const osnoise_options_str[OSN_MAX] = {
> "OSNOISE_WORKLOAD",
> "PANIC_ON_STOP",
> "OSNOISE_PREEMPT_DISABLE",
> - "OSNOISE_IRQ_DISABLE" };
> + "OSNOISE_IRQ_DISABLE",
> + "TIMERLAT_ALIGN" };
Do we really need a flag for this, or can we just interpret a non-zero
align_us value as enabling the feature?
> @@ -1820,6 +1824,7 @@ static int wait_next_period(struct timerlat_variables *tlat)
> {
> ktime_t next_abs_period, now;
> u64 rel_period = osnoise_data.timerlat_period * 1000;
> + static atomic64_t align_next;
How will this get reset if the tracer is stopped and restarted?
> now = hrtimer_cb_get_time(&tlat->timer);
> next_abs_period = ns_to_ktime(tlat->abs_period + rel_period);
> @@ -1829,6 +1834,17 @@ static int wait_next_period(struct timerlat_variables *tlat)
> */
> tlat->abs_period = (u64) ktime_to_ns(next_abs_period);
>
> + if (test_bit(OSN_TIMERLAT_ALIGN, &osnoise_options) && !tlat->count
> + && atomic64_cmpxchg_relaxed(&align_next, 0, tlat->abs_period)) {
> + /*
> + * Align thread in first cycle on each CPU to the set alignment.
> + */
> + tlat->abs_period = atomic64_fetch_add_relaxed(osnoise_data.timerlat_align_us * 1000,
> + &align_next);
> + tlat->abs_period += osnoise_data.timerlat_align_us * 1000;
> + next_abs_period = ns_to_ktime(tlat->abs_period);
> + }
I'm already unclear about the existing purpose of next_abs_period, but
if it has any use at all shouldn't it be to avoid writing intermediate
values like this back to tlat?
-Crystal
^ permalink raw reply
* Re: [PATCH] blktrace: fix __this_cpu_read/write in preemptible context
From: Chaitanya Kulkarni @ 2026-02-27 23:08 UTC (permalink / raw)
To: Steven Rostedt, axboe@kernel.dk
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
shinichiro.kawasaki@wdc.com, linux-block@vger.kernel.org,
Chaitanya Kulkarni, linux-trace-kernel@vger.kernel.org
In-Reply-To: <20260227141951.102e19ce@gandalf.local.home>
On 2/27/26 11:19, Steven Rostedt wrote:
> On Thu, 26 Feb 2026 21:03:03 -0800
> Chaitanya Kulkarni <kch@nvidia.com> wrote:
>
>> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
>> index 3b7c102a6eb3..488552036583 100644
>> --- a/kernel/trace/blktrace.c
>> +++ b/kernel/trace/blktrace.c
>> @@ -383,7 +383,9 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
>> cpu = raw_smp_processor_id();
>>
>> if (blk_tracer) {
>> + preempt_disable_notrace();
>> tracing_record_cmdline(current);
>> + preempt_enable_notrace();
>>
>> buffer = blk_tr->array_buffer.buffer;
>> trace_ctx = tracing_gen_ctx_flags(0);
> Do you know when this started? rcu_read_lock() doesn't disable preemption
> in PREEMPT environments, and hasn't for a very long time. I'm surprised it
> took this long to detect this? Perhaps this was a bug from day one?
This started with latest pull which I did on Wed.
Last time same test passed on 2/11/26 since I ran blktests and posted
following patch on 2/11/26 12:47 pacific :-
[PATCH V4] blktrace: log dropped REQ_OP_ZONE_XXX events ver1
Shinichiro CC'd here also reported same bug.
I think Fixes tag would be :-
Fixes: 7ffbd48d5cab ("tracing: Cache comms only after an event occurred")
Since above commit added __this_cpu_read(trace_cmdline_save) and
__this_cpu_write(trace_cmdline_save) :-
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index b90a827a4641..88111b08b2c1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -77,6 +77,13 @@ static int dummy_set_flag(u32 old_flags, u32 bit, int set)
return 0;
}
+/*
+ * To prevent the comm cache from being overwritten when no
+ * tracing is active, only save the comm when a trace event
+ * occurred.
+ */
+static DEFINE_PER_CPU(bool, trace_cmdline_save);
+
/*
* Kill all tracing for good (never come back).
* It is initialized to 1 but will turn to zero if the initialization
@@ -1135,6 +1142,11 @@ void tracing_record_cmdline(struct task_struct *tsk)
!tracing_is_on())
return;
+ if (!__this_cpu_read(trace_cmdline_save))
+ return;
+
+ __this_cpu_write(trace_cmdline_save, false);
+
trace_save_cmdline(tsk);
}
Full disclosure I've no idea why it has started showing up this month.
I've worked on blktrace extensively and tested my code a lot for form
2020-2021 after above commit but never has seen this even with my patches.
> Anyway, the tracing_record_cmdline() is to update the COMM cache so that
> the trace has way to show the task->comm based on the saved PID in the
> trace. It sets a flag to record the COMM from the sched_switch event if a
> trace event happened. It's not needed if no trace event occurred. That
> means, instead of adding preempt_disable() here, just move it after the
> ring buffer event is reserved, as that means preemption is disabled until
> the event is committed.
>
> i.e.
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index e6988929ead2..3735cbc1f99f 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -383,8 +383,6 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
> cpu = raw_smp_processor_id();
>
> if (blk_tracer) {
> - tracing_record_cmdline(current);
> -
> buffer = blk_tr->array_buffer.buffer;
> trace_ctx = tracing_gen_ctx_flags(0);
> switch (bt->version) {
> @@ -419,6 +417,8 @@ static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
> if (!event)
> return;
>
> + tracing_record_cmdline(current);
> +
> switch (bt->version) {
> case 1:
> record_blktrace_event(ring_buffer_event_data(event),
>
> -- Steve
Above does fix the problem and make testcase pass :-
blktests (master) # ./check blktrace
blktrace/001 (blktrace zone management command tracing) [passed]
runtime 3.650s ... 3.647s
blktrace/002 (blktrace ftrace corruption with sysfs trace) [passed]
runtime 0.411s ... 0.384s
blktests (master) #
I'll send a V2.
-ck
^ permalink raw reply related
* Re: [External] Re: [RFC PATCH bpf-next v3 1/3] libbpf: Optimize kprobe.session attachment for exact function names
From: Andrey Grodzovsky @ 2026-02-27 22:28 UTC (permalink / raw)
To: bot+bpf-ci, yonghong.song
Cc: bpf, linux-open-source, ast, daniel, andrii, jolsa, rostedt,
linux-trace-kernel, martin.lau, eddyz87, clm, ihor.solodrai
In-Reply-To: <2d0e9de12b7bf49a0b5117da6d305b0e918785818b63798dfd85de1635b68e8b@mail.kernel.org>
On Fri, Feb 27, 2026 at 4:18 PM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -12041,7 +12041,15 @@ struct kprobe_multi_resolve res = {
> > if (addrs && syms)
> > return libbpf_err_ptr(-EINVAL);
> >
> > - if (pattern) {
> > + /*
> > + * Exact function name (no wildcards): bypass kallsyms parsing
> > + * and pass the symbol directly to the kernel via syms[] array.
> > + * The kernel's ftrace_lookup_symbols() resolves it efficiently.
> > + */
> > + if (pattern && !strpbrk(pattern, "*?")) {
> > + syms = &pattern;
> > + cnt = 1;
> > + } else if (pattern) {
>
> When the fast path is taken here, unique_match is never checked.
> The unique_match validation is inside the "else if (pattern)"
> branch:
>
> if (unique_match && res.cnt != 1) {
> pr_warn("prog '%s': failed to find a unique match ...");
> err = -EINVAL;
> goto error;
> }
>
> Before this change, a caller passing an exact function name with
> unique_match = true would go through kallsyms parsing, which could
> find multiple addresses for same-named static functions across
> different translation units, and the unique_match check would
> correctly return an error.
>
> With the fast path, the name goes directly to the kernel's
> ftrace_lookup_symbols(), which resolves only the first match via
> kallsyms_callback() skipping duplicates:
>
> if (args->addrs[idx])
> return 0;
>
> Should the fast path condition also check unique_match, for
> example:
>
> if (pattern && !strpbrk(pattern, "*?") && !unique_match) {
>
> This would preserve the optimization for the common case while
> falling back to the slow path when unique_match is explicitly
> requested.
>
I am not sure this makes sense, according to the original patchset [1]
this flag was specifically tailored for patterns with wildcards where
this indeed
makes sense. in our case, cnt == 1 from the get go since no wildcards so this
check can't ever fail.
Andrii, Yonghong - any suggestions ?
[1] - https://lore.kernel.org/bpf/20241218225246.3170300-1-yonghong.song@linux.dev/
Andrey
> > [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://urldefense.com/v3/__https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md__;!!BmdzS3_lV9HdKG8!z-aIXCz8YRZcraMmGI2bmb4YrDgW0brRTcX_BaJCWYwj7xfmkZL6qka6aqqIwzDPUjR1TxUU-Mc50s9AAYQf-vQMuPuGlVKW$
>
> CI run summary: https://urldefense.com/v3/__https://github.com/kernel-patches/bpf/actions/runs/22503275616__;!!BmdzS3_lV9HdKG8!z-aIXCz8YRZcraMmGI2bmb4YrDgW0brRTcX_BaJCWYwj7xfmkZL6qka6aqqIwzDPUjR1TxUU-Mc50s9AAYQf-vQMuGeekJPd$
>
> AI-authorship-score: medium
> AI-authorship-explanation: Comments are unusually verbose for a simple optimization, and the commit message is well-structured with distinct sections, but the iterative v1-v3 refinement following reviewer feedback is typical of human development.
> issues-found: 1
> issue-severity-score: low
> issue-severity-explanation: The fast path bypasses the unique_match check, which could silently attach to the wrong function among same-named statics, but requires the uncommon combination of unique_match=true with an exact name matching multiple kernel functions.
^ permalink raw reply
* Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: Ihor Solodrai @ 2026-02-27 22:00 UTC (permalink / raw)
To: Jiri Olsa
Cc: Steven Rostedt, Florent Revest, Mark Rutland, bpf, linux-kernel,
linux-trace-kernel, linux-arm-kernel, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Menglong Dong, Song Liu,
Kumar Kartikeya Dwivedi
In-Reply-To: <aaILlSuEgaYDq41r@krava>
On 2/27/26 1:24 PM, Jiri Olsa wrote:
> On Fri, Feb 27, 2026 at 09:37:52PM +0100, Jiri Olsa wrote:
>> [...]
>>
>>>
>>> With CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS ftrace_replace_code()
>>> operates on all call sites in the shared ops. Then if a concurrent
>>> ftrace user (like kprobe) modifies a call site in between
>>> ftrace_replace_code's verify pass and its patch pass, then ftrace_bug
>>> fires and sets ftrace_disabled to 1.
>>
>> hum, I'd think that's all under ftrace_lock/direct_mutex,
>> but we might be missing some paths
>>
>
> could you please try with change below? I can no longer trigger the bug with it
Can confirm that the bug doesn't trigger with this change.
At least by the reproducer test.
Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Thanks!
>
> thanks,
> jirka
>
>
> ---
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 827fb9a0bf0d..e333749a5896 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
> new_filter_hash = old_filter_hash;
> }
> } else {
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
> @@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
> ops->func_hash->filter_hash = NULL;
> }
> } else {
> + mutex_lock(&ftrace_lock);
> err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
> + mutex_unlock(&ftrace_lock);
> /*
> * new_filter_hash is dup-ed, so we need to release it anyway,
> * old_filter_hash either stays on error or is already released
^ permalink raw reply
* Re: [PATCH v18 0/3] Improve proc RSS accuracy
From: Andrew Morton @ 2026-02-27 21:27 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linux-kernel, Paul E. McKenney, Steven Rostedt, Masami Hiramatsu,
Dennis Zhou, Tejun Heo, Christoph Lameter, Martin Liu,
David Rientjes, christian.koenig, Shakeel Butt, SeongJae Park,
Michal Hocko, Johannes Weiner, Sweet Tea Dorminy, Lorenzo Stoakes,
Liam R . Howlett, Mike Rapoport, Suren Baghdasaryan,
Vlastimil Babka, Christian Brauner, Wei Yang, David Hildenbrand,
Miaohe Lin, Al Viro, linux-mm, linux-trace-kernel, Yu Zhao,
Roman Gushchin, Mateusz Guzik, Matthew Wilcox, Baolin Wang,
Aboorva Devarajan
In-Reply-To: <20260227153730.1556542-1-mathieu.desnoyers@efficios.com>
On Fri, 27 Feb 2026 10:37:27 -0500 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> This series introduces the hierarchical tree counter (hpcc) to increase
> accuracy of approximated RSS counters exposed through proc interfaces.
>
> With a test program hopping across CPUs doing frequent mmap/munmap
> operations, the upstream implementation approximation reaches a 1GB
> delta from the precise value after a few minutes, compared to a 80MB
> delta with the hierarchical counter. The hierarchical counter provides a
> guaranteed maximum approximation inaccuracy of 192MB on that hardware
> topology.
>
> This series is based on tag v7.0-rc1.
>
> The main changes since v17:
> - Fix patch series bissectability.
> - Export GPL symbols for kunit tests.
> - Improve kunit tests coverage.
> - Fix kunit tests wait queue head reinit bug.
> - Fix an out-of-bound on bootup on configurations where nr_cpu_ids is
> close to NR_CPUS.
Updated, thanks.
> Andrew, this series targets 7.1.
Some review would be useful. Can you think of someone we could ask to
undertake this?
^ permalink raw reply
* Re: [PATCHv6 bpf-next 9/9] bpf,x86: Use single ftrace_ops for direct calls
From: Jiri Olsa @ 2026-02-27 21:24 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Jiri Olsa, Steven Rostedt, Florent Revest, Mark Rutland, bpf,
linux-kernel, linux-trace-kernel, linux-arm-kernel,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Menglong Dong, Song Liu, Kumar Kartikeya Dwivedi
In-Reply-To: <aaIAoBZGkP7RQrvc@krava>
On Fri, Feb 27, 2026 at 09:37:52PM +0100, Jiri Olsa wrote:
> On Fri, Feb 27, 2026 at 09:40:12AM -0800, Ihor Solodrai wrote:
> > On 12/30/25 6:50 AM, Jiri Olsa wrote:
> > > Using single ftrace_ops for direct calls update instead of allocating
> > > ftrace_ops object for each trampoline.
> > >
> > > With single ftrace_ops object we can use update_ftrace_direct_* api
> > > that allows multiple ip sites updates on single ftrace_ops object.
> > >
> > > Adding HAVE_SINGLE_FTRACE_DIRECT_OPS config option to be enabled on
> > > each arch that supports this.
> > >
> > > At the moment we can enable this only on x86 arch, because arm relies
> > > on ftrace_ops object representing just single trampoline image (stored
> > > in ftrace_ops::direct_call). Archs that do not support this will continue
> > > to use *_ftrace_direct api.
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> >
> > Hi Jiri,
> >
> > Me and Kumar stumbled on kernel splats with "ftrace failed to modify",
> > and if running with KASAN:
> >
> > BUG: KASAN: slab-use-after-free in __get_valid_kprobe+0x224/0x2a0
> >
> > Pasting a full splat example at the bottom.
> >
> > I was able to create a reproducer with AI, and then used it to bisect
> > to this patch. You can run it with ./test_progs -t ftrace_direct_race
> >
> > Below is my (human-generated, haha) summary of AI's analysis of what's
> > happening. It makes sense to me conceptually, but I don't know enough
> > details here to call bullshit. Please take a look:
>
> hi, nice :)
>
> >
> > With CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS ftrace_replace_code()
> > operates on all call sites in the shared ops. Then if a concurrent
> > ftrace user (like kprobe) modifies a call site in between
> > ftrace_replace_code's verify pass and its patch pass, then ftrace_bug
> > fires and sets ftrace_disabled to 1.
>
> hum, I'd think that's all under ftrace_lock/direct_mutex,
> but we might be missing some paths
>
could you please try with change below? I can no longer trigger the bug with it
thanks,
jirka
---
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 827fb9a0bf0d..e333749a5896 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6404,7 +6404,9 @@ int update_ftrace_direct_add(struct ftrace_ops *ops, struct ftrace_hash *hash)
new_filter_hash = old_filter_hash;
}
} else {
+ mutex_lock(&ftrace_lock);
err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
+ mutex_unlock(&ftrace_lock);
/*
* new_filter_hash is dup-ed, so we need to release it anyway,
* old_filter_hash either stays on error or is already released
@@ -6530,7 +6532,9 @@ int update_ftrace_direct_del(struct ftrace_ops *ops, struct ftrace_hash *hash)
ops->func_hash->filter_hash = NULL;
}
} else {
+ mutex_lock(&ftrace_lock);
err = ftrace_update_ops(ops, new_filter_hash, EMPTY_HASH);
+ mutex_unlock(&ftrace_lock);
/*
* new_filter_hash is dup-ed, so we need to release it anyway,
* old_filter_hash either stays on error or is already released
^ permalink raw reply related
* Re: [RFC PATCH bpf-next v3 1/3] libbpf: Optimize kprobe.session attachment for exact function names
From: bot+bpf-ci @ 2026-02-27 21:17 UTC (permalink / raw)
To: andrey.grodzovsky, bpf, linux-open-source
Cc: ast, daniel, andrii, jolsa, rostedt, linux-trace-kernel, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260227204052.725813-2-andrey.grodzovsky@crowdstrike.com>
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -12041,7 +12041,15 @@ struct kprobe_multi_resolve res = {
> if (addrs && syms)
> return libbpf_err_ptr(-EINVAL);
>
> - if (pattern) {
> + /*
> + * Exact function name (no wildcards): bypass kallsyms parsing
> + * and pass the symbol directly to the kernel via syms[] array.
> + * The kernel's ftrace_lookup_symbols() resolves it efficiently.
> + */
> + if (pattern && !strpbrk(pattern, "*?")) {
> + syms = &pattern;
> + cnt = 1;
> + } else if (pattern) {
When the fast path is taken here, unique_match is never checked.
The unique_match validation is inside the "else if (pattern)"
branch:
if (unique_match && res.cnt != 1) {
pr_warn("prog '%s': failed to find a unique match ...");
err = -EINVAL;
goto error;
}
Before this change, a caller passing an exact function name with
unique_match = true would go through kallsyms parsing, which could
find multiple addresses for same-named static functions across
different translation units, and the unique_match check would
correctly return an error.
With the fast path, the name goes directly to the kernel's
ftrace_lookup_symbols(), which resolves only the first match via
kallsyms_callback() skipping duplicates:
if (args->addrs[idx])
return 0;
Should the fast path condition also check unique_match, for
example:
if (pattern && !strpbrk(pattern, "*?") && !unique_match) {
This would preserve the optimization for the common case while
falling back to the slow path when unique_match is explicitly
requested.
> [ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22503275616
AI-authorship-score: medium
AI-authorship-explanation: Comments are unusually verbose for a simple optimization, and the commit message is well-structured with distinct sections, but the iterative v1-v3 refinement following reviewer feedback is typical of human development.
issues-found: 1
issue-severity-score: low
issue-severity-explanation: The fast path bypasses the unique_match check, which could silently attach to the wrong function among same-named statics, but requires the uncommon combination of unique_match=true with an exact name matching multiple kernel functions.
^ 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