* Re: [PATCH v2] ring-buffer: Add helper functions for allocations
From: Masami Hiramatsu @ 2026-01-28 23:47 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Linus Torvalds
In-Reply-To: <20251125121153.35c07461@gandalf.local.home>
On Tue, 25 Nov 2025 12:11:53 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> The allocation of the per CPU buffer descriptor, the buffer page
> descriptors and the buffer page data itself can be pretty ugly:
>
> kzalloc_node(ALIGN(sizeof(struct buffer_page), cache_line_size()),
> GFP_KERNEL, cpu_to_node(cpu));
>
> And the data pages:
>
> page = alloc_pages_node(cpu_to_node(cpu),
> GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO, order);
> if (!page)
> return NULL;
> bpage->page = page_address(page);
> rb_init_page(bpage->page);
>
> Add helper functions to make the code easier to read.
>
> This does make all allocations of the data page (bpage->page) allocated
> with the __GFP_RETRY_MAYFAIL flag (and not just the bulk allocator). Which
> is actually better, as allocating the data page for the ring buffer tracing
> should try hard but not trigger the OOM killer.
>
> Link: https://lore.kernel.org/all/CAHk-=wjMMSAaqTjBSfYenfuzE1bMjLj+2DLtLWJuGt07UGCH_Q@mail.gmail.com/
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
> ---
> Changes since v1: https://patch.msgid.link/20251124140906.71a2abf6@gandalf.local.home
>
> - Removed set but unused variables (kernel test robot)
>
> kernel/trace/ring_buffer.c | 97 +++++++++++++++++++++-----------------
> 1 file changed, 53 insertions(+), 44 deletions(-)
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 1244d2c5c384..6295443b0944 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -401,6 +401,41 @@ static void free_buffer_page(struct buffer_page *bpage)
> kfree(bpage);
> }
>
> +/*
> + * For best performance, allocate cpu buffer data cache line sized
> + * and per CPU.
> + */
> +#define alloc_cpu_buffer(cpu) (struct ring_buffer_per_cpu *) \
> + kzalloc_node(ALIGN(sizeof(struct ring_buffer_per_cpu), \
> + cache_line_size()), GFP_KERNEL, cpu_to_node(cpu));
> +
> +#define alloc_cpu_page(cpu) (struct buffer_page *) \
> + kzalloc_node(ALIGN(sizeof(struct buffer_page), \
> + cache_line_size()), GFP_KERNEL, cpu_to_node(cpu));
> +
> +static struct buffer_data_page *alloc_cpu_data(int cpu, int order)
> +{
> + struct buffer_data_page *dpage;
> + struct page *page;
> + gfp_t mflags;
> +
> + /*
> + * __GFP_RETRY_MAYFAIL flag makes sure that the allocation fails
> + * gracefully without invoking oom-killer and the system is not
> + * destabilized.
> + */
> + mflags = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO;
> +
> + page = alloc_pages_node(cpu_to_node(cpu), mflags, order);
> + if (!page)
> + return NULL;
> +
> + dpage = page_address(page);
> + rb_init_page(dpage);
> +
> + return dpage;
> +}
> +
> /*
> * We need to fit the time_stamp delta into 27 bits.
> */
> @@ -2204,7 +2239,6 @@ static int __rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
> struct ring_buffer_cpu_meta *meta = NULL;
> struct buffer_page *bpage, *tmp;
> bool user_thread = current->mm != NULL;
> - gfp_t mflags;
> long i;
>
> /*
> @@ -2218,13 +2252,6 @@ static int __rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
> if (i < nr_pages)
> return -ENOMEM;
>
> - /*
> - * __GFP_RETRY_MAYFAIL flag makes sure that the allocation fails
> - * gracefully without invoking oom-killer and the system is not
> - * destabilized.
> - */
> - mflags = GFP_KERNEL | __GFP_RETRY_MAYFAIL;
> -
> /*
> * If a user thread allocates too much, and si_mem_available()
> * reports there's enough memory, even though there is not.
> @@ -2241,10 +2268,8 @@ static int __rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
> meta = rb_range_meta(buffer, nr_pages, cpu_buffer->cpu);
>
> for (i = 0; i < nr_pages; i++) {
> - struct page *page;
>
> - bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
> - mflags, cpu_to_node(cpu_buffer->cpu));
> + bpage = alloc_cpu_page(cpu_buffer->cpu);
> if (!bpage)
> goto free_pages;
>
> @@ -2267,13 +2292,10 @@ static int __rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
> bpage->range = 1;
> bpage->id = i + 1;
> } else {
> - page = alloc_pages_node(cpu_to_node(cpu_buffer->cpu),
> - mflags | __GFP_COMP | __GFP_ZERO,
> - cpu_buffer->buffer->subbuf_order);
> - if (!page)
> + int order = cpu_buffer->buffer->subbuf_order;
> + bpage->page = alloc_cpu_data(cpu_buffer->cpu, order);
> + if (!bpage->page)
> goto free_pages;
> - bpage->page = page_address(page);
> - rb_init_page(bpage->page);
> }
> bpage->order = cpu_buffer->buffer->subbuf_order;
>
> @@ -2324,14 +2346,12 @@ static int rb_allocate_pages(struct ring_buffer_per_cpu *cpu_buffer,
> static struct ring_buffer_per_cpu *
> rb_allocate_cpu_buffer(struct trace_buffer *buffer, long nr_pages, int cpu)
> {
> - struct ring_buffer_per_cpu *cpu_buffer __free(kfree) = NULL;
> + struct ring_buffer_per_cpu *cpu_buffer __free(kfree) =
> + alloc_cpu_buffer(cpu);
> struct ring_buffer_cpu_meta *meta;
> struct buffer_page *bpage;
> - struct page *page;
> int ret;
>
> - cpu_buffer = kzalloc_node(ALIGN(sizeof(*cpu_buffer), cache_line_size()),
> - GFP_KERNEL, cpu_to_node(cpu));
> if (!cpu_buffer)
> return NULL;
>
> @@ -2347,8 +2367,7 @@ rb_allocate_cpu_buffer(struct trace_buffer *buffer, long nr_pages, int cpu)
> init_waitqueue_head(&cpu_buffer->irq_work.full_waiters);
> mutex_init(&cpu_buffer->mapping_lock);
>
> - bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()),
> - GFP_KERNEL, cpu_to_node(cpu));
> + bpage = alloc_cpu_page(cpu);
> if (!bpage)
> return NULL;
>
> @@ -2370,13 +2389,10 @@ rb_allocate_cpu_buffer(struct trace_buffer *buffer, long nr_pages, int cpu)
> rb_meta_buffer_update(cpu_buffer, bpage);
> bpage->range = 1;
> } else {
> - page = alloc_pages_node(cpu_to_node(cpu),
> - GFP_KERNEL | __GFP_COMP | __GFP_ZERO,
> - cpu_buffer->buffer->subbuf_order);
> - if (!page)
> + int order = cpu_buffer->buffer->subbuf_order;
> + bpage->page = alloc_cpu_data(cpu, order);
> + if (!bpage->page)
> goto fail_free_reader;
> - bpage->page = page_address(page);
> - rb_init_page(bpage->page);
> }
>
> INIT_LIST_HEAD(&cpu_buffer->reader_page->list);
> @@ -6464,7 +6480,6 @@ ring_buffer_alloc_read_page(struct trace_buffer *buffer, int cpu)
> struct ring_buffer_per_cpu *cpu_buffer;
> struct buffer_data_read_page *bpage = NULL;
> unsigned long flags;
> - struct page *page;
>
> if (!cpumask_test_cpu(cpu, buffer->cpumask))
> return ERR_PTR(-ENODEV);
> @@ -6486,22 +6501,16 @@ ring_buffer_alloc_read_page(struct trace_buffer *buffer, int cpu)
> arch_spin_unlock(&cpu_buffer->lock);
> local_irq_restore(flags);
>
> - if (bpage->data)
> - goto out;
> -
> - page = alloc_pages_node(cpu_to_node(cpu),
> - GFP_KERNEL | __GFP_NORETRY | __GFP_COMP | __GFP_ZERO,
> - cpu_buffer->buffer->subbuf_order);
> - if (!page) {
> - kfree(bpage);
> - return ERR_PTR(-ENOMEM);
> + if (bpage->data) {
> + rb_init_page(bpage->data);
> + } else {
> + bpage->data = alloc_cpu_data(cpu, cpu_buffer->buffer->subbuf_order);
> + if (!bpage->data) {
> + kfree(bpage);
> + return ERR_PTR(-ENOMEM);
> + }
> }
>
> - bpage->data = page_address(page);
> -
> - out:
> - rb_init_page(bpage->data);
> -
> return bpage;
> }
> EXPORT_SYMBOL_GPL(ring_buffer_alloc_read_page);
> --
> 2.51.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] bpf: Implement kretprobe fallback for kprobe multi link
From: Masami Hiramatsu @ 2026-01-29 0:13 UTC (permalink / raw)
To: bot+bpf-ci
Cc: liujing.root, ast, daniel, andrii, martin.lau, eddyz87, song,
yonghong.song, john.fastabend, kpsingh, sdf, haoluo, jolsa, bpf,
linux-kernel, linux-trace-kernel, liujing40, martin.lau, clm,
ihor.solodrai
In-Reply-To: <4ee5b08b6cebfc87b552a0fde1f09fd5a2c190813760aa7e68f1e6d060f15ccd@mail.kernel.org>
On Thu, 18 Dec 2025 13:33:31 +0000 (UTC)
bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 1fd07c10378f..426a1c627508 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
>
> [ ... ]
>
> > +int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
> > +{
> > + struct bpf_kprobe_multi_link *link = NULL;
> > + struct bpf_link_primer link_primer;
> > + struct bpf_kprobe *kprobes = NULL;
> > + u32 flags, cnt;
> > + u64 __user *ucookies;
> > + unsigned long __user *uaddrs;
> > + unsigned long __user *usyms;
> > + int err, i;
>
> [ ... ]
>
> > + for (i = 0; i < cnt; i++) {
> > + unsigned long addr;
> > +
> > + if (uaddrs) {
> > + if (__get_user(addr, uaddrs + i)) {
> > + err = -EFAULT;
> > + goto error;
> > + }
> > + } else {
> > + unsigned long __user usymbol;
> > + char buf[KSYM_NAME_LEN];
> > +
> > + if (__get_user(usymbol, usyms + i)) {
> > + err = -EFAULT;
> > + goto error;
> > + }
> > + err = strncpy_from_user(buf, (const char __user *) usymbol, KSYM_NAME_LEN);
> > + if (err == KSYM_NAME_LEN)
> > + err = -E2BIG;
> > + if (err < 0)
> > + goto error;
> > +
> > + addr = kallsyms_lookup_name(buf);
> > + if (!addr)
> > + goto error;
>
> When kallsyms_lookup_name() returns 0 (symbol not found), is err being set
> to an error code before jumping to the error label? It looks like err will
> still hold the positive return value from strncpy_from_user() (the string
> length), which would be returned to the caller as a success indication.
Good catch. It should set err = -ENOENT.
Thanks,
>
> The error label at the end of the function does:
>
> error:
> kvfree(kprobes);
> kfree(link);
> return err;
>
> This could cause the syscall to return a positive value to userspace instead
> of an error, and also leak a prog reference since link_create() only calls
> bpf_prog_put() when ret < 0.
>
> > + }
> > + if (prog->kprobe_override && !within_error_injection_list(addr)) {
> > + err = -EINVAL;
> > + goto error;
> > + }
>
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/20338242683
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v10 01/30] ring-buffer: Add page statistics to the meta-page
From: Steven Rostedt @ 2026-01-29 0:25 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-2-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:50 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Add two fields pages_touched and pages_lost to the ring-buffer
> meta-page. Those fields are useful to get the number of used pages in
> the ring-buffer.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 02/30] ring-buffer: Store bpage pointers into subbuf_ids
From: Steven Rostedt @ 2026-01-29 0:26 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-3-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:51 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> The subbuf_ids field allows to point to a specific page from the
> ring-buffer based on its ID. As a preparation or the upcoming
> ring-buffer remote support, point this array to the buffer_page instead
> of the buffer_data_page.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 03/30] ring-buffer: Introduce ring-buffer remotes
From: Steven Rostedt @ 2026-01-29 0:26 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-4-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:52 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> A ring-buffer remote is an entity outside of the kernel (most likely a
> firmware or a hypervisor) capable of writing events in a ring-buffer
> following the same format as the tracefs ring-buffer.
>
> To setup the ring-buffer on the kernel side, a description of the pages
> forming the ring-buffer (struct trace_buffer_desc) must be given.
> Callbacks (swap_reader_page and reset) must also be provided.
>
> It is expected from the remote to keep the meta-page updated.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 04/30] ring-buffer: Add non-consuming read for ring-buffer remotes
From: Steven Rostedt @ 2026-01-29 0:26 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-5-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:53 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Hopefully, the remote will only swap pages on the kernel instruction (via
> the swap_reader_page() callback). This means we know at what point the
> ring-buffer geometry has changed. It is therefore possible to rearrange
> the kernel view of that ring-buffer to allow non-consuming read.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 06/30] tracing: Add reset to trace remotes
From: Steven Rostedt @ 2026-01-29 0:27 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-7-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:55 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Allow to reset the trace remote buffer by writing to the Tracefs "trace"
> file. This is similar to the regular Tracefs interface.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 08/30] tracing: Add init callback to trace remotes
From: Steven Rostedt @ 2026-01-29 0:27 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-9-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:57 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Add a .init call back so the trace remote callers can add entries to the
> tracefs directory.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 10/30] tracing: Add events/ root files to trace remotes
From: Steven Rostedt @ 2026-01-29 0:28 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-11-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:43:59 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Just like for the kernel events directory, add 'enable', 'header_page'
> and 'header_event' at the root of the trace remote events/ directory.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 11/30] tracing: Add helpers to create trace remote events
From: Steven Rostedt @ 2026-01-29 0:28 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-12-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:44:00 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> Declaring remote events can be cumbersome let's add a set of macros to
> simplify developers life. The declaration of a remote event is very
> similar to kernel's events:
>
> REMOTE_EVENT(name, id,
> RE_STRUCT(
> re_field(u64 foo)
> ),
> RE_PRINTK("foo=%llu", __entry->foo)
> )
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v10 12/30] ring-buffer: Export buffer_data_page and macros
From: Steven Rostedt @ 2026-01-29 0:28 UTC (permalink / raw)
To: Vincent Donnefort
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: <20260126104419.1649811-13-vdonnefort@google.com>
On Mon, 26 Jan 2026 10:44:01 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> In preparation for allowing the writing of ring-buffer compliant pages
> outside of ring_buffer.c, move buffer_data_page and timestamps encoding
> macros into the publicly available ring_buffer_types.h.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH v5 v5 1/3] docs: tracing/fprobe: Document list filters and :entry/:exit
From: Masami Hiramatsu @ 2026-01-29 0:35 UTC (permalink / raw)
To: Seokwoo Chung
Cc: Steven Rostedt, mhiramat, corbet, shuah, mathieu.desnoyers,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <wqpijkdwziafpuci6js5mtfzro46bre4z7une547crcdzrlm67@kd4fgea5m6ov>
Hi Ryan,
On Sun, 25 Jan 2026 15:23:17 -0500
Seokwoo Chung <seokwoo.chung130@gmail.com> wrote:
> On Tue, Jan 20, 2026 at 03:53:40PM -0500, Steven Rostedt wrote:
> > On Sat, 17 Jan 2026 20:18:13 -0500
> > "Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> >
> > > Update fprobe event documentation to describe comma-separated symbol lists,
> > > exclusions, and explicit suffixes.
> >
> > Usually, the documentation updates comes *after* the changes.
> >
> > -- Steve
> >
> Thanks for the comment. As you noticed, I sent another patch since I forgot to
> put log. That said, please let me know if you want me to continue on this
> series. My apologies on the ordering. I noted after Masami mentioned but I
> misordered when sending. Thank you.
Sorry for replying so late,
Can you fix the kernel test robot's error? I think it is almost done.
Thank you,
>
> Best regards,
> Ryan Chung
> > >
> > > Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> > > ---
> > > Documentation/trace/fprobetrace.rst | 17 ++++++++++++++---
> > > 1 file changed, 14 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/trace/fprobetrace.rst b/Documentation/trace/fprobetrace.rst
> > > index b4c2ca3d02c1..bbcfd57f0005 100644
> > > --- a/Documentation/trace/fprobetrace.rst
> > > +++ b/Documentation/trace/fprobetrace.rst
> > > @@ -25,14 +25,18 @@ Synopsis of fprobe-events
> > > -------------------------
> > > ::
> > >
> > > - f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry
> > > - f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit
> > > + f[:[GRP1/][EVENT1]] SYM[%return] [FETCHARGS] : Single function
> > > + f[:[GRP1/][EVENT1]] SYM[,[!]SYM[,...]][:entry|:exit] [FETCHARGS] :Multiple
> > > + function
> > > t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint
> > >
> > > GRP1 : Group name for fprobe. If omitted, use "fprobes" for it.
> > > GRP2 : Group name for tprobe. If omitted, use "tracepoints" for it.
> > > EVENT1 : Event name for fprobe. If omitted, the event name is
> > > - "SYM__entry" or "SYM__exit".
> > > + - For a single literal symbol, the event name is
> > > + "SYM__entry" or "SYM__exit".
> > > + - For a *list or any wildcard*, an explicit [GRP1/][EVENT1] is
> > > + required; otherwise the parser rejects it.
> > > EVENT2 : Event name for tprobe. If omitted, the event name is
> > > the same as "TRACEPOINT", but if the "TRACEPOINT" starts
> > > with a digit character, "_TRACEPOINT" is used.
> > > @@ -40,6 +44,13 @@ Synopsis of fprobe-events
> > > can be probed simultaneously, or 0 for the default value
> > > as defined in Documentation/trace/fprobe.rst
> > >
> > > + SYM : Function name or comma-separated list of symbols.
> > > + - SYM prefixed with "!" are exclusions.
> > > + - ":entry" suffix means it probes entry of given symbols
> > > + (default)
> > > + - ":exit" suffix means it probes exit of given symbols.
> > > + - "%return" suffix means it probes exit of SYM (single
> > > + symbol).
> > > FETCHARGS : Arguments. Each probe can have up to 128 args.
> > > ARG : Fetch "ARG" function argument using BTF (only for function
> > > entry or tracepoint.) (\*1)
> >
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-01-29 0:37 UTC (permalink / raw)
To: Ackerley Tng
Cc: Alexey Kardashevskiy, cgroups, kvm, linux-doc, linux-fsdevel,
linux-kernel, linux-kselftest, linux-mm, linux-trace-kernel, x86,
akpm, binbin.wu, bp, brauner, chao.p.peng, chenhuacai, corbet,
dave.hansen, dave.hansen, david, dmatlack, erdemaktas, fan.du,
fvdl, haibo1.xu, hannes, hch, hpa, hughd, ira.weiny,
isaku.yamahata, jack, james.morse, jarkko, jgowans, jhubbard,
jroedel, jthoughton, jun.miao, kai.huang, keirf, kent.overstreet,
liam.merwick, maciej.wieczor-retman, mail, maobibo,
mathieu.desnoyers, maz, mhiramat, mhocko, mic, michael.roth,
mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz, oliver.upton,
palmer, pankaj.gupta, paul.walmsley, pbonzini, peterx, pgonda,
prsampat, pvorel, qperret, richard.weiyang, rick.p.edgecombe,
rientjes, rostedt, roypat, rppt, seanjc, shakeel.butt, shuah,
steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <CAEvNRgEuez=JbArRf2SApLAL0usv5-Q6q=nBPOFMHrHGaKAtMw@mail.gmail.com>
On Wed, Jan 28, 2026 at 01:47:50PM -0800, Ackerley Tng wrote:
> Alexey Kardashevskiy <aik@amd.com> writes:
>
> >
> > [...snip...]
> >
> >
>
> Thanks for bringing this up!
>
> > I am trying to make it work with TEE-IO where fd of VFIO MMIO is a dmabuf fd while the rest (guest RAM) is gmemfd. The above suggests that if there is gmemfd - then the memory attributes are handled by gmemfd which is... expected?
> >
>
> I think this is not expected.
>
> IIUC MMIO guest physical addresses don't have an associated memslot, but
> if you managed to get to that line in kvm_gmem_get_memory_attributes(),
> then there is an associated memslot (slot != NULL)?
I think they should have a memslot, shouldn't they? I imagine creating
a memslot from a FD and the FD can be memfd, guestmemfd, dmabuf, etc,
etc ?
> Either way, guest_memfd shouldn't store attributes for guest physical
> addresses that don't belong to some guest_memfd memslot.
>
> I think we need a broader discussion for this on where to store memory
> attributes for MMIO addresses.
>
> I think we should at least have line of sight to storing memory
> attributes for MMIO addresses, in case we want to design something else,
> since we're putting vm_memory_attributes on a deprecation path with this
> series.
I don't know where you want to store them in KVM long term, but they
need to come from the dmabuf itself (probably via a struct
p2pdma_provider) and currently it is OK to assume all DMABUFs are
uncachable MMIO that is safe for the VM to convert into "write
combining" (eg Normal-NC on ARM)
Jason
^ 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 0:41 UTC (permalink / raw)
To: Yaxiong Tian, axboe
Cc: mhiramat, mathieu.desnoyers, corbet, skhan, linux-trace-kernel,
linux-block, linux-kernel, linux-doc
In-Reply-To: <20260128125554.1717261-1-tianyaxiong@kylinos.cn>
Jens,
Can you give me an acked-by on this patch and I can take the series through
my tree.
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?
Thanks,
-- Steve
On Wed, 28 Jan 2026 20:55:54 +0800
Yaxiong Tian <tianyaxiong@kylinos.cn> wrote:
> The init_blk_tracer() function causes significant boot delay as it
> waits for the trace_event_sem lock held by trace_event_update_all().
> Specifically, its child function register_trace_event() requires
> this lock, which is occupied for an extended period during boot.
>
> To resolve this, when the trace_async_init parameter is enabled, the
> execution of primary init_blk_tracer() is moved to the trace_init_wq
> workqueue, allowing it to run asynchronously. and prevent blocking
> the main boot thread.
>
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> index d031c8d80be4..56c7270ec447 100644
> --- a/kernel/trace/blktrace.c
> +++ b/kernel/trace/blktrace.c
> @@ -1832,7 +1832,9 @@ static struct trace_event trace_blk_event = {
> .funcs = &trace_blk_event_funcs,
> };
>
> -static int __init init_blk_tracer(void)
> +static struct work_struct blktrace_works __initdata;
> +
> +static int __init __init_blk_tracer(void)
> {
> if (!register_trace_event(&trace_blk_event)) {
> pr_warn("Warning: could not register block events\n");
> @@ -1852,6 +1854,25 @@ static int __init init_blk_tracer(void)
> return 0;
> }
>
> +static void __init blktrace_works_func(struct work_struct *work)
> +{
> + __init_blk_tracer();
> +}
> +
> +static int __init init_blk_tracer(void)
> +{
> + int ret = 0;
> +
> + if (trace_init_wq && trace_async_init) {
> + INIT_WORK(&blktrace_works, blktrace_works_func);
> + queue_work(trace_init_wq, &blktrace_works);
> + } else {
> + ret = __init_blk_tracer();
> + }
> +
> + return ret;
> +}
> +
> device_initcall(init_blk_tracer);
>
> static int blk_trace_remove_queue(struct request_queue *q)
^ permalink raw reply
* Re: [PATCH v2] iommu: Fix NULL pointer deref when io_page_fault tracepoint fires
From: Steven Rostedt @ 2026-01-29 0:46 UTC (permalink / raw)
To: Daniel Thompson
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel, Will Deacon, Robin Murphy, linux-arm-kernel,
Joerg Roedel
In-Reply-To: <20260128-iommu-io_page_fault_null_fix-v2-1-de047be6dd3a@riscstar.com>
Note, event changes go through the maintainer's tree where the events are
used.
But from a tracing POV:
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
-- Steve
On Wed, 28 Jan 2026 15:48:01 +0000
Daniel Thompson <daniel@riscstar.com> wrote:
> The arm-smmu driver is unable to allocate the blame for a page fault to
> a specific device so it calls report_iommu_fault() with the dev argument
> set to NULL. Normally this doesn't cause anything catastrophic but on a
> system with the io_page_fault tracepoint enabled this results in a NULL
> pointer deref (resulting in a fairly spectacular crash on the hardware
> I'm currently working on).
>
> Fix this by adding logic to the tracepoint to safely propagate NULL.
>
> Fixes: f8f934c180f6 ("iommu/arm-smmu: Add support for driver IOMMU fault handlers")
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> ---
> Changes in v2:
> - Add a Fixes:. It points to the earliest point I can find where it becomes
> possible for the tracepoint to be triggered with dev set to NULL.
> - Link to v1: https://lore.kernel.org/r/20260116-iommu-io_page_fault_null_fix-v1-1-6c20c2e62987@riscstar.com
> ---
> include/trace/events/iommu.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/iommu.h b/include/trace/events/iommu.h
> index 373007e567cb827458a729b8200bbcc1b7d76912..1315193f13b8812ad4e29e6b0c0c66ca806ce08d 100644
> --- a/include/trace/events/iommu.h
> +++ b/include/trace/events/iommu.h
> @@ -131,8 +131,8 @@ DECLARE_EVENT_CLASS(iommu_error,
> TP_ARGS(dev, iova, flags),
>
> TP_STRUCT__entry(
> - __string(device, dev_name(dev))
> - __string(driver, dev_driver_string(dev))
> + __string(device, dev ? dev_name(dev) : NULL)
> + __string(driver, dev ? dev_driver_string(dev) : NULL)
> __field(u64, iova)
> __field(int, flags)
> ),
>
> ---
> base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
> change-id: 20260116-iommu-io_page_fault_null_fix-f81b4e8b5423
>
> Best regards,
^ permalink raw reply
* Re: [PATCHv2 bpf-next 1/6] x86/fgraph: Fix return_to_handler regs.rsp value
From: Steven Rostedt @ 2026-01-29 0:49 UTC (permalink / raw)
To: Jiri Olsa
Cc: Masami Hiramatsu, Josh Poimboeuf, Peter Zijlstra, bpf,
linux-trace-kernel, x86, Yonghong Song, Song Liu, Andrii Nakryiko,
Mahe Tardy
In-Reply-To: <20260126211837.472802-2-jolsa@kernel.org>
On Mon, 26 Jan 2026 22:18:32 +0100
Jiri Olsa <jolsa@kernel.org> wrote:
> The previous change (Fixes commit) messed up the rsp register value,
> which is wrong because it's already adjusted with FRAME_SIZE, we need
> the original rsp value.
>
> This change does not affect fprobe current kernel unwind, the !perf_hw_regs
> path perf_callchain_kernel:
>
> if (perf_hw_regs(regs)) {
> if (perf_callchain_store(entry, regs->ip))
> return;
> unwind_start(&state, current, regs, NULL);
> } else {
> unwind_start(&state, current, NULL, (void *)regs->sp);
> }
>
> which uses pt_regs.sp as first_frame boundary (FRAME_SIZE shift makes
> no difference, unwind stil stops at the right frame).
>
> This change fixes the other path when we want to unwind directly from
> pt_regs sp/fp/ip state, which is coming in following change.
>
> Fixes: 20a0bc10272f ("x86/fgraph,bpf: Fix stack ORC unwind from kprobe_multi return probe")
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
(it passed all my tests too)
-- Steve
^ permalink raw reply
* Re: [PATCHv2 bpf-next 2/6] x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path
From: Steven Rostedt @ 2026-01-29 0:50 UTC (permalink / raw)
To: Jiri Olsa
Cc: Masami Hiramatsu, Josh Poimboeuf, Mahe Tardy, Peter Zijlstra, bpf,
linux-trace-kernel, x86, Yonghong Song, Song Liu, Andrii Nakryiko
In-Reply-To: <20260126211837.472802-3-jolsa@kernel.org>
On Mon, 26 Jan 2026 22:18:33 +0100
Jiri Olsa <jolsa@kernel.org> wrote:
> Mahe reported missing function from stack trace on top of kprobe
> multi program. The missing function is the very first one in the
> stacktrace, the one that the bpf program is attached to.
>
> # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}'
> Attaching 1 probe...
>
> do_syscall_64+134
> entry_SYSCALL_64_after_hwframe+118
>
> ('*' is used for kprobe_multi attachment)
>
> The reason is that the previous change (the Fixes commit) fixed
> stack unwind for tracepoint, but removed attached function address
> from the stack trace on top of kprobe multi programs, which I also
> overlooked in the related test (check following patch).
>
> The tracepoint and kprobe_multi have different stack setup, but use
> same unwind path. I think it's better to keep the previous change,
> which fixed tracepoint unwind and instead change the kprobe multi
> unwind as explained below.
>
> The bpf program stack unwind calls perf_callchain_kernel for kernel
> portion and it follows two unwind paths based on X86_EFLAGS_FIXED
> bit in pt_regs.flags.
>
> When the bit set we unwind from stack represented by pt_regs argument,
> otherwise we unwind currently executed stack up to 'first_frame'
> boundary.
>
> The 'first_frame' value is taken from regs.rsp value, but ftrace_caller
> and ftrace_regs_caller (ftrace trampoline) functions set the regs.rsp
> to the previous stack frame, so we skip the attached function entry.
>
> If we switch kprobe_multi unwind to use the X86_EFLAGS_FIXED bit,
> we set the start of the unwind to the attached function address.
> As another benefit we also cut extra unwind cycles needed to reach
> the 'first_frame' boundary.
>
> The speedup can be measured with trigger bench for kprobe_multi
> program and stacktrace support.
>
> - trigger bench with stacktrace on current code:
>
> kprobe-multi : 0.810 ± 0.001M/s
> kretprobe-multi: 0.808 ± 0.001M/s
>
> - and with the fix:
>
> kprobe-multi : 1.264 ± 0.001M/s
> kretprobe-multi: 1.401 ± 0.002M/s
>
> With the fix, the entry probe stacktrace:
>
> # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}'
> Attaching 1 probe...
>
> __x64_sys_newuname+9
> do_syscall_64+134
> entry_SYSCALL_64_after_hwframe+118
>
> The return probe skips the attached function, because it's no longer
> on the stack at the point of the unwind and this way is the same how
> standard kretprobe works.
>
> # bpftrace -e 'kretprobe:__x64_sys_newuname* { print(kstack)}'
> Attaching 1 probe...
>
> do_syscall_64+134
> entry_SYSCALL_64_after_hwframe+118
>
> Fixes: 6d08340d1e35 ("Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"")
> Reported-by: Mahe Tardy <mahe.tardy@gmail.com>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> arch/x86/include/asm/ftrace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index b08c95872eed..c56e1e63b893 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
(it passed all my tests too)
-- Steve
^ permalink raw reply
* Re: [PATCH AUTOSEL 6.18] tracing: Avoid possible signed 64-bit truncation
From: Steven Rostedt @ 2026-01-29 0:59 UTC (permalink / raw)
To: Sasha Levin
Cc: patches, stable, Ian Rogers, Mathieu Desnoyers,
Masami Hiramatsu (Google), linux-kernel, linux-trace-kernel
In-Reply-To: <20260128223332.2806589-18-sashal@kernel.org>
On Wed, 28 Jan 2026 17:33:16 -0500
Sasha Levin <sashal@kernel.org> wrote:
> LLM Generated explanations, may be completely bogus:
>
> The original buggy code was introduced in v6.15 and later. It's only
> present in 6.15+ kernels.
Interesting self discussion from the LLM.
>
> ### 8. SUMMARY OF ANALYSIS
>
> **The Bug:**
> - The `cmp_mod_entry()` function uses subtraction of two `unsigned long`
> values and returns the result as `int`
> - On 64-bit systems, if addresses differ by more than 2^31 (~2GB), the
> truncation from 64-bit to 32-bit can flip the sign
> - This would cause `bsearch()` to make wrong decisions about search
> direction
> - Result: potentially incorrect module address lookups in trace data
>
> **The Fix:**
> - Replaces arithmetic subtraction with simple comparisons
> - Returns -1, 0, or 1 directly based on comparisons
> - No overflow or truncation possible with the new code
> - Logic is more readable and provably correct
>
> **Stable Criteria Evaluation:**
> 1. ✅ **Obviously correct and tested**: Simple logic, reviewed by
> maintainers
> 2. ✅ **Fixes a real bug**: Yes, a potential comparator correctness bug
> 3. ⚠️ **Important issue**: Moderate - unlikely to trigger (requires >2GB
> address separation) but could cause incorrect trace output
I purposely didn't add Cc: stable because there's basically no chance of
two modules being more than 2GB apart.
> 4. ✅ **Small and contained**: Only changes one function body (~6 lines)
> 5. ✅ **No new features**: Pure bug fix
> 6. ✅ **Applies cleanly**: Should apply to 6.15+ kernels where this code
> exists
>
> **Risk Assessment:**
> - Very low risk - the change is small and the new logic is simpler
> - The original code has a provable bug (integer overflow on truncation)
> - The new code has no such issues
>
> **Concerns:**
> - The code only exists in 6.15+ kernels (introduced March 2025)
> - The bug is "unlikely" per the author (requires addresses >2GB apart)
> - No known real-world reports of this actually causing issues
>
> ### DECISION
>
> This is a valid bug fix that:
> - Fixes a real (though unlikely to trigger) bug in the comparator
> function
> - Is very small and self-contained
> - Has been reviewed and acked by the tracing maintainers
> - Has near-zero regression risk
> - Applies to 6.15+ kernels only
>
> The fix is surgical, obviously correct, and addresses a potential
> correctness issue. While the bug is unlikely to trigger in practice
> (addresses must be >2GB apart), it could cause silent data corruption in
> trace output when it does trigger. The fix is trivial and risk-free.
>
> **YES**
But I see the bot considered the same thing, but because of the risk factor
it decided to take it.
I have no issue with backporting it (I did label it a "fix"). I was
actually wondering if the bot would notice likeliness of it not happening.
It did, but decided to take it for "correctness" reasons vs risk factor.
Nice,
-- Steve
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Sean Christopherson @ 2026-01-29 1:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Ackerley Tng, Alexey Kardashevskiy, cgroups, kvm, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <20260129003753.GZ1641016@ziepe.ca>
On Wed, Jan 28, 2026, Jason Gunthorpe wrote:
> On Wed, Jan 28, 2026 at 01:47:50PM -0800, Ackerley Tng wrote:
> > Alexey Kardashevskiy <aik@amd.com> writes:
> >
> > >
> > > [...snip...]
> > >
> > >
> >
> > Thanks for bringing this up!
> >
> > > I am trying to make it work with TEE-IO where fd of VFIO MMIO is a dmabuf
> > > fd while the rest (guest RAM) is gmemfd. The above suggests that if there
> > > is gmemfd - then the memory attributes are handled by gmemfd which is...
> > > expected?
> > >
> >
> > I think this is not expected.
> >
> > IIUC MMIO guest physical addresses don't have an associated memslot, but
> > if you managed to get to that line in kvm_gmem_get_memory_attributes(),
> > then there is an associated memslot (slot != NULL)?
>
> I think they should have a memslot, shouldn't they? I imagine creating
> a memslot from a FD and the FD can be memfd, guestmemfd, dmabuf, etc,
> etc ?
Yeah, there are two flavors of MMIO for KVM guests. Emulated MMIO, which is
what Ackerley is thinking of, and "host" MMIO (for lack of a better term), which
is what I assume "fd of VFIO MMIO" is referring to.
Emulated MMIO does NOT have memslots[*]. There are some wrinkles and technical
exceptions, e.g. read-only memslots for emulating option ROMs, but by and large,
lack of a memslot means Emulated MMIO.
Host MMIO isn't something KVM really cares about, in the sense that, for the most
part, it's "just another memslot". KVM x86 does need to identify host MMIO for
vendor specific reasons, e.g. to ensure UC memory stays UC when using EPT (MTRRs
are ignored), to create shared mappings when SME is enabled, and to mitigate the
lovely MMIO Stale Data vulnerability.
But those Host MMIO edge cases are almost entirely contained to make_spte() (see
the kvm_is_mmio_pfn() calls). And so the vast, vast majority of "MMIO" code in
KVM is dealing with Emulated MMIO, and when most people talk about MMIO in KVM,
they're also talking about Emulated MMIO.
> > Either way, guest_memfd shouldn't store attributes for guest physical
> > addresses that don't belong to some guest_memfd memslot.
> >
> > I think we need a broader discussion for this on where to store memory
> > attributes for MMIO addresses.
> >
> > I think we should at least have line of sight to storing memory
> > attributes for MMIO addresses, in case we want to design something else,
> > since we're putting vm_memory_attributes on a deprecation path with this
> > series.
>
> I don't know where you want to store them in KVM long term, but they
> need to come from the dmabuf itself (probably via a struct
> p2pdma_provider) and currently it is OK to assume all DMABUFs are
> uncachable MMIO that is safe for the VM to convert into "write
> combining" (eg Normal-NC on ARM)
+1. For guest_memfd, we initially defined per-VM memory attributes to track
private vs. shared. But as Ackerley noted, we are in the process of deprecating
that support, e.g. by making it incompatible with various guest_memfd features,
in favor of having each guest_memfd instance track the state of a given page.
The original guest_memfd design was that it would _only_ hold private pages, and
so tracking private vs. shared in guest_memfd didn't make any sense. As we've
pivoted to in-place conversion, tracking private vs. shared in the guest_memfd
has basically become mandatory. We could maaaaaybe make it work with per-VM
attributes, but it would be insanely complex.
For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
is all or nothing, and can never change, then the only entity that can track that
info is the owner of the dmabuf. And even if the private vs. shared attributes
are constant, tracking it external to KVM makes sense, because then the provider
can simply hardcode %true/%false.
As for _how_ to do that, no matter where the attributes are stored, we're going
to have to teach KVM to play nice with a non-guest_memfd provider of private
memory.
^ permalink raw reply
* [PATCH v2] tracing: trace_mmap.h: fix a kernel-doc warning
From: Randy Dunlap @ 2026-01-29 1:12 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Masami Hiramatsu (Google), Steven Rostedt,
Mathieu Desnoyers, linux-trace-kernel
Add a description of struct reader to resolve a kernel-doc warning:
Warning: include/uapi/linux/trace_mmap.h:43 struct member 'reader' not described in 'trace_buffer_meta'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
v2: move @reader ahead of its struct members (Steven)
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-trace-kernel@vger.kernel.org
include/uapi/linux/trace_mmap.h | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20260128.orig/include/uapi/linux/trace_mmap.h
+++ linux-next-20260128/include/uapi/linux/trace_mmap.h
@@ -10,6 +10,7 @@
* @meta_struct_len: Size of this structure.
* @subbuf_size: Size of each sub-buffer.
* @nr_subbufs: Number of subbfs in the ring-buffer, including the reader.
+ * @reader: The reader composite info structure
* @reader.lost_events: Number of events lost at the time of the reader swap.
* @reader.id: subbuf ID of the current reader. ID range [0 : @nr_subbufs - 1]
* @reader.read: Number of bytes read on the reader subbuf.
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-01-29 1:16 UTC (permalink / raw)
To: Sean Christopherson
Cc: Ackerley Tng, Alexey Kardashevskiy, cgroups, kvm, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <aXqx3_eE0rNh6nP0@google.com>
On Wed, Jan 28, 2026 at 05:03:27PM -0800, Sean Christopherson wrote:
> For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
> is all or nothing, and can never change, then the only entity that can track that
> info is the owner of the dmabuf. And even if the private vs. shared attributes
> are constant, tracking it external to KVM makes sense, because then the provider
> can simply hardcode %true/%false.
Oh my I had not given that bit any thought. My remarks were just about
normal non-CC systems.
So MMIO starts out shared, and then converts to private when the guest
triggers it. It is not all or nothing, there are permanent shared
holes in the MMIO ranges too.
Beyond that I don't know what people are thinking.
Clearly VFIO has to revoke and disable the DMABUF once any of it
becomes private. VFIO will somehow have to know when it changes modes
from the TSM subsystem.
I guess we could have a special channel for KVM to learn the
shared/private page by page from VFIO as some kind of "aware of CC"
importer.
I suppose AMD needs to mangle the RMP when it changes, and KVM has to
do that.
I forget what ARM does, but I seem to recall there is a call to create
a vPCI function and that is what stuffs the S2? So maybe KVM isn't
even involved? (IIRC people were talking that something else would
call the vPCI function but I haven't seen patches)
No idea what x86 does beyond it has to unmap all the MMIO otherwise
the machine crashes :P
Oh man, what a horrible mess to even contemplate. I'm going to bed.
Jason
^ permalink raw reply
* [PATCH] tracing: Fix indentation of return statement in print_trace_fmt()
From: Haoyang LIU @ 2026-01-29 1:39 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
open list:TRACING, open list:TRACING
Cc: tttturtleruss, open list:TRACING, open list:TRACING
The return statement inside the nested if block in print_trace_fmt()
is not properly indented, making the code structure unclear. This was
flagged by smatch as a warning.
Add proper indentation to the return statement to match the kernel
coding style and improve readability.
Signed-off-by: Haoyang LIU <tttturtleruss@gmail.com>
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8bd4ec08fb36..bf0ce2aac177 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4286,7 +4286,7 @@ static enum print_line_t print_trace_fmt(struct trace_iterator *iter)
/* ftrace and system call events are still OK */
if ((event->type > __TRACE_LAST_TYPE) &&
!is_syscall_event(event))
- return print_event_fields(iter, event);
+ return print_event_fields(iter, event);
}
return event->funcs->trace(iter, sym_flags, event);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Jens Axboe @ 2026-01-29 2:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Yaxiong Tian, mhiramat, mathieu.desnoyers, corbet, skhan,
linux-trace-kernel, linux-block, linux-kernel, linux-doc
In-Reply-To: <20260128194104.30051be1@gandalf.local.home>
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>
> 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.
^ permalink raw reply
* Re: [PATCH] tracing: Fix indentation of return statement in print_trace_fmt()
From: Masami Hiramatsu @ 2026-01-29 2:29 UTC (permalink / raw)
To: Haoyang LIU
Cc: Steven Rostedt, Mathieu Desnoyers, open list:TRACING,
open list:TRACING
In-Reply-To: <20260129013954.5325-1-tttturtleruss@gmail.com>
On Thu, 29 Jan 2026 09:39:54 +0800
Haoyang LIU <tttturtleruss@gmail.com> wrote:
> The return statement inside the nested if block in print_trace_fmt()
> is not properly indented, making the code structure unclear. This was
> flagged by smatch as a warning.
>
> Add proper indentation to the return statement to match the kernel
> coding style and improve readability.
>
> Signed-off-by: Haoyang LIU <tttturtleruss@gmail.com>
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks,
> ---
> kernel/trace/trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8bd4ec08fb36..bf0ce2aac177 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -4286,7 +4286,7 @@ static enum print_line_t print_trace_fmt(struct trace_iterator *iter)
> /* ftrace and system call events are still OK */
> if ((event->type > __TRACE_LAST_TYPE) &&
> !is_syscall_event(event))
> - return print_event_fields(iter, event);
> + return print_event_fields(iter, event);
> }
> return event->funcs->trace(iter, sym_flags, event);
> }
> --
> 2.25.1
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 v5 2/3] tracing/fprobe: Support comma-separated symbols and :entry/:exit
From: Masami Hiramatsu @ 2026-01-29 4:24 UTC (permalink / raw)
To: Seokwoo Chung (Ryan)
Cc: rostedt, corbet, shuah, mathieu.desnoyers, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260118011815.56516-3-seokwoo.chung130@gmail.com>
On Sat, 17 Jan 2026 20:18:14 -0500
"Seokwoo Chung (Ryan)" <seokwoo.chung130@gmail.com> wrote:
> - Update DEFINE_FREE to use standard __free()
> - Extend fprobe to support multiple symbols per event. Add parsing logic for
> lists, ! exclusions, and explicit suffixes. Update tracefs/README to reflect
> the new syntax
>
> Signed-off-by: Seokwoo Chung (Ryan) <seokwoo.chung130@gmail.com>
> ---
> kernel/trace/trace.c | 3 +-
> kernel/trace/trace_fprobe.c | 209 +++++++++++++++++++++++++++---------
> 2 files changed, 163 insertions(+), 49 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index baec63134ab6..10cdcc7b194e 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -5578,7 +5578,8 @@ static const char readme_msg[] =
> "\t r[maxactive][:[<group>/][<event>]] <place> [<args>]\n"
> #endif
> #ifdef CONFIG_FPROBE_EVENTS
> - "\t f[:[<group>/][<event>]] <func-name>[%return] [<args>]\n"
> + "\t f[:[<group>/][<event>]] <func-name>[:entry|:exit] [<args>]\n"
> + "\t (single symbols still accept %return)\n"
> "\t t[:[<group>/][<event>]] <tracepoint> [<args>]\n"
> #endif
> #ifdef CONFIG_HIST_TRIGGERS
> diff --git a/kernel/trace/trace_fprobe.c b/kernel/trace/trace_fprobe.c
> index 262c0556e4af..5a2a41eea603 100644
> --- a/kernel/trace/trace_fprobe.c
> +++ b/kernel/trace/trace_fprobe.c
> @@ -187,11 +187,14 @@ DEFINE_FREE(tuser_put, struct tracepoint_user *,
> */
> struct trace_fprobe {
> struct dyn_event devent;
> + char *filter;
> struct fprobe fp;
> + bool list_mode;
> + char *nofilter;
> const char *symbol;
> + struct trace_probe tp;
> bool tprobe;
> struct tracepoint_user *tuser;
> - struct trace_probe tp;
> };
>
> static bool is_trace_fprobe(struct dyn_event *ev)
> @@ -559,6 +562,8 @@ static void free_trace_fprobe(struct trace_fprobe *tf)
> trace_probe_cleanup(&tf->tp);
> if (tf->tuser)
> tracepoint_user_put(tf->tuser);
> + kfree(tf->filter);
> + kfree(tf->nofilter);
> kfree(tf->symbol);
> kfree(tf);
> }
> @@ -838,7 +843,12 @@ static int __register_trace_fprobe(struct trace_fprobe *tf)
> if (trace_fprobe_is_tracepoint(tf))
> return __regsiter_tracepoint_fprobe(tf);
>
> - /* TODO: handle filter, nofilter or symbol list */
> + /* Registration path:
> + * - list_mode: pass filter/nofilter
> + * - single: pass symbol only (legacy)
> + */
> + if (tf->list_mode)
> + return register_fprobe(&tf->fp, tf->filter, tf->nofilter);
> return register_fprobe(&tf->fp, tf->symbol, NULL);
> }
>
> @@ -1154,60 +1164,119 @@ static struct notifier_block tprobe_event_module_nb = {
> };
> #endif /* CONFIG_MODULES */
>
> -static int parse_symbol_and_return(int argc, const char *argv[],
> - char **symbol, bool *is_return,
> - bool is_tracepoint)
> +static bool has_wildcard(const char *s)
> {
> - char *tmp = strchr(argv[1], '%');
> - int i;
> + return s && (strchr(s, '*') || strchr(s, '?'));
> +}
>
> - if (tmp) {
> - int len = tmp - argv[1];
> +static int parse_fprobe_spec(const char *in, bool is_tracepoint,
> + char **base, bool *is_return, bool *list_mode,
> + char **filter, char **nofilter)
> +{
> + char *work __free(kfree) = NULL;
> + char *b __free(kfree) = NULL;
> + char *f __free(kfree) = NULL;
> + char *nf __free(kfree) = NULL;
> + bool legacy_ret = false;
> + bool list = false;
> + const char *p;
> + int ret = 0;
>
> - if (!is_tracepoint && !strcmp(tmp, "%return")) {
> - *is_return = true;
> - } else {
> - trace_probe_log_err(len, BAD_ADDR_SUFFIX);
> - return -EINVAL;
> - }
> - *symbol = kmemdup_nul(argv[1], len, GFP_KERNEL);
> - } else
> - *symbol = kstrdup(argv[1], GFP_KERNEL);
> - if (!*symbol)
> - return -ENOMEM;
> + if (!in || !base || !is_return || !list_mode || !filter || !nofilter)
> + return -EINVAL;
>
> - if (*is_return)
> - return 0;
> + *base = NULL; *filter = NULL; *nofilter = NULL;
> + *is_return = false; *list_mode = false;
>
> if (is_tracepoint) {
> - tmp = *symbol;
> - while (*tmp && (isalnum(*tmp) || *tmp == '_'))
> - tmp++;
> - if (*tmp) {
> - /* find a wrong character. */
> - trace_probe_log_err(tmp - *symbol, BAD_TP_NAME);
> - kfree(*symbol);
> - *symbol = NULL;
> + if (strchr(in, ',') || strchr(in, ':'))
> return -EINVAL;
> - }
> + if (strstr(in, "%return"))
> + return -EINVAL;
These checks look redundant. because below ensures there is no
',', '/' and '%'.
> + for (p = in; *p; p++)
> + if (!isalnum(*p) && *p != '_')
> + return -EINVAL;
Please report parse error via trace_probe_log_err() function so that
user can check what was wrong via tracefs/error_log file. E.g.
trace_probe_log_err(p - in, BAD_TP_NAME);
> + b = kstrdup(in, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
Note: ENOMEM does not need to report via error_log.
> + *base = no_free_ptr(b);
> + return 0;
> }
>
> - /* If there is $retval, this should be a return fprobe. */
> - for (i = 2; i < argc; i++) {
> - tmp = strstr(argv[i], "$retval");
> - if (tmp && !isalnum(tmp[7]) && tmp[7] != '_') {
> - if (is_tracepoint) {
> - trace_probe_log_set_index(i);
> - trace_probe_log_err(tmp - argv[i], RETVAL_ON_PROBE);
> - kfree(*symbol);
> - *symbol = NULL;
> + work = kstrdup(in, GFP_KERNEL);
> + if (!work)
> + return -ENOMEM;
> +
> + p = strstr(work, "%return");
> + if (p && p[7] == '\0') {
> + *is_return = true;
> + legacy_ret = true;
> + *(char *)p = '\0';
> + } else {
> + /*
> + * If "symbol:entry" or "symbol:exit" is given, it is new
> + * style probe.
> + */
> + p = strrchr(work, ':');
> + if (p) {
> + if (!strcmp(p, ":exit")) {
> + *is_return = true;
> + *(char *)p = '\0';
> + } else if (!strcmp(p, ":entry")) {
> + *(char *)p = '\0';
> + } else {
> return -EINVAL;
> }
> - *is_return = true;
> - break;
> }
> }
> - return 0;
> +
> + list = !!strchr(work, ',');
> +
> + if (list && legacy_ret) {
> + return -EINVAL;
> + }
You don't need braces for the above block.
> +
> + if (legacy_ret)
> + *is_return = true;
> +
> + b = kstrdup(work, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
> +
> + if (list) {
Could you make this block as an independent function?
> + char *tmp = b, *tok;
> + size_t fsz, nfsz;
> +
> + fsz = nfsz = strlen(b) + 1;
> +
> + f = kzalloc(fsz, GFP_KERNEL);
> + nf = kzalloc(nfsz, GFP_KERNEL);
> + if (!f || !nf)
> + return -ENOMEM;
> +
> + while ((tok = strsep(&tmp, ",")) != NULL) {
> + char *dst;
> + bool neg = (*tok == '!');
> +
> + if (*tok == '\0') {
> + trace_probe_log_err(tmp - b - 1, BAD_TP_NAME);
> + return -EINVAL;
You missed close brace '}' here. And that makes the build failure.
Can you fix it and run all tests under tools/testing/selftests/ftrace/
with your change?
Thank you,
> +
> + if (neg)
> + tok++;
> + dst = neg ? nf : f;
> + if (dst[0] != '\0')
> + strcat(dst, ",");
> + strcat(dst, tok);
> + }
> + *list_mode = true;
> + }
> +
> + *base = no_free_ptr(b);
> + *filter = no_free_ptr(f);
> + *nofilter = no_free_ptr(nf);
> +
> + return ret;
> }
>
> static int trace_fprobe_create_internal(int argc, const char *argv[],
> @@ -1241,6 +1310,8 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> const char *event = NULL, *group = FPROBE_EVENT_SYSTEM;
> struct module *mod __free(module_put) = NULL;
> const char **new_argv __free(kfree) = NULL;
> + char *parsed_nofilter __free(kfree) = NULL;
> + char *parsed_filter __free(kfree) = NULL;
> char *symbol __free(kfree) = NULL;
> char *ebuf __free(kfree) = NULL;
> char *gbuf __free(kfree) = NULL;
> @@ -1249,6 +1320,7 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> char *dbuf __free(kfree) = NULL;
> int i, new_argc = 0, ret = 0;
> bool is_tracepoint = false;
> + bool list_mode = false;
> bool is_return = false;
>
> if ((argv[0][0] != 'f' && argv[0][0] != 't') || argc < 2)
> @@ -1270,11 +1342,26 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
>
> trace_probe_log_set_index(1);
>
> - /* a symbol(or tracepoint) must be specified */
> - ret = parse_symbol_and_return(argc, argv, &symbol, &is_return, is_tracepoint);
> + /* Parse spec early (single vs list, suffix, base symbol) */
> + ret = parse_fprobe_spec(argv[1], is_tracepoint, &symbol, &is_return,
> + &list_mode, &parsed_filter, &parsed_nofilter);
> if (ret < 0)
> return -EINVAL;
>
> + for (i = 2; i < argc; i++) {
> + char *tmp = strstr(argv[i], "$retval");
> +
> + if (tmp && !isalnum(tmp[7]) && tmp[7] != '_') {
> + if (is_tracepoint) {
> + trace_probe_log_set_index(i);
> + trace_probe_log_err(tmp - argv[i], RETVAL_ON_PROBE);
> + return -EINVAL;
> + }
> + is_return = true;
> + break;
> + }
> + }
> +
> trace_probe_log_set_index(0);
> if (event) {
> gbuf = kmalloc(MAX_EVENT_NAME_LEN, GFP_KERNEL);
> @@ -1287,6 +1374,15 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> }
>
> if (!event) {
> + /*
> + * Event name rules:
> + * - For list/wildcard: require explicit [GROUP/]EVENT
> + * - For single literal: autogenerate symbol__entry/symbol__exit
> + */
> + if (list_mode || has_wildcard(symbol)) {
> + trace_probe_log_err(0, NO_GROUP_NAME);
> + return -EINVAL;
> + }
> ebuf = kmalloc(MAX_EVENT_NAME_LEN, GFP_KERNEL);
> if (!ebuf)
> return -ENOMEM;
> @@ -1322,7 +1418,8 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> NULL, NULL, NULL, sbuf);
> }
> }
> - if (!ctx->funcname)
> +
> + if (!list_mode && !has_wildcard(symbol) && !is_tracepoint)
> ctx->funcname = symbol;
>
> abuf = kmalloc(MAX_BTF_ARGS_LEN, GFP_KERNEL);
> @@ -1356,6 +1453,21 @@ static int trace_fprobe_create_internal(int argc, const char *argv[],
> return ret;
> }
>
> + /* carry list parsing result into tf */
> + if (!is_tracepoint) {
> + tf->list_mode = list_mode;
> + if (parsed_filter) {
> + tf->filter = kstrdup(parsed_filter, GFP_KERNEL);
> + if (!tf->filter)
> + return -ENOMEM;
> + }
> + if (parsed_nofilter) {
> + tf->nofilter = kstrdup(parsed_nofilter, GFP_KERNEL);
> + if (!tf->nofilter)
> + return -ENOMEM;
> + }
> + }
> +
> /* parse arguments */
> for (i = 0; i < argc; i++) {
> trace_probe_log_set_index(i + 2);
> @@ -1442,8 +1554,9 @@ static int trace_fprobe_show(struct seq_file *m, struct dyn_event *ev)
> seq_printf(m, ":%s/%s", trace_probe_group_name(&tf->tp),
> trace_probe_name(&tf->tp));
>
> - seq_printf(m, " %s%s", trace_fprobe_symbol(tf),
> - trace_fprobe_is_return(tf) ? "%return" : "");
> + seq_printf(m, " %s", trace_fprobe_symbol(tf));
> + if (!trace_fprobe_is_tracepoint(tf) && trace_fprobe_is_return(tf))
> + seq_puts(m, ":exit");
>
> for (i = 0; i < tf->tp.nr_args; i++)
> seq_printf(m, " %s=%s", tf->tp.args[i].name, tf->tp.args[i].comm);
> --
> 2.43.0
>
--
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