* [PATCH] bootconfig: Fix to terminate value search if it hits a newline
From: Masami Hiramatsu (Google) @ 2026-01-30 4:41 UTC (permalink / raw)
To: Steven Rostedt, linux-trace-kernel; +Cc: Julius Werner, Masami Hiramatsu, LKML
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Fix bootconfig to terminate the value search if it hits a newline
even if it is empty.
When we pass a bootconfig with an empty value terminated by the
newline, like below::
foo =
bar = value
Current bootconfig interprets it as a single entry::
foo = "bar = value";
However, the Documentation/admin-guide/bootconfig.rst said that
The value has to be terminated by semi-colon (``;``) or newline (``\n``).
Thus, it should be interpreted as::
foo = "";
bar = "value";
Note that if the line has a comment, it still keep searching the
value to the next line::
foo = # comment
value
This is interpreted as `foo = "value"`.
This also updates the test script so that it can check the above cases.
Fixes: 76db5a27a827 ("bootconfig: Add Extra Boot Config support")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
tools/bootconfig/test-bootconfig.sh | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/lib/bootconfig.c b/lib/bootconfig.c
index 81f29c29f47b..94b55ec32444 100644
--- a/lib/bootconfig.c
+++ b/lib/bootconfig.c
@@ -563,7 +563,7 @@ static int __init __xbc_parse_value(char **__v, char **__n)
char *p, *v = *__v;
int c, quotes = 0;
- v = skip_spaces(v);
+ v = skip_spaces_until_newline(v);
while (*v == '#') {
v = skip_comment(v);
v = skip_spaces(v);
diff --git a/tools/bootconfig/test-bootconfig.sh b/tools/bootconfig/test-bootconfig.sh
index 7594659af1e1..0873883182b0 100755
--- a/tools/bootconfig/test-bootconfig.sh
+++ b/tools/bootconfig/test-bootconfig.sh
@@ -171,6 +171,24 @@ $BOOTCONF $INITRD > $OUTFILE
xfail grep -q 'val[[:space:]]' $OUTFILE
xpass grep -q 'val2[[:space:]]' $OUTFILE
+echo "Empty value with ="
+cat > $TEMPCONF << EOF
+foo =
+bar
+EOF
+$BOOTCONF $TEMPCONF > $OUTFILE
+xfail grep 'foo[[:space:]]=[[:space:]]"bar"' $OUTFILE
+xpass grep 'foo[[:space:]]=[[:space:]]"";' $OUTFILE
+
+echo "Continue value after comment"
+cat > $TEMPCONF << EOF
+foo = # comment
+bar
+EOF
+$BOOTCONF $TEMPCONF > $OUTFILE
+xpass grep 'foo[[:space:]]=[[:space:]]"bar"' $OUTFILE
+xfail grep 'foo[[:space:]]=[[:space:]]"";' $OUTFILE
+
echo "=== expected failure cases ==="
for i in samples/bad-* ; do
xfail $BOOTCONF -a $i $INITRD
^ permalink raw reply related
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Yaxiong Tian @ 2026-01-30 4:10 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jens Axboe, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <20260129224520.7f043338@robin>
在 2026/1/30 11:45, Steven Rostedt 写道:
> On Thu, 29 Jan 2026 22:31:16 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
>> I added the below patch and have this result:
>>
>> kworker/u33:1-79 [002] ..... 1.840855: trace_event_update_all: Start syncing
>> swapper/0-1 [005] ..... 6.045742: trace_eval_sync: sync maps
>> kworker/u33:1-79 [002] ..... 12.289296: trace_event_update_all: Finish syncing
>> swapper/0-1 [005] ..... 12.289387: trace_eval_sync: sync maps complete
>>
>> Which shows that the final initcall waited for the work queue to complete:
> Switching to printk() gives me the same results:
>
> # dmesg |grep sync
> [ 1.117856] Start syncing
> [ 4.498360] sync maps
> [ 11.173304] Finish syncing
> [ 11.175660] sync maps complete
>
> -- Steve
Sorry, yes, no problem. I confirmed that init_blk_tracer() is running
properly (when executed sequentially) — if there were an issue, it would
have already gotten stuck in a lock. It seems like this might be related
to the print buffer. I’ll look into this issue myself.
Back to this topic — I don’t object to that proposal.
I think each has its own advantages. Let’s see what others think.
^ permalink raw reply
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Steven Rostedt @ 2026-01-30 3:45 UTC (permalink / raw)
To: Yaxiong Tian
Cc: Jens Axboe, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <20260129223116.489a01fd@robin>
On Thu, 29 Jan 2026 22:31:16 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> I added the below patch and have this result:
>
> kworker/u33:1-79 [002] ..... 1.840855: trace_event_update_all: Start syncing
> swapper/0-1 [005] ..... 6.045742: trace_eval_sync: sync maps
> kworker/u33:1-79 [002] ..... 12.289296: trace_event_update_all: Finish syncing
> swapper/0-1 [005] ..... 12.289387: trace_eval_sync: sync maps complete
>
> Which shows that the final initcall waited for the work queue to complete:
Switching to printk() gives me the same results:
# dmesg |grep sync
[ 1.117856] Start syncing
[ 4.498360] sync maps
[ 11.173304] Finish syncing
[ 11.175660] sync maps complete
-- Steve
^ permalink raw reply
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Steven Rostedt @ 2026-01-30 3:31 UTC (permalink / raw)
To: Yaxiong Tian
Cc: Jens Axboe, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <20260129222608.7000bffd@robin>
On Thu, 29 Jan 2026 22:26:08 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> Use trace_printk() instead. printk now has a "deferred" output. I'm not
> sure if the timestamps of when it prints is when the print took place
> or when it got to the console :-/
I added the below patch and have this result:
kworker/u33:1-79 [002] ..... 1.840855: trace_event_update_all: Start syncing
swapper/0-1 [005] ..... 6.045742: trace_eval_sync: sync maps
kworker/u33:1-79 [002] ..... 12.289296: trace_event_update_all: Finish syncing
swapper/0-1 [005] ..... 12.289387: trace_eval_sync: sync maps complete
Which shows that the final initcall waited for the work queue to complete:
-- Steve
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 396d59202438..33180d5622a8 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -10817,9 +10817,11 @@ subsys_initcall(trace_eval_init);
static int __init trace_eval_sync(void)
{
+ trace_printk("sync maps\n");
/* Make sure the eval map updates are finished */
if (eval_map_wq)
destroy_workqueue(eval_map_wq);
+ trace_printk("sync maps complete\n");
return 0;
}
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index af6d1fe5cab7..194b344400e9 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -3555,6 +3555,7 @@ void trace_event_update_all(struct trace_eval_map **map, int len)
int last_i;
int i;
+ trace_printk("Start syncing\n");
down_write(&trace_event_sem);
list_for_each_entry_safe(call, p, &ftrace_events, list) {
/* events are usually grouped together with systems */
@@ -3593,6 +3594,8 @@ void trace_event_update_all(struct trace_eval_map **map, int len)
cond_resched();
}
up_write(&trace_event_sem);
+ msleep(10000);
+ trace_printk("Finish syncing\n");
}
static bool event_in_systems(struct trace_event_call *call,
^ permalink raw reply related
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Steven Rostedt @ 2026-01-30 3:26 UTC (permalink / raw)
To: Yaxiong Tian
Cc: Jens Axboe, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <a61e6bc0-58d1-46f0-8a4f-17f02503fe17@kylinos.cn>
On Fri, 30 Jan 2026 11:09:26 +0800
Yaxiong Tian <tianyaxiong@kylinos.cn> wrote:
> > thought|trace_eval_sync()|'s|destroy_workqueue()|would wait for all
> > tasks to complete, but it seems that might not be the case. From this,
> > if the above conclusion is true, then strictly speaking, tasks
> > using|queue_work(xx)|cannot be guaranteed to finish before the init
> > process executes. If it's necessary to strictly ensure initialization
> > completes before user space starts,
> > using|async_synchronize_full()|or|async_synchronize_full_domain()|would
> > be better in such scenarios.
> I need to double-check this issue—theoretically, it shouldn't exist. But
> I'm not sure why the print appeared at the 14-second mark.
Use trace_printk() instead. printk now has a "deferred" output. I'm not
sure if the timestamps of when it prints is when the print took place
or when it got to the console :-/
-- Steve
> >
> > Of course, the situation described above is an extreme case. I don't
> > oppose this approach; I only hope to make the startup faster for
> > ordinary users who don’t use trace, while minimizing the impact on
> > others as much as possible.
> >
^ permalink raw reply
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Yaxiong Tian @ 2026-01-30 3:09 UTC (permalink / raw)
To: Steven Rostedt, Jens Axboe
Cc: mhiramat, mathieu.desnoyers, corbet, skhan, linux-trace-kernel,
linux-block, linux-kernel, linux-doc
In-Reply-To: <bb29a10c-6130-4040-8521-0b5375c017ef@kylinos.cn>
在 2026/1/30 09:35, Yaxiong Tian 写道:
>
> 在 2026/1/30 04:29, Steven Rostedt 写道:
>> On Wed, 28 Jan 2026 19:25:46 -0700
>> Jens Axboe <axboe@kernel.dk> wrote:
>>
>>> On Jan 28, 2026, at 5:40 PM, Steven Rostedt <rostedt@goodmis.org>
>>> wrote:
>>>>
>>>> Jens,
>>>>
>>>> Can you give me an acked-by on this patch and I can take the series
>>>> through
>>>> my tree.
>>> On phone, hope this works:
>>>
>>> Acked-by: Jens Axboe <axboe@kernel.dk>
>> Thanks!
>>
>>>> Or perhaps this doesn't even need to test the trace_async_init flag
>>>> and can
>>>> always do the work queue? Does blk_trace ever do tracing at boot
>>>> up? That
>>>> is, before user space starts?
>>> Not via the traditonal way of running blktrace.
>> Masami and Yaxiong,
>>
>> I've been thinking about this more and I'm not sure we need the
>> trace_async_init kernel parameter at all. As blktrace should only be
>> enabled by user space, it can always use the work queue.
>>
>> For kprobes, if someone is adding a kprobe on the kernel command
>> line, then
>> they are already specifying that tracing is more important.
>>
>> Patch 3 already keeps kprobes from being an issue with contention of the
>> tracing locks, so I don't think it ever needs to use the work queue.
>>
>> Wouldn't it just be better to remove the trace_async_init and make
>> blktrace
>> always use the work queue and kprobes never do it (but exit out early if
>> there were no kprobes registered)?
>>
>> That is, remove patch 2 and 4 and make this patch always use the work
>> queue.
>
> Yesterday, I was curious about|trace_event_update_all()|, so I
> added|pr_err(xx)|prints within the function's loop. I discovered that
> these prints appeared as late as 14 seconds later (printing is
> time-consuming), by which time the desktop had already been up for
> quite a while. However,|trace_eval_sync()|had already finished running
> at 0.6 seconds.
>
> This implies that I originally
> thought|trace_eval_sync()|'s|destroy_workqueue()|would wait for all
> tasks to complete, but it seems that might not be the case. From this,
> if the above conclusion is true, then strictly speaking, tasks
> using|queue_work(xx)|cannot be guaranteed to finish before the init
> process executes. If it's necessary to strictly ensure initialization
> completes before user space starts,
> using|async_synchronize_full()|or|async_synchronize_full_domain()|would
> be better in such scenarios.
I need to double-check this issue—theoretically, it shouldn't exist. But
I'm not sure why the print appeared at the 14-second mark.
>
> Of course, the situation described above is an extreme case. I don't
> oppose this approach; I only hope to make the startup faster for
> ordinary users who don’t use trace, while minimizing the impact on
> others as much as possible.
>
>>
>> -- Steve
^ permalink raw reply
* Re: [PATCH v6 0/3] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast
From: Steven Rostedt @ 2026-01-30 2:50 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, linux-trace-kernel, bpf, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Sebastian Andrzej Siewior, Alexei Starovoitov
In-Reply-To: <1d6300a5-61a8-498a-8d40-b529bacf9a8a@paulmck-laptop>
On Thu, 29 Jan 2026 17:32:24 -0800
"Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> Thank you, done, and apologies for the hassle! This should show up
> here in a bit:
>
> https://lore.kernel.org/all/8232efe8-a7a3-446c-af0b-19f9b523b4f7@paulmck-laptop/
I can get it from there. Also if you Cc
linux-trace-kernel@vger.kernel.org, I would be able to pull it from
patchwork.
-- Steve
^ permalink raw reply
* [PATCH] tracing: Fix duration calculation bug (rettime - calltime) on ARM architecture
From: jempty.liang @ 2026-01-30 1:57 UTC (permalink / raw)
To: rostedt, mhiramat, mark.rutland, mathieu.desnoyers
Cc: linux-kernel, linux-trace-kernel, jempty.liang
This issue is reproducible on the QEMU vexpress-a9 platform with the
following steps:
Step 1: Launch the QEMU vexpress-a9 VM
~# qemu-system-arm -M vexpress-a9 -smp 1 -m 256 -kernel zImage -dtb \
vexpress-v2p-ca9.dtb -drive file=rootfs.ext2,if=sd,format=raw \
-append "console=ttyAMA0,115200 rootwait" -net nic,model=lan9118 \
-net user -serial stdio
Step 2: Capture and view the trace with trace-cmd
~# trace-cmd record -p function_graph -g do_open_execat \
--max-graph-depth 1 dd if=/dev/zero of=/tmp/1.bin \
bs=1M count=1
~# trace-cmd report
Step 3: Observed behavior
Before:
dd-89 ... 5.764026: funcgraph_entry: $ 2757369004 us | do_open_execat()
dd-89 ... 5.765222: funcgraph_entry: $ 2034790547 us | do_open_execat();
After:
dd-91 ... 891.945577: funcgraph_entry: ! 185.542 us | do_open_execat();
dd-91 ... 891.946840: funcgraph_entry: + 98.625 us | do_open_execat();
Signed-off-by: jempty.liang <imntjempty@163.com>
---
include/linux/ftrace.h | 2 ++
kernel/trace/trace_entries.h | 8 ++++----
kernel/trace/trace_functions_graph.c | 19 +++++++++----------
3 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index a3a8989e3268..52727a342273 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -1191,6 +1191,8 @@ struct ftrace_graph_ret {
int depth;
/* Number of functions that overran the depth limit for current task */
unsigned int overrun;
+ unsigned long long calltime;
+ unsigned long long rettime;
} __packed;
struct fgraph_ops;
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index f6a8d29c0d76..362a757e65a2 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -127,8 +127,8 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
__field_packed( unsigned long, ret, retval )
__field_packed( unsigned int, ret, depth )
__field_packed( unsigned int, ret, overrun )
- __field(unsigned long long, calltime )
- __field(unsigned long long, rettime )
+ __field_packed(unsigned long long, ret, calltime)
+ __field_packed(unsigned long long, ret, rettime)
),
F_printk("<-- %ps (%u) (start: %llx end: %llx) over: %u retval: %lx",
@@ -149,8 +149,8 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
__field_packed( unsigned long, ret, func )
__field_packed( unsigned int, ret, depth )
__field_packed( unsigned int, ret, overrun )
- __field(unsigned long long, calltime )
- __field(unsigned long long, rettime )
+ __field_packed(unsigned long long, ret, calltime)
+ __field_packed(unsigned long long, ret, rettime)
),
F_printk("<-- %ps (%u) (start: %llx end: %llx) over: %u",
diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c
index 1de6f1573621..5798aeb31f05 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -317,6 +317,8 @@ __trace_graph_function(struct trace_array *tr,
struct ftrace_graph_ret ret = {
.func = ip,
.depth = 0,
+ .calltime = time,
+ .rettime = time,
};
__trace_graph_entry(tr, &ent, trace_ctx);
@@ -346,8 +348,8 @@ void __trace_graph_return(struct trace_array *tr,
return;
entry = ring_buffer_event_data(event);
entry->ret = *trace;
- entry->calltime = calltime;
- entry->rettime = rettime;
+ entry->ret.calltime = calltime;
+ entry->ret.rettime = rettime;
trace_buffer_unlock_commit_nostack(buffer, event);
}
@@ -372,10 +374,9 @@ void trace_graph_return(struct ftrace_graph_ret *trace,
struct trace_array *tr = gops->private;
struct fgraph_times *ftimes;
unsigned int trace_ctx;
- u64 calltime, rettime;
int size;
- rettime = trace_clock_local();
+ trace->rettime = trace_clock_local();
ftrace_graph_addr_finish(gops, trace);
@@ -390,10 +391,10 @@ void trace_graph_return(struct ftrace_graph_ret *trace,
handle_nosleeptime(tr, trace, ftimes, size);
- calltime = ftimes->calltime;
+ trace->calltime = ftimes->calltime;
trace_ctx = tracing_gen_ctx();
- __trace_graph_return(tr, trace, trace_ctx, calltime, rettime);
+ __trace_graph_return(tr, trace, trace_ctx, trace->calltime, trace->rettime);
}
static void trace_graph_thresh_return(struct ftrace_graph_ret *trace,
@@ -956,7 +957,7 @@ print_graph_entry_leaf(struct trace_iterator *iter,
graph_ret = &ret_entry->ret;
call = &entry->graph_ent;
- duration = ret_entry->rettime - ret_entry->calltime;
+ duration = graph_ret->rettime - graph_ret->calltime;
if (data) {
struct fgraph_cpu_data *cpu_data;
@@ -1280,9 +1281,7 @@ print_graph_return(struct ftrace_graph_ret_entry *retentry, struct trace_seq *s,
u32 flags)
{
struct ftrace_graph_ret *trace = &retentry->ret;
- u64 calltime = retentry->calltime;
- u64 rettime = retentry->rettime;
- unsigned long long duration = rettime - calltime;
+ unsigned long long duration = trace->rettime - trace->calltime;
struct fgraph_data *data = iter->private;
struct trace_array *tr = iter->tr;
unsigned long func;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Yaxiong Tian @ 2026-01-30 1:35 UTC (permalink / raw)
To: Steven Rostedt, Jens Axboe
Cc: mhiramat, mathieu.desnoyers, corbet, skhan, linux-trace-kernel,
linux-block, linux-kernel, linux-doc
In-Reply-To: <20260129152958.05c1ca46@gandalf.local.home>
在 2026/1/30 04:29, Steven Rostedt 写道:
> On Wed, 28 Jan 2026 19:25:46 -0700
> Jens Axboe <axboe@kernel.dk> wrote:
>
>> On Jan 28, 2026, at 5:40 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>>
>>> Jens,
>>>
>>> Can you give me an acked-by on this patch and I can take the series through
>>> my tree.
>> On phone, hope this works:
>>
>> Acked-by: Jens Axboe <axboe@kernel.dk>
> Thanks!
>
>>> Or perhaps this doesn't even need to test the trace_async_init flag and can
>>> always do the work queue? Does blk_trace ever do tracing at boot up? That
>>> is, before user space starts?
>> Not via the traditonal way of running blktrace.
> Masami and Yaxiong,
>
> I've been thinking about this more and I'm not sure we need the
> trace_async_init kernel parameter at all. As blktrace should only be
> enabled by user space, it can always use the work queue.
>
> For kprobes, if someone is adding a kprobe on the kernel command line, then
> they are already specifying that tracing is more important.
>
> Patch 3 already keeps kprobes from being an issue with contention of the
> tracing locks, so I don't think it ever needs to use the work queue.
>
> Wouldn't it just be better to remove the trace_async_init and make blktrace
> always use the work queue and kprobes never do it (but exit out early if
> there were no kprobes registered)?
>
> That is, remove patch 2 and 4 and make this patch always use the work queue.
Yesterday, I was curious about|trace_event_update_all()|, so I
added|pr_err(xx)|prints within the function's loop. I discovered that
these prints appeared as late as 14 seconds later (printing is
time-consuming), by which time the desktop had already been up for quite
a while. However,|trace_eval_sync()|had already finished running at 0.6
seconds.
This implies that I originally
thought|trace_eval_sync()|'s|destroy_workqueue()|would wait for all
tasks to complete, but it seems that might not be the case. From this,
if the above conclusion is true, then strictly speaking, tasks
using|queue_work(xx)|cannot be guaranteed to finish before the init
process executes. If it's necessary to strictly ensure initialization
completes before user space starts,
using|async_synchronize_full()|or|async_synchronize_full_domain()|would
be better in such scenarios.
Of course, the situation described above is an extreme case. I don't
oppose this approach; I only hope to make the startup faster for
ordinary users who don’t use trace, while minimizing the impact on
others as much as possible.
>
> -- Steve
^ permalink raw reply
* Re: [PATCH v6 0/3] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast
From: Paul E. McKenney @ 2026-01-30 1:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, bpf, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Sebastian Andrzej Siewior, Alexei Starovoitov
In-Reply-To: <20260129193359.08230ac0@gandalf.local.home>
On Thu, Jan 29, 2026 at 07:33:59PM -0500, Steven Rostedt wrote:
> On Tue, 27 Jan 2026 15:18:05 -0800
> "Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> > Ah, I get it. I think. NMIs, right?
> >
> > In your source tree, line 792 of kernel/rcu/srcutree.c is this line of
> > code, correct?
> >
> > WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi());
> >
> > If so, could you please try this test with the patch shown at the end
> > of this email?
> >
>
> >
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index c469c708fdd6a..66ba6a2f83d3a 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -789,7 +789,8 @@ void __srcu_check_read_flavor(struct srcu_struct *ssp, int read_flavor)
> > struct srcu_data *sdp;
> >
> > /* NMI-unsafe use in NMI is a bad sign, as is multi-bit read_flavor values. */
> > - WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi());
> > + WARN_ON_ONCE(read_flavor != SRCU_READ_FLAVOR_NMI &&
> > + read_flavor != SRCU_READ_FLAVOR_FAST && in_nmi());
> > WARN_ON_ONCE(read_flavor & (read_flavor - 1));
> >
> > sdp = raw_cpu_ptr(ssp->sda);
>
> It appears to fix the issue.
>
> Tested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>
> Care to send a formal patch, and I'll add it before the patch that causes
> issues.
Thank you, done, and apologies for the hassle! This should show up
here in a bit:
https://lore.kernel.org/all/8232efe8-a7a3-446c-af0b-19f9b523b4f7@paulmck-laptop/
And I have it below, just in case.
Thanx, Paul
------------------------------------------------------------------------
commit 0bf3a51bef3c33ea528c96720ab6d6211d9009cf
Author: Paul E. McKenney <paulmck@kernel.org>
Date: Tue Jan 27 15:20:02 2026 -0800
srcu: Fix warning to permit SRCU-fast readers in NMI handlers
SRCU-fast is designed to be used in NMI handlers, even going so far
as to use atomic operations for architectures supporting NMIs but not
providing NMI-safe per-CPU atomic operations. However, the WARN_ON_ONCE()
in __srcu_check_read_flavor() complains if SRCU-fast is used in an NMI
handler. This commit therefore modifies that WARN_ON_ONCE() to avoid
such complaints.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: bpf@vger.kernel.org
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index c469c708fdd6a..66ba6a2f83d3a 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -789,7 +789,8 @@ void __srcu_check_read_flavor(struct srcu_struct *ssp, int read_flavor)
struct srcu_data *sdp;
/* NMI-unsafe use in NMI is a bad sign, as is multi-bit read_flavor values. */
- WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi());
+ WARN_ON_ONCE(read_flavor != SRCU_READ_FLAVOR_NMI &&
+ read_flavor != SRCU_READ_FLAVOR_FAST && in_nmi());
WARN_ON_ONCE(read_flavor & (read_flavor - 1));
sdp = raw_cpu_ptr(ssp->sda);
^ permalink raw reply related
* Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: JP Kobryn @ 2026-01-30 1:24 UTC (permalink / raw)
To: Chen Ridong, tj, hannes, mkoutny, rostedt, mhiramat,
mathieu.desnoyers, shakeel.butt
Cc: cgroups, linux-kernel, linux-trace-kernel, lujialin4
In-Reply-To: <20260129063133.209874-1-chenridong@huaweicloud.com>
Hi Chen,
On 1/28/26 10:31 PM, Chen Ridong wrote:
> From: Chen Ridong <chenridong@huawei.com>
>
> The current cgroup subsystem limit of 16 is insufficient, as the number of
> subsystems has already reached this maximum. Attempting to add new
> subsystems beyond this limit results in boot failures.
>
> This patch increases the maximum number of supported cgroup subsystems from
> 16 to 32, providing adequate headroom for future subsystem additions.
>
> Signed-off-by: Chen Ridong <chenridong@huawei.com>
> ---
[...]
I gave this a run with with 32 controllers enabled (16 pre-existing, 16
custom) and can confirm it works as expected.
Tested-by: JP Kobryn <inwardvessel@gmail.com>
Acked-by: JP Kobryn <inwardvessel@gmail.com>
^ permalink raw reply
* Re: [PATCH v2] function_graph: Fix args pointer mismatch in print_graph_retval()
From: Donglin Peng @ 2026-01-30 1:13 UTC (permalink / raw)
To: Steven Rostedt; +Cc: mhiramat, linux-trace-kernel, linux-kernel, Donglin Peng
In-Reply-To: <20260123121858.0f7c3e98@gandalf.local.home>
On Sat, Jan 24, 2026 at 1:18 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 12 Jan 2026 10:16:01 +0800
> Donglin Peng <dolinux.peng@gmail.com> wrote:
>
> > From: Donglin Peng <pengdonglin@xiaomi.com>
> >
> > When funcgraph-args and funcgraph-retaddr are both enabled, many kernel
> > functions display invalid parameters in trace logs[1].
> >
> > The issue occurs because print_graph_retval() passes a mismatched args
> > pointer to print_function_args(). Fix this by retrieving the correct
> > args pointer using the FGRAPH_ENTRY_ARGS() macro.
> >
> > [1] https://gitee.com/pengdonglin137/funcgraph_visualization/raw/master/samples/error_args.png
>
> Please do not provide links to images. This stays in the git logs for the
> lifetime of the Linux kernel. Images like this will likely not live as long
> and the link becomes wasted space in the git history.
Thanks for pointing this out.
>
> Either do a cut and paste of the bad output, or don't include it at all.
Thanks.
>
> -- Steve
>
>
> > Fixes: f83ac7544fbf ("function_graph: Enable funcgraph-args and funcgraph-retaddr to work simultaneously")
> > Signed-off-by: Donglin Peng <pengdonglin@xiaomi.com>
^ permalink raw reply
* Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: Chen Ridong @ 2026-01-30 0:41 UTC (permalink / raw)
To: Waiman Long, Michal Koutný
Cc: tj, hannes, rostedt, mhiramat, mathieu.desnoyers, inwardvessel,
shakeel.butt, cgroups, linux-kernel, linux-trace-kernel,
lujialin4
In-Reply-To: <6fc1fb93-7010-4381-a9a9-68a9b81acf88@redhat.com>
On 2026/1/30 2:33, Waiman Long wrote:
> On 1/29/26 4:51 AM, Chen Ridong wrote:
>>
>> On 2026/1/29 17:23, Michal Koutný wrote:
>>> On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong
>>> <chenridong@huaweicloud.com> wrote:
>>>> From: Chen Ridong <chenridong@huawei.com>
>>>>
>>>> The current cgroup subsystem limit of 16 is insufficient, as the number of
>>>> subsystems has already reached this maximum.
>>> Indeed. But some of them are legacy (and some novel). Do you really need
>>> one kernel image with every subsys config enabled?
>>>
>> We compiled with 'make allmodconfig'.
>>
>>>> Attempting to add new subsystems beyond this limit results in boot
>>>> failures.
>>> That sounds like BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) doesn't trigger
>>> during build for you. Is the macro broken?
>>>
>> The BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) macro worked correctly. However, I
>> only modified the code to allow compilation to pass, and the system subsequently
>> failed to boot.
>>
>>>> This patch increases the maximum number of supported cgroup subsystems from
>>>> 16 to 32, providing adequate headroom for future subsystem additions.
>>> It may be needed one day but I'd suggest binding this change with
>>> introduction of actual new controller.
>>> (As we have some CONFIG_*_V1 options that default to N, I'm thinking
>>> about switching config's default to N as well (like:
>>> CONFIG_CGROUP_CPUACCT CONFIG_CGROUP_DEVICE CONFIG_CGROUP_FREEZER
>>> CONFIG_CGROUP_DEBGU), arch/x86/configs/x86_64_defconfig is not exactly
>>> pinnacle of freshness :-/)
>>>
>>>
>> Can I propose increasing the maximum number now? If we switch certain configs to
>> default N and then a new subsystem is added later, the default configuration may
>> work fine, but it will become a problem under allmodconfig — which some users
>> actually rely on.
>>
>> Besides, this shouldn't be a major change, right?
>
> Yes, I agreed that it is not a major change. I count the number of SUBSYS() in
> include/linux/cgroup_subsys.h and there are exactly 16 of them. So introduction
> of a new cgroup subsystem will break the current limit. I remember that there
> was talk about adding scheduling cgroup on the GPU side. One day, a new cgroup
Thanks, Longman,
Now that dmem has been added, I believe a new subsystem for GPU scheduling will
be introduced soon.
> subsystem may be added without the awareness that the subsystem limit has to be
> extended causing issue down the line. So I support the idea of extending it now
> so that there is one less thing to worry about when a new cgroup subsystem is
> added in the future.
>
> Acked-by: Waiman Long <longman@redhat.com>
>
>
--
Best regards,
Ridong
^ permalink raw reply
* Re: [PATCH v6 0/3] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast
From: Steven Rostedt @ 2026-01-30 0:33 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, linux-trace-kernel, bpf, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Sebastian Andrzej Siewior, Alexei Starovoitov
In-Reply-To: <581f0711-9115-44e8-a616-06cd13563f8c@paulmck-laptop>
On Tue, 27 Jan 2026 15:18:05 -0800
"Paul E. McKenney" <paulmck@kernel.org> wrote:
> Ah, I get it. I think. NMIs, right?
>
> In your source tree, line 792 of kernel/rcu/srcutree.c is this line of
> code, correct?
>
> WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi());
>
> If so, could you please try this test with the patch shown at the end
> of this email?
>
>
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index c469c708fdd6a..66ba6a2f83d3a 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -789,7 +789,8 @@ void __srcu_check_read_flavor(struct srcu_struct *ssp, int read_flavor)
> struct srcu_data *sdp;
>
> /* NMI-unsafe use in NMI is a bad sign, as is multi-bit read_flavor values. */
> - WARN_ON_ONCE((read_flavor != SRCU_READ_FLAVOR_NMI) && in_nmi());
> + WARN_ON_ONCE(read_flavor != SRCU_READ_FLAVOR_NMI &&
> + read_flavor != SRCU_READ_FLAVOR_FAST && in_nmi());
> WARN_ON_ONCE(read_flavor & (read_flavor - 1));
>
> sdp = raw_cpu_ptr(ssp->sda);
It appears to fix the issue.
Tested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Care to send a formal patch, and I'll add it before the patch that causes
issues.
Thanks,
-- Steve
^ permalink raw reply
* [syzbot] [trace?] WARNING in __dma_map_sg_attrs (2)
From: syzbot @ 2026-01-29 22:58 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel, mathieu.desnoyers, mhiramat,
rostedt, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 8dfce8991b95 Merge tag 'pinctrl-v6.19-3' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14278073980000
kernel config: https://syzkaller.appspot.com/x/.config?x=4aae00ac5a9d2645
dashboard link: https://syzkaller.appspot.com/bug?extid=28cea38c382fd15e751a
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1354085a580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111f0d8a580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-8dfce899.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4eaf4687f53f/vmlinux-8dfce899.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3e1fab48af47/bzImage-8dfce899.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
------------[ cut here ]------------
perf buffer not large enough, wanted 24620, have 8192
WARNING: kernel/trace/trace_event_perf.c:407 at perf_trace_buf_alloc+0x1e2/0x280 kernel/trace/trace_event_perf.c:405, CPU#0: syz.0.17/5497
Modules linked in:
CPU: 0 UID: 0 PID: 5497 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:perf_trace_buf_alloc+0x1e9/0x280 kernel/trace/trace_event_perf.c:405
Code: 4c 89 f0 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 05 2d f6 ff 48 8d 3d 9e ca 24 0e 89 de ba 00 20 00 00 <67> 48 0f b9 3a 45 31 f6 eb cc 44 89 f9 80 e1 07 80 c1 03 38 c1 0f
RSP: 0018:ffffc90002a57720 EFLAGS: 00010293
RAX: ffffffff81ce59eb RBX: 000000000000602c RCX: ffff88801f9fa4c0
RDX: 0000000000002000 RSI: 000000000000602c RDI: ffffffff8ff32490
RBP: ffffc90002a578a8 R08: 0000000000000001 R09: 0000000000000000
R10: dffffc0000000000 R11: fffffbfff1fde7cf R12: 0000000000000bfd
R13: 000000000000000c R14: ffffc90002a57820 R15: ffffc90002a57840
FS: 0000555569728500(0000) GS:ffff88808ccea000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fbc8bc17368 CR3: 00000000453be000 CR4: 0000000000352ef0
Call Trace:
<TASK>
do_perf_trace_dma_map_sg include/trace/events/dma.h:278 [inline]
perf_trace_dma_map_sg+0x2a9/0xc00 include/trace/events/dma.h:278
__do_trace_dma_map_sg include/trace/events/dma.h:278 [inline]
trace_dma_map_sg include/trace/events/dma.h:278 [inline]
__dma_map_sg_attrs+0x390/0x520 kernel/dma/mapping.c:251
dma_map_sgtable+0x67/0xf0 kernel/dma/mapping.c:323
drm_gem_shmem_get_pages_sgt_locked drivers/gpu/drm/drm_gem_shmem_helper.c:758 [inline]
drm_gem_shmem_get_pages_sgt+0x16e/0x360 drivers/gpu/drm/drm_gem_shmem_helper.c:798
virtio_gpu_object_shmem_init drivers/gpu/drm/virtio/virtgpu_object.c:171 [inline]
virtio_gpu_object_create+0x1fe/0x1050 drivers/gpu/drm/virtio/virtgpu_object.c:231
virtio_gpu_gem_create drivers/gpu/drm/virtio/virtgpu_gem.c:42 [inline]
virtio_gpu_mode_dumb_create+0x2fb/0x5d0 drivers/gpu/drm/virtio/virtgpu_gem.c:90
drm_mode_create_dumb drivers/gpu/drm/drm_dumb_buffers.c:227 [inline]
drm_mode_create_dumb_ioctl+0x2bd/0x340 drivers/gpu/drm/drm_dumb_buffers.c:236
drm_ioctl_kernel+0x2df/0x3b0 drivers/gpu/drm/drm_ioctl.c:804
drm_ioctl+0x6ba/0xb80 drivers/gpu/drm/drm_ioctl.c:901
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f624939aeb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fffb40ecb88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f6249615fa0 RCX: 00007f624939aeb9
RDX: 0000200000000040 RSI: 00000000c02064b2 RDI: 0000000000000004
RBP: 00007f6249408c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f6249615fac R14: 00007f6249615fa0 R15: 00007f6249615fa0
</TASK>
----------------
Code disassembly (best guess):
0: 4c 89 f0 mov %r14,%rax
3: 48 83 c4 08 add $0x8,%rsp
7: 5b pop %rbx
8: 41 5c pop %r12
a: 41 5d pop %r13
c: 41 5e pop %r14
e: 41 5f pop %r15
10: 5d pop %rbp
11: c3 ret
12: cc int3
13: cc int3
14: cc int3
15: cc int3
16: cc int3
17: e8 05 2d f6 ff call 0xfff62d21
1c: 48 8d 3d 9e ca 24 0e lea 0xe24ca9e(%rip),%rdi # 0xe24cac1
23: 89 de mov %ebx,%esi
25: ba 00 20 00 00 mov $0x2000,%edx
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 45 31 f6 xor %r14d,%r14d
32: eb cc jmp 0x0
34: 44 89 f9 mov %r15d,%ecx
37: 80 e1 07 and $0x7,%cl
3a: 80 c1 03 add $0x3,%cl
3d: 38 c1 cmp %al,%cl
3f: 0f .byte 0xf
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v10 14/30] tracing: Add a trace remote module for testing
From: Vincent Donnefort @ 2026-01-29 21:50 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260129113452.190d4d79@gandalf.local.home>
>
> Where was the cpus_read lock taken?
I am pretty sure that's leftover of when I was reading some CPU mask :-(
>
> > + cpus_read_unlock();
> > +
> > + return ERR_PTR(ret);
> > +}
> > +
[...]
> > +static ssize_t
> > +write_event_write(struct file *filp, const char __user *ubuf, size_t cnt, loff_t *pos)
> > +{
> > + struct remote_event_format_selftest *evt_test;
> > + struct simple_rb_per_cpu *cpu_buffer;
> > + unsigned long val;
> > + int ret;
> > +
> > + ret = kstrtoul_from_user(ubuf, cnt, 10, &val);
> > + if (ret)
> > + return ret;
> > +
> > + guard(mutex)(&simple_rbs_lock);
> > +
> > + if (!remote_event_selftest.enabled)
> > + return -ENODEV;
> > +
>
> You want a guard(preempt)(); here...
>
> > + cpu_buffer = *this_cpu_ptr(&simple_rbs);
>
> Otherwise this triggers:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: bash/1096
> caller is write_event_write+0xe0/0x230 [remote_test]
>
> -- Steve
Ha, of course! And also for a per-CPU ring-buffer, that is way better to make
sure we actually do all the writing from the same CPU even though in that case
the simple_rbs_lock protect us.
>
> > + if (!cpu_buffer)
> > + return -ENODEV;
> > +
> > + evt_test = simple_ring_buffer_reserve(cpu_buffer,
> > + sizeof(struct remote_event_format_selftest),
> > + trace_clock_global());
> > + if (!evt_test)
> > + return -ENODEV;
> > +
> > + evt_test->hdr.id = REMOTE_TEST_EVENT_ID;
> > + evt_test->id = val;
> > +
> > + simple_ring_buffer_commit(cpu_buffer);
> > +
> > + return cnt;
> > +}
> > +
^ permalink raw reply
* Re: [PATCH v10 05/30] tracing: Introduce trace remotes
From: Vincent Donnefort @ 2026-01-29 21:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260128153725.56e801c0@gandalf.local.home>
[...]
> > +static ssize_t buffer_size_kb_write(struct file *filp, const char __user *ubuf, size_t cnt,
> > + loff_t *ppos)
> > +{
> > + struct trace_remote *remote = filp->private_data;
> > + unsigned long val;
> > + int ret;
> > +
> > + ret = kstrtoul_from_user(ubuf, cnt, 10, &val);
> > + if (ret)
> > + return ret;
> > +
> > + /* KiB to Bytes */
> > + if (!val || check_shl_overflow(val, 10, &val))
> > + return -EINVAL;
> > +
> > + guard(mutex)(&remote->lock);
> > +
> > + remote->trace_buffer_size = val;
>
> Should this be allowed to change when it is already loaded?
It would only be effective on the next unload/load.
But now thinking more about it, this is probably not clear to a user and
returning -EBUSY when loaded might be a better solution?
>
> -- Steve
>
> > +
> > + return cnt;
> > +}
> > +
> > +static int buffer_size_kb_show(struct seq_file *s, void *unused)
> > +{
> > + struct trace_remote *remote = s->private;
> > +
> > + seq_printf(s, "%lu (%s)\n", remote->trace_buffer_size >> 10,
> > + trace_remote_loaded(remote) ? "loaded" : "unloaded");
> > +
> > + return 0;
> > +}
> > +DEFINE_SHOW_STORE_ATTRIBUTE(buffer_size_kb);
> > +
>
^ permalink raw reply
* Re: [PATCH v10 00/30] Tracefs support for pKVM
From: Vincent Donnefort @ 2026-01-29 21:34 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mathieu.desnoyers, linux-trace-kernel, maz,
oliver.upton, joey.gouly, suzuki.poulose, yuzenghui, kvmarm,
linux-arm-kernel, jstultz, qperret, will, aneesh.kumar,
kernel-team, linux-kernel
In-Reply-To: <20260129123739.3c00155b@gandalf.local.home>
On Thu, Jan 29, 2026 at 12:37:39PM -0500, Steven Rostedt wrote:
> Hi Vincent,
>
> I finished my review. I replied to every patch (before the KVM ones) and
> either made comments or added a Reviewed-by tag.
Thanks a lot! I will try to send an update tomorrow.
>
> When you send the next version, if you don't modify one of the patches I
> replied with a RB tag, add the tag to the patch and it will let me know I
> don't need to look at it again.
>
> You can use b4 or download the series from here[1] and it will automatically
> add the tags for you. Just create a new branch and apply the download via
> git am and work from there.
>
> Thanks,
>
> -- Steve
>
> [1] https://patchwork.kernel.org/series/1047043/mbox/
^ permalink raw reply
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Steven Rostedt @ 2026-01-29 20:29 UTC (permalink / raw)
To: Jens Axboe
Cc: Yaxiong Tian, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <56C8934E-3D17-4467-93E6-D813770BF577@kernel.dk>
On Wed, 28 Jan 2026 19:25:46 -0700
Jens Axboe <axboe@kernel.dk> wrote:
> On Jan 28, 2026, at 5:40 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> >
> > Jens,
> >
> > Can you give me an acked-by on this patch and I can take the series through
> > my tree.
>
> On phone, hope this works:
>
> Acked-by: Jens Axboe <axboe@kernel.dk>
Thanks!
>
> > Or perhaps this doesn't even need to test the trace_async_init flag and can
> > always do the work queue? Does blk_trace ever do tracing at boot up? That
> > is, before user space starts?
>
> Not via the traditonal way of running blktrace.
Masami and Yaxiong,
I've been thinking about this more and I'm not sure we need the
trace_async_init kernel parameter at all. As blktrace should only be
enabled by user space, it can always use the work queue.
For kprobes, if someone is adding a kprobe on the kernel command line, then
they are already specifying that tracing is more important.
Patch 3 already keeps kprobes from being an issue with contention of the
tracing locks, so I don't think it ever needs to use the work queue.
Wouldn't it just be better to remove the trace_async_init and make blktrace
always use the work queue and kprobes never do it (but exit out early if
there were no kprobes registered)?
That is, remove patch 2 and 4 and make this patch always use the work queue.
-- Steve
^ permalink raw reply
* Re: [PATCH v5 4/4] tracing/Documentation: Add a section about backup instance
From: Steven Rostedt @ 2026-01-29 20:19 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <176955901173.2786091.7719483008240216705.stgit@mhiramat.tok.corp.google.com>
On Wed, 28 Jan 2026 09:10:11 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> Add a section about backup instance to the debugging.rst.
>
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> Documentation/trace/debugging.rst | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/trace/debugging.rst b/Documentation/trace/debugging.rst
> index 4d88c346fc38..73e2154bcf98 100644
> --- a/Documentation/trace/debugging.rst
> +++ b/Documentation/trace/debugging.rst
> @@ -159,3 +159,22 @@ If setting it from the kernel command line, it is recommended to also
> disable tracing with the "traceoff" flag, and enable tracing after boot up.
> Otherwise the trace from the most recent boot will be mixed with the trace
> from the previous boot, and may make it confusing to read.
> +
> +Using a backup instance for keeping previous boot data
> +------------------------------------------------------
> +
> +It is also possible to record trace data at system boot time by specifying
> +events with the persistent ring buffer, but in this case the data before the
> +reboot will be lost before it can be read. This problem can be solved by a
> +backup instance. From the kernel command line::
> +
> + reserve_mem=12M:4096:trace trace_instance=boot_map@trace,sched,irq trace_instance=backup=boot_map
> +
> +When the boot up, the previous data in the`boot_map` is copied to "backup"
s/When the boot up/On boot up/ copied to the "backup"
> +instance, and the "sched:*" and "irq:*" events for current boot are traced on
for the current boot are traced in
> +"boot_map". Thus user can read the previous boot data from the "backup" instance
Thus the user
> +without stopping trace.
stopping the trace.
> +
> +Note that this "backup" instance is readonly, and will be removed automatically
> +if you clear the trace data or read out all trace data from "trace_pipe" or
> +"trace_pipe_raw" files.
> \ No newline at end of file
Definite articles are a pain ;-)
-- Steve
^ permalink raw reply
* Re: [PATCH v5 3/4] tracing: Remove the backup instance automatically after read
From: Steven Rostedt @ 2026-01-29 20:13 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <176955900407.2786091.16663650848612163366.stgit@mhiramat.tok.corp.google.com>
On Wed, 28 Jan 2026 09:10:04 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> Since the backup instance is readonly, after reading all data
> via pipe, no data is left on the instance. Thus it can be
> removed safely after closing all files.
> This also removes it if user resets the ring buffer manually
> via 'trace' file.
>
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> Changes in v4:
> - Update description.
> ---
> kernel/trace/trace.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++-
> kernel/trace/trace.h | 6 +++++
> 2 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index d39f6509c12a..7d615a74f915 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -590,6 +590,55 @@ void trace_set_ring_buffer_expanded(struct trace_array *tr)
> tr->ring_buffer_expanded = true;
> }
>
> +static int __remove_instance(struct trace_array *tr);
> +
> +static void trace_array_autoremove(struct work_struct *work)
> +{
> + struct trace_array *tr = container_of(work, struct trace_array, autoremove_work);
> +
> + guard(mutex)(&event_mutex);
> + guard(mutex)(&trace_types_lock);
> +
> + /*
> + * This can be fail if someone gets @tr before starting this
> + * function, but in that case, this will be kicked again when
> + * putting it. So we don't care the result.
"So we don't care about the result."
> + */
> + __remove_instance(tr);
> +}
> +
> +static struct workqueue_struct *autoremove_wq;
> +
> +static void trace_array_init_autoremove(struct trace_array *tr)
> +{
> + INIT_WORK(&tr->autoremove_work, trace_array_autoremove);
> +}
> +
> +static void trace_array_kick_autoremove(struct trace_array *tr)
> +{
> + if (!work_pending(&tr->autoremove_work) && autoremove_wq)
> + queue_work(autoremove_wq, &tr->autoremove_work);
> +}
> +
> +static void trace_array_cancel_autoremove(struct trace_array *tr)
> +{
> + if (work_pending(&tr->autoremove_work))
> + cancel_work(&tr->autoremove_work);
> +}
> +
> +__init static int trace_array_init_autoremove_wq(void)
> +{
This isn't needed if there's no backup trace_array right?
Instead of creating a work queue when its not needed, just exit out if
there's no backup trace_array.
Oh, and the above functions should always test autoremove_wq for NULL.
> + autoremove_wq = alloc_workqueue("tr_autoremove_wq",
> + WQ_UNBOUND | WQ_HIGHPRI, 0);
> + if (!autoremove_wq) {
> + pr_err("Unable to allocate tr_autoremove_wq\n");
> + return -ENOMEM;
> + }
> + return 0;
> +}
> +
> +late_initcall_sync(trace_array_init_autoremove_wq);
> +
> LIST_HEAD(ftrace_trace_arrays);
>
> int trace_array_get(struct trace_array *this_tr)
> @@ -598,7 +647,7 @@ int trace_array_get(struct trace_array *this_tr)
>
> guard(mutex)(&trace_types_lock);
> list_for_each_entry(tr, &ftrace_trace_arrays, list) {
> - if (tr == this_tr) {
> + if (tr == this_tr && !tr->free_on_close) {
> tr->ref++;
> return 0;
> }
Break the above into:
if (tr == this_tr) {
if (tr->free_on_close)
break;
tr->ref++;
return 0;
}
Why continue the loop if we found the trace_array but it's in the process
of closing?
-- Steve
^ permalink raw reply
* Re: [PATCH v5 2/4] tracing: Make the backup instance non-reusable
From: Steven Rostedt @ 2026-01-29 20:07 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <176955899639.2786091.8716448298561300937.stgit@mhiramat.tok.corp.google.com>
On Wed, 28 Jan 2026 09:09:56 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> @@ -10632,17 +10658,23 @@ static __init void create_trace_instances(struct dentry *d_tracer)
> static void
> init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer)
> {
> + umode_t writable_mode = TRACE_MODE_WRITE;
> + bool readonly = trace_array_is_readonly(tr);
> int cpu;
>
> + if (readonly)
> + writable_mode = TRACE_MODE_READ;
> +
> trace_create_file("available_tracers", TRACE_MODE_READ, d_tracer,
> - tr, &show_traces_fops);
> + tr, &show_traces_fops);
>
> - trace_create_file("current_tracer", TRACE_MODE_WRITE, d_tracer,
> - tr, &set_tracer_fops);
> + trace_create_file("current_tracer", writable_mode, d_tracer,
> + tr, &set_tracer_fops);
>
> - trace_create_file("tracing_cpumask", TRACE_MODE_WRITE, d_tracer,
> + trace_create_file("tracing_cpumask", writable_mode, d_tracer,
> tr, &tracing_cpumask_fops);
>
> + /* Options are used for changing print-format even for readonly instance. */
> trace_create_file("trace_options", TRACE_MODE_WRITE, d_tracer,
> tr, &tracing_iter_fops);
>
> @@ -10652,27 +10684,35 @@ init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer)
> trace_create_file("trace_pipe", TRACE_MODE_READ, d_tracer,
> tr, &tracing_pipe_fops);
>
> - trace_create_file("buffer_size_kb", TRACE_MODE_WRITE, d_tracer,
> + trace_create_file("buffer_size_kb", writable_mode, d_tracer,
> tr, &tracing_entries_fops);
>
> trace_create_file("buffer_total_size_kb", TRACE_MODE_READ, d_tracer,
> tr, &tracing_total_entries_fops);
>
> - trace_create_file("free_buffer", 0200, d_tracer,
> - tr, &tracing_free_buffer_fops);
> + if (!readonly) {
> + trace_create_file("free_buffer", 0200, d_tracer,
> + tr, &tracing_free_buffer_fops);
Hmm, why remove the free_buffer. It just shrinks the buffer down to a
minimum. Perhaps its useless, but I it doesn't write to the buffer. Sure it
removes data but so does trace_pipe.
>
> - trace_create_file("trace_marker", 0220, d_tracer,
> - tr, &tracing_mark_fops);
> + trace_create_file("trace_marker", 0220, d_tracer,
> + tr, &tracing_mark_fops);
>
> - tr->trace_marker_file = __find_event_file(tr, "ftrace", "print");
> + tr->trace_marker_file = __find_event_file(tr, "ftrace", "print");
>
> - trace_create_file("trace_marker_raw", 0220, d_tracer,
> - tr, &tracing_mark_raw_fops);
> + trace_create_file("trace_marker_raw", 0220, d_tracer,
> + tr, &tracing_mark_raw_fops);
>
> - trace_create_file("trace_clock", TRACE_MODE_WRITE, d_tracer, tr,
> + trace_create_file("buffer_percent", TRACE_MODE_WRITE, d_tracer,
> + tr, &buffer_percent_fops);
> +
> + trace_create_file("syscall_user_buf_size", TRACE_MODE_WRITE, d_tracer,
> + tr, &tracing_syscall_buf_fops);
> + }
> +
> + trace_create_file("trace_clock", writable_mode, d_tracer, tr,
> &trace_clock_fops);
>
> - trace_create_file("tracing_on", TRACE_MODE_WRITE, d_tracer,
> + trace_create_file("tracing_on", writable_mode, d_tracer,
> tr, &rb_simple_fops);
Hmm, should tracing_on exist in read only mode?
>
> trace_create_file("timestamp_mode", TRACE_MODE_READ, d_tracer, tr,
> @@ -10680,41 +10720,38 @@ init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer)
>
> tr->buffer_percent = 50;
>
> - trace_create_file("buffer_percent", TRACE_MODE_WRITE, d_tracer,
> - tr, &buffer_percent_fops);
> -
> - trace_create_file("buffer_subbuf_size_kb", TRACE_MODE_WRITE, d_tracer,
> + trace_create_file("buffer_subbuf_size_kb", writable_mode, d_tracer,
> tr, &buffer_subbuf_size_fops);
>
> - trace_create_file("syscall_user_buf_size", TRACE_MODE_WRITE, d_tracer,
> - tr, &tracing_syscall_buf_fops);
> -
> create_trace_options_dir(tr);
>
> #ifdef CONFIG_TRACER_MAX_TRACE
> - trace_create_maxlat_file(tr, d_tracer);
> + if (!readonly)
> + trace_create_maxlat_file(tr, d_tracer);
> #endif
>
> - if (ftrace_create_function_files(tr, d_tracer))
> + if (!readonly && ftrace_create_function_files(tr, d_tracer))
> MEM_FAIL(1, "Could not allocate function filter files");
>
> if (tr->range_addr_start) {
> trace_create_file("last_boot_info", TRACE_MODE_READ, d_tracer,
> tr, &last_boot_fops);
> #ifdef CONFIG_TRACER_SNAPSHOT
> - } else {
> + } else if (!readonly) {
> trace_create_file("snapshot", TRACE_MODE_WRITE, d_tracer,
> tr, &snapshot_fops);
> #endif
> }
>
> - trace_create_file("error_log", TRACE_MODE_WRITE, d_tracer,
> - tr, &tracing_err_log_fops);
> + if (!readonly)
> + trace_create_file("error_log", TRACE_MODE_WRITE, d_tracer,
> + tr, &tracing_err_log_fops);
Why not move this up into the "if (!readonly) {" block above?
>
> for_each_tracing_cpu(cpu)
> tracing_init_tracefs_percpu(tr, cpu);
>
> - ftrace_init_tracefs(tr, d_tracer);
> + if (!readonly)
> + ftrace_init_tracefs(tr, d_tracer);
Same here. Or just move the readonly block down to the end of the function.
> }
>
> #ifdef CONFIG_TRACEFS_AUTOMOUNT_DEPRECATED
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 69e7defba6c6..0adc644084bf 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -33,6 +33,7 @@
>
> #define TRACE_MODE_WRITE 0640
> #define TRACE_MODE_READ 0440
> +#define TRACE_MODE_WRITE_MASK (TRACE_MODE_WRITE & ~TRACE_MODE_READ)
>
> enum trace_type {
> __TRACE_FIRST_TYPE = 0,
> @@ -483,6 +484,12 @@ extern bool trace_clock_in_ns(struct trace_array *tr);
>
> extern unsigned long trace_adjust_address(struct trace_array *tr, unsigned long addr);
>
> +static inline bool trace_array_is_readonly(struct trace_array *tr)
> +{
> + /* backup instance is read only. */
> + return tr->flags & TRACE_ARRAY_FL_VMALLOC;
Hmm, I wonder if we should create a RDONLY flag for the trace_array?
-- Steve
> +}
> +
> /*
> * The global tracer (top) should be the first trace array added,
> * but we check the flag anyway.
> @@ -681,7 +688,6 @@ struct dentry *trace_create_file(const char *name,
> void *data,
> const struct file_operations *fops);
>
> -
> /**
> * tracer_tracing_is_on_cpu - show real state of ring buffer enabled on for a cpu
> * @tr : the trace array to know if ring buffer is enabled
> diff --git a/kernel/trace/trace_boot.c b/kernel/trace/trace_boot.c
> index dbe29b4c6a7a..2ca2541c8a58 100644
> --- a/kernel/trace/trace_boot.c
> +++ b/kernel/trace/trace_boot.c
> @@ -61,7 +61,8 @@ trace_boot_set_instance_options(struct trace_array *tr, struct xbc_node *node)
> v = memparse(p, NULL);
> if (v < PAGE_SIZE)
> pr_err("Buffer size is too small: %s\n", p);
> - if (tracing_resize_ring_buffer(tr, v, RING_BUFFER_ALL_CPUS) < 0)
> + if (trace_array_is_readonly(tr) ||
> + tracing_resize_ring_buffer(tr, v, RING_BUFFER_ALL_CPUS) < 0)
> pr_err("Failed to resize trace buffer to %s\n", p);
> }
>
> @@ -597,7 +598,7 @@ trace_boot_enable_tracer(struct trace_array *tr, struct xbc_node *node)
>
> p = xbc_node_find_value(node, "tracer", NULL);
> if (p && *p != '\0') {
> - if (tracing_set_tracer(tr, p) < 0)
> + if (trace_array_is_readonly(tr) || tracing_set_tracer(tr, p) < 0)
> pr_err("Failed to set given tracer: %s\n", p);
> }
>
^ permalink raw reply
* Re: [PATCH v5 2/4] tracing: Make the backup instance non-reusable
From: Steven Rostedt @ 2026-01-29 19:53 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <176955899639.2786091.8716448298561300937.stgit@mhiramat.tok.corp.google.com>
On Wed, 28 Jan 2026 09:09:56 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> @@ -9388,12 +9405,16 @@ static void
> tracing_init_tracefs_percpu(struct trace_array *tr, long cpu)
> {
> struct dentry *d_percpu = tracing_dentry_percpu(tr, cpu);
> + umode_t writable_mode = TRACE_MODE_WRITE;
> struct dentry *d_cpu;
> char cpu_dir[30]; /* 30 characters should be more than enough */
>
> if (!d_percpu)
> return;
>
> + if (trace_array_is_readonly(tr))
> + writable_mode = TRACE_MODE_READ;
Hmm, writable_mode is set but not used?
Looks like you missed an update.
-- Steve
> +
> snprintf(cpu_dir, 30, "cpu%ld", cpu);
> d_cpu = tracefs_create_dir(cpu_dir, d_percpu);
> if (!d_cpu) {
> @@ -9616,7 +9637,6 @@ struct dentry *trace_create_file(const char *name,
> return ret;
> }
^ permalink raw reply
* Re: [PATCH v5] stm: class: Add MIPI OST protocol support
From: Randy Dunlap @ 2026-01-29 18:38 UTC (permalink / raw)
To: Yingchao Deng, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue
Cc: linux-kernel, linux-trace-kernel, linux-doc, linux-stm32,
linux-arm-kernel, quic_yingdeng, Tingwei Zhang, Yuanfang Zhang,
Jinlong Mao
In-Reply-To: <0ed08d07-5736-4874-9a0f-0f848e8419b6@infradead.org>
On 1/29/26 10:31 AM, Randy Dunlap wrote:
> diff --git a/Documentation/trace/p_ost.rst b/Documentation/trace/p_ost.rst
> new file mode 100644
> index 000000000000..df93b889eb4c
> --- /dev/null
> +++ b/Documentation/trace/p_ost.rst
> @@ -0,0 +1,36 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===================
> +MIPI OST over STP
> +===================
> +
> +The OST(Open System Trace) driver is used with STM class devices to
The OST (Open System Trace) driver
> +generate standardized trace stream. Trace sources can be identified
> +by different entity ids.
> +
> +CONFIG_STM_PROTO_OST is for p_ost driver enablement. Once this config
> +is enabled, you can select the p_ost protocol by command below:
> +
> +# mkdir /sys/kernel/config/stp-policy/stm0:p_ost.policy
> +
> +The policy name format is extended like this:
> + <device_name>:<protocol_name>.<policy_name>
> +
> +With coresight-stm device, it will be look like "stm0:p_ost.policy".
With {a | the} coresight-stm device,
> +
> +With MIPI OST protocol driver, the attributes for each protocol node is:
With the MIPI OST protocol driver, are:
> +# mkdir /sys/kernel/config/stp-policy/stm0:p_ost.policy/default
> +# ls /sys/kernel/config/stp-policy/stm0:p_ost.policy/default
> +channels entity masters
> +
> +The entity here is the set the entity that p_ost supports. Currently
is the set of {entities | features} that p_ost supports. Currently
> +p_ost supports ftrace, console and diag entity.
entities.
> +
> +Set entity:
> +# echo 'ftrace' > /sys/kernel/config/stp-policy/stm0:p_ost.policy/default/entity
> +
> +Get available and currently selected (shown in square brackets) entity that p_ost supports:
> +# cat /sys/kernel/config/stp-policy/stm0:p_ost.policy/default/entity
> +[ftrace] console diag
> +
> +See Documentation/ABI/testing/configfs-stp-policy-p_ost for more details.
--
~Randy
^ permalink raw reply
* Re: [PATCH -next] cgroup: increase maximum subsystem count from 16 to 32
From: Waiman Long @ 2026-01-29 18:33 UTC (permalink / raw)
To: Chen Ridong, Michal Koutný
Cc: tj, hannes, rostedt, mhiramat, mathieu.desnoyers, inwardvessel,
shakeel.butt, cgroups, linux-kernel, linux-trace-kernel,
lujialin4
In-Reply-To: <3a12eb16-3a91-4278-9dfd-6c6f424e7f9f@huaweicloud.com>
On 1/29/26 4:51 AM, Chen Ridong wrote:
>
> On 2026/1/29 17:23, Michal Koutný wrote:
>> On Thu, Jan 29, 2026 at 06:31:33AM +0000, Chen Ridong <chenridong@huaweicloud.com> wrote:
>>> From: Chen Ridong <chenridong@huawei.com>
>>>
>>> The current cgroup subsystem limit of 16 is insufficient, as the number of
>>> subsystems has already reached this maximum.
>> Indeed. But some of them are legacy (and some novel). Do you really need
>> one kernel image with every subsys config enabled?
>>
> We compiled with 'make allmodconfig'.
>
>>> Attempting to add new subsystems beyond this limit results in boot
>>> failures.
>> That sounds like BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) doesn't trigger
>> during build for you. Is the macro broken?
>>
> The BUILD_BUG_ON(CGROUP_SUBSYS_COUNT > 16) macro worked correctly. However, I
> only modified the code to allow compilation to pass, and the system subsequently
> failed to boot.
>
>>> This patch increases the maximum number of supported cgroup subsystems from
>>> 16 to 32, providing adequate headroom for future subsystem additions.
>> It may be needed one day but I'd suggest binding this change with
>> introduction of actual new controller.
>> (As we have some CONFIG_*_V1 options that default to N, I'm thinking
>> about switching config's default to N as well (like:
>> CONFIG_CGROUP_CPUACCT CONFIG_CGROUP_DEVICE CONFIG_CGROUP_FREEZER
>> CONFIG_CGROUP_DEBGU), arch/x86/configs/x86_64_defconfig is not exactly
>> pinnacle of freshness :-/)
>>
>>
> Can I propose increasing the maximum number now? If we switch certain configs to
> default N and then a new subsystem is added later, the default configuration may
> work fine, but it will become a problem under allmodconfig — which some users
> actually rely on.
>
> Besides, this shouldn't be a major change, right?
Yes, I agreed that it is not a major change. I count the number of
SUBSYS() in include/linux/cgroup_subsys.h and there are exactly 16 of
them. So introduction of a new cgroup subsystem will break the current
limit. I remember that there was talk about adding scheduling cgroup on
the GPU side. One day, a new cgroup subsystem may be added without the
awareness that the subsystem limit has to be extended causing issue down
the line. So I support the idea of extending it now so that there is one
less thing to worry about when a new cgroup subsystem is added in the
future.
Acked-by: Waiman Long <longman@redhat.com>
^ 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