* 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 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 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 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 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 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 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
* [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 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
* 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 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: 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 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 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
* [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 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
* 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 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: 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: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: 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
* [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
* [PATCH] tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
From: Deepanshu Kartikey @ 2026-01-30 6:03 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers
Cc: m.szyprowski, leon, jgg, ptesarik, kbusch, linux-kernel,
linux-trace-kernel, Deepanshu Kartikey,
syzbot+28cea38c382fd15e751a, Deepanshu Kartikey
The dma_map_sg tracepoint can trigger a perf buffer overflow when
tracing large scatter-gather lists. With devices like virtio-gpu
creating large DRM buffers, nents can exceed 1000 entries, resulting
in:
phys_addrs: 1000 * 8 bytes = 8,000 bytes
dma_addrs: 1000 * 8 bytes = 8,000 bytes
lengths: 1000 * 4 bytes = 4,000 bytes
Total: ~20,000 bytes
This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:
WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405
perf buffer not large enough, wanted 24620, have 8192
Cap all three dynamic arrays at a fixed size of 128 entries. This limits
the total event size to approximately 2,760 bytes, safely under the 8KB
limit while still providing sufficient debugging information for typical
cases.
The tracepoint now records the full nents/ents counts and a truncated
flag so users can see when data has been capped.
Reported-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=28cea38c382fd15e751a
Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
---
include/trace/events/dma.h | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/dma.h b/include/trace/events/dma.h
index b3fef140ae15..c4e1a9f0c9c4 100644
--- a/include/trace/events/dma.h
+++ b/include/trace/events/dma.h
@@ -275,6 +275,8 @@ TRACE_EVENT(dma_free_sgt,
sizeof(u64), sizeof(u64)))
);
+#define DMA_TRACE_MAX_ENTRIES 128
+
TRACE_EVENT(dma_map_sg,
TP_PROTO(struct device *dev, struct scatterlist *sgl, int nents,
int ents, enum dma_data_direction dir, unsigned long attrs),
@@ -282,9 +284,12 @@ TRACE_EVENT(dma_map_sg,
TP_STRUCT__entry(
__string(device, dev_name(dev))
- __dynamic_array(u64, phys_addrs, nents)
- __dynamic_array(u64, dma_addrs, ents)
- __dynamic_array(unsigned int, lengths, ents)
+ __field(int, full_nents)
+ __field(int, full_ents)
+ __field(bool, truncated)
+ __dynamic_array(u64, phys_addrs, DMA_TRACE_MAX_ENTRIES)
+ __dynamic_array(u64, dma_addrs, DMA_TRACE_MAX_ENTRIES)
+ __dynamic_array(unsigned int, lengths, DMA_TRACE_MAX_ENTRIES)
__field(enum dma_data_direction, dir)
__field(unsigned long, attrs)
),
@@ -292,11 +297,16 @@ TRACE_EVENT(dma_map_sg,
TP_fast_assign(
struct scatterlist *sg;
int i;
+ int traced_nents = min_t(int, nents, DMA_TRACE_MAX_ENTRIES);
+ int traced_ents = min_t(int, ents, DMA_TRACE_MAX_ENTRIES);
__assign_str(device);
- for_each_sg(sgl, sg, nents, i)
+ __entry->full_nents = nents;
+ __entry->full_ents = ents;
+ __entry->truncated = (nents > DMA_TRACE_MAX_ENTRIES) || (ents > DMA_TRACE_MAX_ENTRIES);
+ for_each_sg(sgl, sg, traced_nents, i)
((u64 *)__get_dynamic_array(phys_addrs))[i] = sg_phys(sg);
- for_each_sg(sgl, sg, ents, i) {
+ for_each_sg(sgl, sg, traced_ents, i) {
((u64 *)__get_dynamic_array(dma_addrs))[i] =
sg_dma_address(sg);
((unsigned int *)__get_dynamic_array(lengths))[i] =
@@ -306,9 +316,12 @@ TRACE_EVENT(dma_map_sg,
__entry->attrs = attrs;
),
- TP_printk("%s dir=%s dma_addrs=%s sizes=%s phys_addrs=%s attrs=%s",
+ TP_printk("%s dir=%s nents=%d/%d ents=%d/%d%s dma_addrs=%s sizes=%s phys_addrs=%s attrs=%s",
__get_str(device),
decode_dma_data_direction(__entry->dir),
+ min_t(int, __entry->full_nents, DMA_TRACE_MAX_ENTRIES), __entry->full_nents,
+ min_t(int, __entry->full_ents, DMA_TRACE_MAX_ENTRIES), __entry->full_ents,
+ __entry->truncated ? " [TRUNCATED]" : "",
__print_array(__get_dynamic_array(dma_addrs),
__get_dynamic_array_len(dma_addrs) /
sizeof(u64), sizeof(u64)),
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 0/3] powerpc64/ftrace: fixes clang build issues
From: Venkat Rao Bagalkote @ 2026-01-30 6:18 UTC (permalink / raw)
To: Hari Bathini, linuxppc-dev
Cc: Madhavan Srinivasan, Christophe Leroy, Naveen N. Rao,
Michael Ellerman, linux-trace-kernel, Mark Rutland,
Steven Rostedt, Masami Hiramatsu, llvm, Maryam Moghadas
In-Reply-To: <20260127084926.34497-1-hbathini@linux.ibm.com>
On 27/01/26 2:19 pm, Hari Bathini wrote:
> Support for -fpatchable-function-entry on ppc64le was added in Clang
> with [1]. Faced a couple of issues while building the linux kernel
> with Clang though. Patches 1 & 2 address those issues. The last patch
> provides workaround to ensure, an open issue [2] in Clang with
> -fpatchable-function-entry support, does not impact the linux
> ftrace subsystem.
>
> [1] https://github.com/llvm/llvm-project/pull/151569
> [2] https://github.com/llvm/llvm-project/issues/163706
>
>
> Hari Bathini (3):
> powerpc64: make clang cross-build friendly
> powerpc64/ftrace: fix OOL stub count with clang
> powerpc64/ftrace: workaround clang recording GEP in
> __patchable_function_entries
>
> arch/powerpc/Kconfig | 4 +--
> arch/powerpc/kernel/trace/ftrace.c | 26 ++++++++++++++++---
> ....sh => check-fpatchable-function-entry.sh} | 0
> arch/powerpc/tools/ftrace-gen-ool-stubs.sh | 4 +--
> 4 files changed, 26 insertions(+), 8 deletions(-)
> rename arch/powerpc/tools/{gcc-check-fpatchable-function-entry.sh => check-fpatchable-function-entry.sh} (100%)
>
Tested this patch series, and bulild is successful with both GCC and
clang23.x version.
KERNEL PARAMETER enabled:
CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY=y
CONFIG_PPC_FTRACE_OUT_OF_LINE=y
CONFIG_PPC_FTRACE_OUT_OF_LINE_NUM_RESERVE=32768
clang version 23.0.0git
Please add below tag for the series.
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Regards,
Venkat.
^ permalink raw reply
* Re: [PATCH v5 2/4] tracing: Make the backup instance non-reusable
From: Masami Hiramatsu @ 2026-01-30 9:01 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Mathieu Desnoyers, linux-kernel, linux-trace-kernel
In-Reply-To: <20260129145333.002815e1@gandalf.local.home>
On Thu, 29 Jan 2026 14:53:33 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> 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?
Oops, good catch! I missed to update it.
Thanks!
>
> 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;
> > }
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ 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