* Re: [PATCH v3 01/13] rv: Unify DA event handling functions across monitor types
From: Gabriele Monaco @ 2025-12-22 14:45 UTC (permalink / raw)
To: Nam Cao, linux-kernel, Steven Rostedt, linux-trace-kernel
Cc: Tomas Glozar, Juri Lelli, Clark Williams, John Kacur
In-Reply-To: <871pksk3cg.fsf@yellow.woof>
On Thu, 2025-12-18 at 08:04 +0700, Nam Cao wrote:
> I think this overexplains. I would just explain the "WHY", then the
> general idea how the patch solves the problem. Let the diff speaks for
> the rest.
>
> Perhaps something like:
>
> The DA event handling functions are mostly duplicated for
> differerent monitor types, because per-task monitors' functions
> require a task_struct parameter while the others do not.
>
> Unify the functions, handle the difference by always passing a
> da_id_type which is the task's pid for per-task monitor but is
> ignored for the other types.
>
Good point, I'll squeeze it.
Thanks,
Gabriele
> Regardless:
>
> Reviewed-by: Nam Cao <namcao@linutronix.de>
>
> Nam
^ permalink raw reply
* Re: [PATCH v3 02/13] rv: Add Hybrid Automata monitor type
From: Gabriele Monaco @ 2025-12-22 15:26 UTC (permalink / raw)
To: Nam Cao, linux-kernel, Steven Rostedt, Masami Hiramatsu,
linux-trace-kernel
Cc: Tomas Glozar, Juri Lelli, Clark Williams, John Kacur
In-Reply-To: <87y0n0ib6k.fsf@yellow.woof>
On Thu, 2025-12-18 at 12:57 +0700, Nam Cao wrote:
> Gabriele Monaco <gmonaco@redhat.com> writes:
> > +static inline void ha_start_timer_ns(struct ha_monitor *ha_mon, enum envs
> > env,
> > + u64 expire, u64 time_ns)
> > +{
> > + u64 passed = ha_invariant_passed_ns(ha_mon, env, expire, time_ns);
> > +
> > + ha_start_timer_jiffy(ha_mon, ENV_MAX_STORED,
> > + nsecs_to_jiffies(expire - passed) + 1,
> > time_ns);
>
> What is the +1 for? I guess to prevent it being rounded down to zero? If
> so, maybe we should do
>
> nsecs_to_jiffies(expire - passed + TICK_NSEC - 1)
>
> instead.
Yeah that was the reason and your suggestion is actually cleaner.
Thanks,
Gabriele
>
> Anyway, no big deal:
> Reviewed-by: Nam Cao <namcao@linutronix.de>
^ permalink raw reply
* Re: [External Mail]Re: [PATCH v8] dma-buf: add some tracepoints to debug.
From: Steven Rostedt @ 2025-12-22 17:04 UTC (permalink / raw)
To: 高翔
Cc: Christian König, Xiang Gao, sumit.semwal@linaro.org,
mhiramat@kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com, dhowells@redhat.com,
kuba@kernel.org, brauner@kernel.org, akpm@linux-foundation.org,
linux-trace-kernel@vger.kernel.org
In-Reply-To: <e9046d36a74d4eefbe85936fd2ff7cba@xiaomi.com>
On Mon, 22 Dec 2025 01:41:28 +0000
高翔 <gaoxiang17@xiaomi.com> wrote:
> > there was some whitespace issues with the macro.
>
> I check the patch with checkpatch.pl, couldn't find whitespace issues.
>
> > +DECLARE_EVENT_CLASS(dma_buf,
> > +
> > + TP_PROTO(struct dma_buf *dmabuf),
> > +
> > + TP_ARGS(dmabuf),
> > +
> > + TP_STRUCT__entry(
> > + __string(exp_name, dmabuf->exp_name)
> > + __field(size_t, size)
> > + __field(ino_t, ino)
> > + ),
These don't follow checkpatch recommendations for whitespace, because they
are "special". Please update these to look more like a structure:
TP_STRUCT__entry(
__string( exp_name, dmabuf->exp_name)
__field( size_t, size)
__field( ino_t, ino)
),
> > +
> > + TP_fast_assign(
> > + __assign_str(exp_name);
> > + __entry->size = dmabuf->size;
> > + __entry->ino = dmabuf->file->f_inode->i_ino;
> > + ),
> > +
> > + TP_printk("exp_name=%s size=%zu ino=%lu",
> > + __get_str(exp_name),
> > + __entry->size,
> > + __entry->ino)
> > +);
> > +
> > +DECLARE_EVENT_CLASS(dma_buf_attach_dev,
> > +
> > + TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
> > + bool is_dynamic, struct device *dev),
> > +
> > + TP_ARGS(dmabuf, attach, is_dynamic, dev),
> > +
> > + TP_STRUCT__entry(
> > + __string(dev_name, dev_name(dev))
> > + __string(exp_name, dmabuf->exp_name)
> > + __field(size_t, size)
> > + __field(ino_t, ino)
> > + __field(struct dma_buf_attachment *, attach)
> > + __field(bool, is_dynamic)
> > + ),
Same here too:
TP_STRUCT__entry(
__string( dev_name, dev_name(dev))
__string( exp_name, dmabuf->exp_name)
__field( size_t, size)
__field( ino_t, ino)
__field( struct dma_buf_attachment *, attach)
__field( bool, is_dynamic)
),
> > +
> > + TP_fast_assign(
> > + __assign_str(dev_name);
> > + __assign_str(exp_name);
> > + __entry->size = dmabuf->size;
> > + __entry->ino = dmabuf->file->f_inode->i_ino;
> > + __entry->is_dynamic = is_dynamic;
> > + __entry->attach = attach;
> > + ),
> > +
> > + TP_printk("exp_name=%s size=%zu ino=%lu attachment:%p is_dynamic=%d dev_name=%s",
> > + __get_str(exp_name),
> > + __entry->size,
> > + __entry->ino,
> > + __entry->attach,
> > + __entry->is_dynamic,
> > + __get_str(dev_name))
> > +);
> > +
> > +DECLARE_EVENT_CLASS(dma_buf_fd,
> > +
> > + TP_PROTO(struct dma_buf *dmabuf, int fd),
> > +
> > + TP_ARGS(dmabuf, fd),
> > +
> > + TP_STRUCT__entry(
> > + __string(exp_name, dmabuf->exp_name)
> > + __field(size_t, size)
> > + __field(ino_t, ino)
> > + __field(int, fd)
> > + ),
And the above.
-- Steve
> > +
> > + TP_fast_assign(
> > + __assign_str(exp_name);
> > + __entry->size = dmabuf->size;
> > + __entry->ino = dmabuf->file->f_inode->i_ino;
> > + __entry->fd = fd;
> > + ),
> > +
> > + TP_printk("exp_name=%s size=%zu ino=%lu fd=%d",
> > + __get_str(exp_name),
> > + __entry->size,
> > + __entry->ino,
> > + __entry->fd)
> > +);
> > +
^ permalink raw reply
* Re: [PATCH 2/2] bpf: Implement kretprobe fallback for kprobe multi link
From: Steven Rostedt @ 2025-12-22 17:15 UTC (permalink / raw)
To: liujing40
Cc: menglong.dong, andrii, ast, bpf, daniel, eddyz87, haoluo,
john.fastabend, jolsa, kpsingh, linux-kernel, linux-trace-kernel,
liujing40, martin.lau, mhiramat, sdf, song, yonghong.song
In-Reply-To: <20251222080253.2314895-1-liujing40@xiaomi.com>
On Mon, 22 Dec 2025 16:02:53 +0800
liujing40 <liujing.root@gmail.com> wrote:
> The Dynamic ftrace feature is not enabled in Android for security reasons,
> forcing us to fall back on kretprobe.
Really? I would say kretprobe is a much bigger security risk than ftrace.
Ftrace only attaches to a set of defined functions and anything that is
enabled is displayed in /sys/kernel/tracing/enabled_functions (for security
reasons!)
Whereas kretprobe can attach to anything, and call anything. Not to
mention, there's no way to know if a kretprobe is there or not. So rootkits
that would use this can most definitely go under the wire, whereas they
can't with ftrace.
So if they disable ftrace for security reasons, they most definitely should
be disabling kprobes!
-- Steve
> https://source.android.com/docs/core/tests/debug/ftrace#dftrace
>
> I will provide the benchmark test results as soon as possible.
^ permalink raw reply
* Re: [RFC bpf PATCH 0/2] bpf: Fix memory access tags in helper prototypes
From: Amery Hung @ 2025-12-22 19:29 UTC (permalink / raw)
To: Zesen Liu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan, bpf,
linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Shuran Liu, Peili Gao, Haoran Ni
In-Reply-To: <20251220-helper_proto-v1-0-2206e0d9422d@gmail.com>
On Sat, Dec 20, 2025 at 3:35 AM Zesen Liu <ftyghome@gmail.com> wrote:
>
> Hi,
>
> This series adds missing memory access tags (MEM_RDONLY or MEM_WRITE) to
> several bpf helper function prototypes that use ARG_PTR_TO_MEM but lack the
> correct type annotation.
>
> Missing memory access tags in helper prototypes can lead to critical
> correctness issues when the verifier tries to perform code optimization.
> After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type
> tracking"), the verifier relies on the memory access tags, rather than
> treating all arguments in helper functions as potentially modifying the
> pointed-to memory.
>
> We have already seen several reports regarding this:
>
> - commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's
> output buffer") adds MEM_WRITE to bpf_d_path;
> - commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name
> args") adds MEM_WRITE to bpf_sysctl_get_name.
>
> This series looks through all prototypes in the kernel and completes the
> tags. In addition, this series also adds selftests for some of these
> functions.
>
> I marked the series as RFC since the introduced selftests are fragile and
> ad hoc (similar to the previously added selftests). The original goal of
> these tests is to reproduce the case where the verifier wrongly optimizes
> reads after the helper function is called. However, triggering the error
> often requires carefully designed code patterns. For example, I had to
> explicitly use "if (xx != 0)" in my attached tests, because using memcmp
> will not reproduce the issue. This makes the reproduction heavily dependent
> on the verifier's internal optimization logic and clutters the selftests
> with specific, unnatural patterns.
>
> Some cases are also hard to trigger by selftests. For example, I couldn't
> find a triggering pattern for bpf_read_branch_records, since the
> execution of program seems to be messed up by wrong tags. For
> bpf_skb_fib_lookup, I also failed to reproduce it because the argument
> needs content on entry, but the verifier seems to only enable this
> optimization for fully empty buffers.
>
> Since adding selftests does not help with existing issues or prevent future
> occurrences of similar problems, I believe one way to resolve it is to
> statically restrict ARG_PTR_TO_MEM from appearing without memory access
> tags. Using ARG_PTR_TO_MEM alone without tags is nonsensical because:
>
> - If the helper does not change the argument, missing MEM_RDONLY causes
> the verifier to incorrectly reject a read-only buffer.
Perhaps you are conflating one of your proposals here? This is fine
currently. ARG_PTR_TO_MEM without any annotation is viewed as BPF_READ
so passing a read-only buffer should work.
> - If the helper does change the argument, missing MEM_WRITE causes the
> verifier to incorrectly assume the memory is unchanged, leading to
> potential errors.
>
> I am still wondering, if we agree on the above, how should we enforce this
> restriction? Should we let ARG_PTR_TO_MEM imply MEM_WRITE semantics by
> default, and change ARG_PTR_TO_MEM | MEM_RDONLY to ARG_CONST_PTR_TO_MEM? Or
> should we add a check in the verifier to ensure ARG_PTR_TO_MEM always comes
> with an access tag (though this seems to only catch errors at
> runtime/testing)?
I think it is better to make the MEM_WRITE, MEM_RDONLY annotation
explicit and check it in the verifier.
Flipping the default MEM_RDONLY semantic to MEM_WRITE does not prevent
a similar bug in the future when we have helpers/optimizations/checks
rely on an implicit semantic.
>
> Any insights and comments are welcome. If the individual fix patches for
> the prototypes look correct, I would also really appreciate it if they
> could be merged ahead of the discussion.
>
> Thanks,
>
> Zesen Liu
>
> Signed-off-by: Zesen Liu <ftyghome@gmail.com>
> ---
> Zesen Liu (2):
> bpf: Fix memory access tags in helper prototypes
> selftests/bpf: add regression tests for snprintf and get_stack helpers
>
> kernel/bpf/helpers.c | 2 +-
> kernel/trace/bpf_trace.c | 6 +++---
> net/core/filter.c | 8 ++++----
> tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c | 15 +++++++++++++--
> tools/testing/selftests/bpf/prog_tests/snprintf.c | 6 ++++++
> tools/testing/selftests/bpf/prog_tests/snprintf_btf.c | 3 +++
> tools/testing/selftests/bpf/progs/netif_receive_skb.c | 13 ++++++++++++-
> tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 11 ++++++++++-
> tools/testing/selftests/bpf/progs/test_snprintf.c | 12 ++++++++++++
> 9 files changed, 64 insertions(+), 12 deletions(-)
> ---
> base-commit: 22cc16c04b7893d8fc22810599f49a305d600b9e
> change-id: 20251220-helper_proto-fb6e64182467
>
> Best regards,
> --
> Zesen Liu <ftyghome@gmail.com>
>
>
^ permalink raw reply
* Re: [RFC PATCH bpf 1/2] bpf: Fix memory access tags in helper prototypes
From: Amery Hung @ 2025-12-22 19:29 UTC (permalink / raw)
To: Zesen Liu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan, bpf,
linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Shuran Liu, Peili Gao, Haoran Ni
In-Reply-To: <20251220-helper_proto-v1-1-2206e0d9422d@gmail.com>
On Sat, Dec 20, 2025 at 3:35 AM Zesen Liu <ftyghome@gmail.com> wrote:
>
> After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"),
> the verifier started relying on the access type tags in helper
> function prototypes to perform memory access optimizations.
>
> Currently, several helper functions utilizing ARG_PTR_TO_MEM lack the
> corresponding MEM_RDONLY or MEM_WRITE tags. This omission causes the
> verifier to incorrectly assume that the buffer contents are unchanged
> across the helper call. Consequently, the verifier may optimize away
> subsequent reads based on this wrong assumption, leading to correctness
> issues.
>
> Similar issues were recently addressed for specific helpers in commit
> ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer")
> and commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args").
>
> Fix these prototypes by adding the correct memory access tags.
>
> Fixes: 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking")
> Co-developed-by: Shuran Liu <electronlsr@gmail.com>
> Signed-off-by: Shuran Liu <electronlsr@gmail.com>
> Co-developed-by: Peili Gao <gplhust955@gmail.com>
> Signed-off-by: Peili Gao <gplhust955@gmail.com>
> Co-developed-by: Haoran Ni <haoran.ni.cs@gmail.com>
> Signed-off-by: Haoran Ni <haoran.ni.cs@gmail.com>
> Signed-off-by: Zesen Liu <ftyghome@gmail.com>
> ---
> kernel/bpf/helpers.c | 2 +-
> kernel/trace/bpf_trace.c | 6 +++---
> net/core/filter.c | 8 ++++----
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> index db72b96f9c8c..f66284f8ec2c 100644
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c
> @@ -1077,7 +1077,7 @@ const struct bpf_func_proto bpf_snprintf_proto = {
> .func = bpf_snprintf,
> .gpl_only = true,
> .ret_type = RET_INTEGER,
> - .arg1_type = ARG_PTR_TO_MEM_OR_NULL,
> + .arg1_type = ARG_PTR_TO_MEM_OR_NULL | MEM_WRITE,
> .arg2_type = ARG_CONST_SIZE_OR_ZERO,
> .arg3_type = ARG_PTR_TO_CONST_STR,
> .arg4_type = ARG_PTR_TO_MEM | PTR_MAYBE_NULL | MEM_RDONLY,
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index fe28d86f7c35..59c2394981c7 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -1022,7 +1022,7 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = {
> .func = bpf_snprintf_btf,
> .gpl_only = false,
> .ret_type = RET_INTEGER,
> - .arg1_type = ARG_PTR_TO_MEM,
> + .arg1_type = ARG_PTR_TO_MEM | MEM_WRITE,
> .arg2_type = ARG_CONST_SIZE,
> .arg3_type = ARG_PTR_TO_MEM | MEM_RDONLY,
> .arg4_type = ARG_CONST_SIZE,
> @@ -1526,7 +1526,7 @@ static const struct bpf_func_proto bpf_read_branch_records_proto = {
> .gpl_only = true,
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_CTX,
> - .arg2_type = ARG_PTR_TO_MEM_OR_NULL,
> + .arg2_type = ARG_PTR_TO_MEM_OR_NULL | MEM_WRITE,
> .arg3_type = ARG_CONST_SIZE_OR_ZERO,
> .arg4_type = ARG_ANYTHING,
> };
> @@ -1661,7 +1661,7 @@ static const struct bpf_func_proto bpf_get_stack_proto_raw_tp = {
> .gpl_only = true,
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_CTX,
> - .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
> + .arg2_type = ARG_PTR_TO_UNINIT_MEM,
> .arg3_type = ARG_CONST_SIZE_OR_ZERO,
> .arg4_type = ARG_ANYTHING,
> };
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 616e0520a0bb..6e07bb994aa7 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -6399,7 +6399,7 @@ static const struct bpf_func_proto bpf_xdp_fib_lookup_proto = {
> .gpl_only = true,
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_CTX,
> - .arg2_type = ARG_PTR_TO_MEM,
> + .arg2_type = ARG_PTR_TO_MEM | MEM_WRITE,
> .arg3_type = ARG_CONST_SIZE,
> .arg4_type = ARG_ANYTHING,
> };
> @@ -6454,7 +6454,7 @@ static const struct bpf_func_proto bpf_skb_fib_lookup_proto = {
> .gpl_only = true,
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_CTX,
> - .arg2_type = ARG_PTR_TO_MEM,
> + .arg2_type = ARG_PTR_TO_MEM | MEM_WRITE,
> .arg3_type = ARG_CONST_SIZE,
> .arg4_type = ARG_ANYTHING,
> };
> @@ -8010,7 +8010,7 @@ static const struct bpf_func_proto bpf_tcp_raw_gen_syncookie_ipv4_proto = {
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_FIXED_SIZE_MEM,
> .arg1_size = sizeof(struct iphdr),
> - .arg2_type = ARG_PTR_TO_MEM,
> + .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
> .arg3_type = ARG_CONST_SIZE_OR_ZERO,
> };
>
> @@ -8042,7 +8042,7 @@ static const struct bpf_func_proto bpf_tcp_raw_gen_syncookie_ipv6_proto = {
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_FIXED_SIZE_MEM,
> .arg1_size = sizeof(struct ipv6hdr),
> - .arg2_type = ARG_PTR_TO_MEM,
> + .arg2_type = ARG_PTR_TO_MEM | MEM_RDONLY,
> .arg3_type = ARG_CONST_SIZE_OR_ZERO,
> };
>
I did a quick search and there is one helper slipping. We should also
annotate arg1_type of bpf_kallsyms_lookup_name with MEM_RDONLY.
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v3] Documentation/rv: Fix dead link to monitor_synthesis.rst
From: Jonathan Corbet @ 2025-12-22 22:25 UTC (permalink / raw)
To: Steven Rostedt, Gabriele Monaco
Cc: Soham Metha, linux-kernel-mentees, shuah, skhan, namcao,
mathieu.desnoyers, mhiramat, bagasdotme, linux-kernel,
linux-trace-kernel, linux-doc
In-Reply-To: <20251204101415.284a7a96@gandalf.local.home>
Steven Rostedt <rostedt@goodmis.org> writes:
> On Thu, 04 Dec 2025 07:36:57 +0100
> Gabriele Monaco <gmonaco@redhat.com> wrote:
>
>> Anyway looks good to me.
>>
>> Acked-by: Gabriele Monaco <gmonaco@redhat.com>
>
> Jon,
>
> Care to take this through your tree? Gabriele is the maintainer of this
> code.
Done (finally).
Thanks,
jon
^ permalink raw reply
* Re: [PATCH V2] blktrace: log dropped REQ_OP_ZONE_XXX events ver1
From: Jens Axboe @ 2025-12-22 23:28 UTC (permalink / raw)
To: Damien Le Moal, Chaitanya Kulkarni, johannes.thumshirn
Cc: rostedt, mhiramat, mathieu.desnoyers, martin.petersen,
linux-block, linux-trace-kernel
In-Reply-To: <bd88af0b-be00-4f1b-b089-6fce986e3cfe@kernel.org>
On 12/19/25 4:55 PM, Damien Le Moal wrote:
> On 10/29/25 02:32, Chaitanya Kulkarni wrote:
>> Add informational messages during blktrace setup when version 1 tools
>> are used on kernels with CONFIG_BLK_DEV_ZONED enabled. This alerts users
>> that REQ_OP_ZONE_* events will be dropped and suggests upgrading to
>> blktrace tools version 2 or later.
>>
>> The warning is printed once during trace setup to inform users about
>> the limitation without spamming the logs during tracing operations.
>> Version 2 blktrace tools properly handle zone management operations
>> (zone reset, zone open, zone close, zone finish, zone append) that
>> were added for zoned block devices.
>>
>> Example output:
>>
>> blktests (master) # ./check blktrace
>> blktrace/001 (blktrace zone management command tracing) [passed]
>> runtime 0.110s ... 3.917s
>> blktrace/002 (blktrace ftrace corruption with sysfs trace) [passed]
>> runtime 0.333s ... 0.608s
>> blktests (master) # dmesg -c
>> [ 57.610592] blktrace: nullb0: blktrace events for REQ_OP_ZONE_XXX will be dropped
>> [ 57.610603] blktrace: use blktrace tools version >= 2 to track REQ_OP_ZONE_XXX
>>
>> This helps users understand why zone operation traces may be missing
>> when using older blktrace tool versions with modern kernels that
>> support REQ_OP_ZONE_XXX in blktrace.
>>
>> Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
>> ---
>> v1->v2 :-
>>
>> Remove the extra () around IS_ENABLED(CONFIG_BLK_DEV_ZONED). (Jens)
>> Add a space after device name in first pr_info(). (Jens)
>>
>> ---
>> kernel/trace/blktrace.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
>> index e4f26ddb7ee2..4a37d9aa0481 100644
>> --- a/kernel/trace/blktrace.c
>> +++ b/kernel/trace/blktrace.c
>> @@ -739,6 +739,12 @@ static void blk_trace_setup_finalize(struct request_queue *q,
>> */
>> strreplace(buts->name, '/', '_');
>>
>> + if (version == 1 && IS_ENABLED(CONFIG_BLK_DEV_ZONED)) {
>> + pr_info("%s: blktrace events for REQ_OP_ZONE_XXX will be dropped\n",
>> + name);
>> + pr_info("use blktrace tools version >= 2 to track REQ_OP_ZONE_XXX\n");
>
> Please change REQ_OP_ZONE_XXX to "zone operations" in these messages. That is a
> little more general, so better I think since we also trace zone write
> plug/unplug events, which are not REQ_OP_ZONE_XXX.
Agree, REQ_OP_ZONE_XXX means nothing in userspace.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH V2] blktrace: log dropped REQ_OP_ZONE_XXX events ver1
From: Chaitanya Kulkarni @ 2025-12-23 2:13 UTC (permalink / raw)
To: Jens Axboe, Damien Le Moal
Cc: rostedt@goodmis.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com, johannes.thumshirn@wdc.com,
Chaitanya Kulkarni, martin.petersen@oracle.com,
linux-block@vger.kernel.org, linux-trace-kernel@vger.kernel.org
In-Reply-To: <03a59f8b-c139-43e0-94cb-80cee108f939@kernel.dk>
On 12/22/25 3:28 PM, Jens Axboe wrote:
>>> */
>>> strreplace(buts->name, '/', '_');
>>>
>>> + if (version == 1 && IS_ENABLED(CONFIG_BLK_DEV_ZONED)) {
>>> + pr_info("%s: blktrace events for REQ_OP_ZONE_XXX will be dropped\n",
>>> + name);
>>> + pr_info("use blktrace tools version >= 2 to track REQ_OP_ZONE_XXX\n");
>> Please change REQ_OP_ZONE_XXX to "zone operations" in these messages. That is a
>> little more general, so better I think since we also trace zone write
>> plug/unplug events, which are not REQ_OP_ZONE_XXX.
> Agree, REQ_OP_ZONE_XXX means nothing in userspace.
>
> -- Jens Axboe
Thanks Damien and Jens for comment.
Will send out V3 soon.
-ck
^ permalink raw reply
* Re: [PATCH v4 6/7] LoongArch: BPF: Enhance the bpf_arch_text_poke() function
From: Hengqi Chen @ 2025-12-23 2:23 UTC (permalink / raw)
To: Chenghao Duan
Cc: yangtiezhu, rostedt, mhiramat, mark.rutland, chenhuacai, kernel,
zhangtianyang, masahiroy, linux-kernel, loongarch, bpf,
youling.tang, jianghaoran, vincent.mc.li, linux-trace-kernel
In-Reply-To: <20251222015010.GA119291@chenghao-pc>
On Mon, Dec 22, 2025 at 9:50 AM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
>
> On Sat, Dec 20, 2025 at 10:07:25PM +0800, Hengqi Chen wrote:
> > On Wed, Dec 17, 2025 at 2:15 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> > >
> > > Enhance the bpf_arch_text_poke() function to enable accurate location
> > > of BPF program entry points.
> > >
> > > When modifying the entry point of a BPF program, skip the move t0, ra
> > > instruction to ensure the correct logic and copy of the jump address.
> > >
> > > Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> > > ---
> > > arch/loongarch/net/bpf_jit.c | 15 ++++++++++++++-
> > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> > > index 3dbabacc8856..0c16a1b18e8f 100644
> > > --- a/arch/loongarch/net/bpf_jit.c
> > > +++ b/arch/loongarch/net/bpf_jit.c
> > > @@ -1290,6 +1290,10 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> > > void *new_addr)
> >
> > The signature of bpf_arch_text_poke() was changed in v6.19 ([1]), please rebase.
> >
> > [1]: https://github.com/torvalds/linux/commit/ae4a3160d19cd16b874737ebc1798c7bc2fe3c9e
>
> Thank you for your review and for pointing out the API change in v6.19.
>
> I believe my patch series already accounts for this. It was developed on
> top of commit ae4a3160d19c ("bpf: specify the old and new poke_type for bpf_arch_text_poke"),
> so all modifications to bpf_arch_text_poke() call sites within my
> patches should already be using the updated signature.
Fine, it seems like the LoongArch tree is not up-to-date.
>
> Please let me know if you find any inconsistencies or if further
> adjustments are needed.
>
> Best regards,
> Chenghao
>
> >
> > > {
> > > int ret;
> > > + unsigned long size = 0;
> > > + unsigned long offset = 0;
> > > + char namebuf[KSYM_NAME_LEN];
> > > + void *image = NULL;
> > > bool is_call;
> > > u32 old_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> > > u32 new_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> > > @@ -1297,9 +1301,18 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> > > /* Only poking bpf text is supported. Since kernel function entry
> > > * is set up by ftrace, we rely on ftrace to poke kernel functions.
> > > */
> > > - if (!is_bpf_text_address((unsigned long)ip))
> > > + if (!__bpf_address_lookup((unsigned long)ip, &size, &offset, namebuf))
> > > return -ENOTSUPP;
> > >
> > > + image = ip - offset;
> > > + /* zero offset means we're poking bpf prog entry */
> > > + if (offset == 0)
> > > + /* skip to the nop instruction in bpf prog entry:
> > > + * move t0, ra
> > > + * nop
> > > + */
> > > + ip = image + LOONGARCH_INSN_SIZE;
> > > +
> > > is_call = old_t == BPF_MOD_CALL;
> > > ret = emit_jump_or_nops(old_addr, ip, old_insns, is_call);
> > > if (ret)
> > > --
> > > 2.25.1
> > >
^ permalink raw reply
* Re: [RFC bpf PATCH 0/2] bpf: Fix memory access tags in helper prototypes
From: Zesen Liu @ 2025-12-23 3:15 UTC (permalink / raw)
To: Amery Hung
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan, bpf,
linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Shuran Liu, Peili Gao, Haoran Ni
In-Reply-To: <CAMB2axPpB7Km=_7J_QTcQV8SvuFMKqg-_fCyRHEZKNfr7WL2Gg@mail.gmail.com>
Apologies for the resend due to an incorrect configuration in my mail client.
Thanks for your comment!
> On Dec 23, 2025, at 03:29, Amery Hung <ameryhung@gmail.com> wrote:
>
> Perhaps you are conflating one of your proposals here? This is fine
> currently. ARG_PTR_TO_MEM without any annotation is viewed as BPF_READ
> so passing a read-only buffer should work.
Actually, that is not the case. I tested this again, and ARG_PTR_TO_MEM
without MEM_RDONLY does reject read-only buffers. You can reproduce this
behavior with test_d_path_check_rdonly_mem in selftests by removing its
arg2’s MEM_WRITE tag.
> I think it is better to make the MEM_WRITE, MEM_RDONLY annotation
> explicit and check it in the verifier.
>
> Flipping the default MEM_RDONLY semantic to MEM_WRITE does not prevent
> a similar bug in the future when we have helpers/optimizations/checks
> rely on an implicit semantic.
The current default semantic is in an inconsistent state: it implies
neither MEM_RDONLY nor MEM_WRITE. A naked ARG_PTR_TO_MEM rejects
read-only buffers, yet tells the verifier that the helper does not modify the memory.
I see two ways to resolve this ambiguity:
1) Enforce explicit memory access tags (disallow naked ARG_PTR_TO_MEM) as I
proposed eariler; or
2) Change ARG_PTR_TO_MEM semantics to behave exactly like
ARG_PTR_TO_MEM | MEM_RDONLY.
I would appreciate your thoughts on this. :)
Thanks,
Zesen Liu
^ permalink raw reply
* Re: [RFC PATCH bpf 1/2] bpf: Fix memory access tags in helper prototypes
From: Zesen Liu @ 2025-12-23 3:22 UTC (permalink / raw)
To: Amery Hung
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Matt Bobrowski, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Daniel Xu, Shuah Khan, bpf,
linux-kernel, linux-trace-kernel, netdev, linux-kselftest,
Shuran Liu, Peili Gao, Haoran Ni
In-Reply-To: <CAMB2axPcJ=U69xyyyY_7og8OALRCbOgeppQv416k9yvMiD9CvQ@mail.gmail.com>
> On Dec 23, 2025, at 03:29, Amery Hung <ameryhung@gmail.com> wrote:
>
> I did a quick search and there is one helper slipping. We should also
> annotate arg1_type of bpf_kallsyms_lookup_name with MEM_RDONLY.
Good catch, thanks! I will address this once we reach a conclusion
on the ARG_PTR_TO_MEM semantics.
Thanks,
Zesen Liu
^ permalink raw reply
* [PATCH v9] dma-buf: add some tracepoints to debug.
From: Xiang Gao @ 2025-12-23 3:27 UTC (permalink / raw)
To: sumit.semwal, christian.koenig, rostedt, mhiramat
Cc: linux-media, dri-devel, linux-kernel, mathieu.desnoyers, dhowells,
kuba, brauner, akpm, linux-trace-kernel, gaoxiang17
From: gaoxiang17 <gaoxiang17@xiaomi.com>
Since we can only inspect dmabuf by iterating over process FDs or the
dmabuf_list, we need to add our own tracepoints to track its status in
real time in production.
For example:
binder:3016_1-3102 [006] ...1. 255.126521: dma_buf_export: exp_name=qcom,system size=12685312 ino=2738
binder:3016_1-3102 [006] ...1. 255.126528: dma_buf_fd: exp_name=qcom,system size=12685312 ino=2738 fd=8
binder:3016_1-3102 [006] ...1. 255.126642: dma_buf_mmap_internal: exp_name=qcom,system size=28672 ino=2739
kworker/6:1-86 [006] ...1. 255.127194: dma_buf_put: exp_name=qcom,system size=12685312 ino=2738
RenderThread-9293 [006] ...1. 316.618179: dma_buf_get: exp_name=qcom,system size=12771328 ino=2762 fd=176
RenderThread-9293 [006] ...1. 316.618195: dma_buf_dynamic_attach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
RenderThread-9293 [006] ...1. 318.878220: dma_buf_detach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
---
drivers/dma-buf/dma-buf.c | 51 ++++++++++-
include/trace/events/dma_buf.h | 157 +++++++++++++++++++++++++++++++++
2 files changed, 206 insertions(+), 2 deletions(-)
create mode 100644 include/trace/events/dma_buf.h
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index edaa9e4ee4ae..59a5261cb26b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -35,6 +35,28 @@
#include "dma-buf-sysfs-stats.h"
+#define CREATE_TRACE_POINTS
+#include <trace/events/dma_buf.h>
+
+/*
+ * dmabuf->name must be accessed with holding dmabuf->name_lock.
+ * we need to take the lock around the tracepoint call itself where
+ * it is called in the code.
+ *
+ * Note: FUNC##_enabled() is a static branch that will only
+ * be set when the trace event is enabled.
+ */
+#define DMA_BUF_TRACE(FUNC, ...) \
+ do { \
+ if (FUNC##_enabled()) { \
+ guard(spinlock)(&dmabuf->name_lock); \
+ FUNC(__VA_ARGS__); \
+ } else if (IS_ENABLED(CONFIG_LOCKDEP)) { \
+ /* Expose this lock when lockdep is enabled */ \
+ guard(spinlock)(&dmabuf->name_lock); \
+ } \
+ } while (0)
+
static inline int is_dma_buf_file(struct file *);
static DEFINE_MUTEX(dmabuf_list_mutex);
@@ -220,6 +242,8 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
+ DMA_BUF_TRACE(trace_dma_buf_mmap_internal, dmabuf);
+
return dmabuf->ops->mmap(dmabuf, vma);
}
@@ -745,6 +769,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
__dma_buf_list_add(dmabuf);
+ DMA_BUF_TRACE(trace_dma_buf_export, dmabuf);
+
return dmabuf;
err_dmabuf:
@@ -768,10 +794,16 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_export, "DMA_BUF");
*/
int dma_buf_fd(struct dma_buf *dmabuf, int flags)
{
+ int fd;
+
if (!dmabuf || !dmabuf->file)
return -EINVAL;
- return FD_ADD(flags, dmabuf->file);
+ fd = FD_ADD(flags, dmabuf->file);
+ if (fd >= 0)
+ DMA_BUF_TRACE(trace_dma_buf_fd, dmabuf, fd);
+
+ return fd;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF");
@@ -786,6 +818,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF");
struct dma_buf *dma_buf_get(int fd)
{
struct file *file;
+ struct dma_buf *dmabuf;
file = fget(fd);
@@ -797,7 +830,11 @@ struct dma_buf *dma_buf_get(int fd)
return ERR_PTR(-EINVAL);
}
- return file->private_data;
+ dmabuf = file->private_data;
+
+ DMA_BUF_TRACE(trace_dma_buf_get, dmabuf, fd);
+
+ return dmabuf;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_get, "DMA_BUF");
@@ -817,6 +854,8 @@ void dma_buf_put(struct dma_buf *dmabuf)
return;
fput(dmabuf->file);
+
+ DMA_BUF_TRACE(trace_dma_buf_put, dmabuf);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF");
@@ -971,6 +1010,9 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
list_add(&attach->node, &dmabuf->attachments);
dma_resv_unlock(dmabuf->resv);
+ DMA_BUF_TRACE(trace_dma_buf_dynamic_attach, dmabuf, attach,
+ dma_buf_attachment_is_dynamic(attach), dev);
+
return attach;
err_attach:
@@ -1015,6 +1057,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
+ DMA_BUF_TRACE(trace_dma_buf_detach, dmabuf, attach,
+ dma_buf_attachment_is_dynamic(attach), attach->dev);
+
kfree(attach);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_detach, "DMA_BUF");
@@ -1480,6 +1525,8 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
+ DMA_BUF_TRACE(trace_dma_buf_mmap, dmabuf);
+
return dmabuf->ops->mmap(dmabuf, vma);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, "DMA_BUF");
diff --git a/include/trace/events/dma_buf.h b/include/trace/events/dma_buf.h
new file mode 100644
index 000000000000..8c49341f60ef
--- /dev/null
+++ b/include/trace/events/dma_buf.h
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM dma_buf
+
+#if !defined(_TRACE_DMA_BUF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_DMA_BUF_H
+
+#include <linux/dma-buf.h>
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(dma_buf,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf),
+
+ TP_STRUCT__entry(
+ __string( exp_name, dmabuf->exp_name)
+ __field( size_t, size)
+ __field( ino_t, ino)
+ ),
+
+ TP_fast_assign(
+ __assign_str(exp_name);
+ __entry->size = dmabuf->size;
+ __entry->ino = dmabuf->file->f_inode->i_ino;
+ ),
+
+ TP_printk("exp_name=%s size=%zu ino=%lu",
+ __get_str(exp_name),
+ __entry->size,
+ __entry->ino)
+);
+
+DECLARE_EVENT_CLASS(dma_buf_attach_dev,
+
+ TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
+ bool is_dynamic, struct device *dev),
+
+ TP_ARGS(dmabuf, attach, is_dynamic, dev),
+
+ TP_STRUCT__entry(
+ __string( dev_name, dev_name(dev))
+ __string( exp_name, dmabuf->exp_name)
+ __field( size_t, size)
+ __field( ino_t, ino)
+ __field( struct dma_buf_attachment *, attach)
+ __field( bool, is_dynamic)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name);
+ __assign_str(exp_name);
+ __entry->size = dmabuf->size;
+ __entry->ino = dmabuf->file->f_inode->i_ino;
+ __entry->is_dynamic = is_dynamic;
+ __entry->attach = attach;
+ ),
+
+ TP_printk("exp_name=%s size=%zu ino=%lu attachment:%p is_dynamic=%d dev_name=%s",
+ __get_str(exp_name),
+ __entry->size,
+ __entry->ino,
+ __entry->attach,
+ __entry->is_dynamic,
+ __get_str(dev_name))
+);
+
+DECLARE_EVENT_CLASS(dma_buf_fd,
+
+ TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+ TP_ARGS(dmabuf, fd),
+
+ TP_STRUCT__entry(
+ __string( exp_name, dmabuf->exp_name)
+ __field( size_t, size)
+ __field( ino_t, ino)
+ __field( int, fd)
+ ),
+
+ TP_fast_assign(
+ __assign_str(exp_name);
+ __entry->size = dmabuf->size;
+ __entry->ino = dmabuf->file->f_inode->i_ino;
+ __entry->fd = fd;
+ ),
+
+ TP_printk("exp_name=%s size=%zu ino=%lu fd=%d",
+ __get_str(exp_name),
+ __entry->size,
+ __entry->ino,
+ __entry->fd)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_export,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_mmap_internal,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_mmap,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_put,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf_attach_dev, dma_buf_dynamic_attach,
+
+ TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
+ bool is_dynamic, struct device *dev),
+
+ TP_ARGS(dmabuf, attach, is_dynamic, dev)
+);
+
+DEFINE_EVENT(dma_buf_attach_dev, dma_buf_detach,
+
+ TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
+ bool is_dynamic, struct device *dev),
+
+ TP_ARGS(dmabuf, attach, is_dynamic, dev)
+);
+
+DEFINE_EVENT(dma_buf_fd, dma_buf_fd,
+
+ TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+ TP_ARGS(dmabuf, fd)
+);
+
+DEFINE_EVENT(dma_buf_fd, dma_buf_get,
+
+ TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+ TP_ARGS(dmabuf, fd)
+);
+
+#endif /* _TRACE_DMA_BUF_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.34.1
^ permalink raw reply related
* [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
From: Aaron Tomlin @ 2025-12-23 3:56 UTC (permalink / raw)
To: rostedt, mhiramat, mark.rutland, mathieu.desnoyers, corbet
Cc: atomlin, sean, linux-kernel, linux-trace-kernel, linux-doc
Add support for displaying bitmasks in human-readable list format (e.g.,
0,2-5,7) in addition to the default hexadecimal bitmap representation.
This is particularly useful when tracing CPU masks and other large
bitmasks where individual bit positions are more meaningful than their
hexadecimal encoding.
When the "bitmask-list" option is enabled, the printk "%*pbl" format
specifier is used to render bitmasks as comma-separated ranges, making
trace output easier to interpret for complex CPU configurations and
large bitmask values.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Documentation/trace/ftrace.rst | 9 +++++++++
include/linux/trace_seq.h | 4 ++--
kernel/trace/trace.h | 1 +
kernel/trace/trace_output.c | 6 +++++-
kernel/trace/trace_seq.c | 11 +++++++----
5 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index d1f313a5f4ad..639f4d95732f 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -1290,6 +1290,15 @@ Here are the available options:
This will be useful if you want to find out which hashed
value is corresponding to the real value in trace log.
+ bitmask-list
+ When enabled, bitmasks are displayed as a human-readable list of
+ ranges (e.g., 0,2-5,7) using the printk "%*pbl" format specifier.
+ When disabled (the default), bitmasks are displayed in the
+ traditional hexadecimal bitmap representation. The list format is
+ particularly useful for tracing CPU masks and other large bitmasks
+ where individual bit positions are more meaningful than their
+ hexadecimal encoding.
+
record-cmd
When any event or tracer is enabled, a hook is enabled
in the sched_switch trace point to fill comm cache
diff --git a/include/linux/trace_seq.h b/include/linux/trace_seq.h
index 4a0b8c172d27..5e5b4331f8f1 100644
--- a/include/linux/trace_seq.h
+++ b/include/linux/trace_seq.h
@@ -114,7 +114,7 @@ extern void trace_seq_putmem_hex(struct trace_seq *s, const void *mem,
extern int trace_seq_path(struct trace_seq *s, const struct path *path);
extern void trace_seq_bitmask(struct trace_seq *s, const unsigned long *maskp,
- int nmaskbits);
+ int nmaskbits, bool show_list);
extern int trace_seq_hex_dump(struct trace_seq *s, const char *prefix_str,
int prefix_type, int rowsize, int groupsize,
@@ -133,7 +133,7 @@ void trace_seq_bprintf(struct trace_seq *s, const char *fmt, const u32 *binary)
static inline void
trace_seq_bitmask(struct trace_seq *s, const unsigned long *maskp,
- int nmaskbits)
+ int nmaskbits, bool show_list)
{
}
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index b6d42fe06115..8888fc9335b6 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1411,6 +1411,7 @@ extern int trace_get_user(struct trace_parser *parser, const char __user *ubuf,
C(COPY_MARKER, "copy_trace_marker"), \
C(PAUSE_ON_TRACE, "pause-on-trace"), \
C(HASH_PTR, "hash-ptr"), /* Print hashed pointer */ \
+ C(BITMASK_LIST, "bitmask-list"), \
FUNCTION_FLAGS \
FGRAPH_FLAGS \
STACK_FLAGS \
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index cc2d3306bb60..ede1a1b6d5a6 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -199,8 +199,12 @@ trace_print_bitmask_seq(struct trace_seq *p, void *bitmask_ptr,
unsigned int bitmask_size)
{
const char *ret = trace_seq_buffer_ptr(p);
+ const struct trace_array *tr = trace_get_global_array();
+ bool show_bitmask_list = tr->trace_flags &
+ TRACE_ITER(BITMASK_LIST);
- trace_seq_bitmask(p, bitmask_ptr, bitmask_size * 8);
+ trace_seq_bitmask(p, bitmask_ptr, bitmask_size * 8,
+ show_bitmask_list);
trace_seq_putc(p, 0);
return ret;
diff --git a/kernel/trace/trace_seq.c b/kernel/trace/trace_seq.c
index 32684ef4fb9d..5445fecf5f95 100644
--- a/kernel/trace/trace_seq.c
+++ b/kernel/trace/trace_seq.c
@@ -98,24 +98,27 @@ void trace_seq_printf(struct trace_seq *s, const char *fmt, ...)
EXPORT_SYMBOL_GPL(trace_seq_printf);
/**
- * trace_seq_bitmask - write a bitmask array in its ASCII representation
+ * trace_seq_bitmask - write a bitmask array in its ASCII or list representation
* @s: trace sequence descriptor
* @maskp: points to an array of unsigned longs that represent a bitmask
* @nmaskbits: The number of bits that are valid in @maskp
+ * @show_list: True for comma-separated list of ranges, false for hex bitmap
*
- * Writes a ASCII representation of a bitmask string into @s.
+ * Writes a ASCII or list (e.g., 0-3,5-7) representation of a bitmask
+ * string into @s.
*/
void trace_seq_bitmask(struct trace_seq *s, const unsigned long *maskp,
- int nmaskbits)
+ int nmaskbits, bool show_list)
{
unsigned int save_len = s->seq.len;
+ const char *fmt = show_list ? "%*pbl" : "%*pb";
if (s->full)
return;
__trace_seq_init(s);
- seq_buf_printf(&s->seq, "%*pb", nmaskbits, maskp);
+ seq_buf_printf(&s->seq, fmt, nmaskbits, maskp);
if (unlikely(seq_buf_has_overflowed(&s->seq))) {
s->seq.len = save_len;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 6/7] LoongArch: BPF: Enhance the bpf_arch_text_poke() function
From: Huacai Chen @ 2025-12-23 8:49 UTC (permalink / raw)
To: Hengqi Chen
Cc: Chenghao Duan, yangtiezhu, rostedt, mhiramat, mark.rutland,
kernel, zhangtianyang, masahiroy, linux-kernel, loongarch, bpf,
youling.tang, jianghaoran, vincent.mc.li, linux-trace-kernel
In-Reply-To: <CAEyhmHRkW67wiz_JX0i+sf2Y5LoYnpmTSt_Dh+asU8EEVTdk=w@mail.gmail.com>
On Tue, Dec 23, 2025 at 10:23 AM Hengqi Chen <hengqi.chen@gmail.com> wrote:
>
> On Mon, Dec 22, 2025 at 9:50 AM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> >
> > On Sat, Dec 20, 2025 at 10:07:25PM +0800, Hengqi Chen wrote:
> > > On Wed, Dec 17, 2025 at 2:15 PM Chenghao Duan <duanchenghao@kylinos.cn> wrote:
> > > >
> > > > Enhance the bpf_arch_text_poke() function to enable accurate location
> > > > of BPF program entry points.
> > > >
> > > > When modifying the entry point of a BPF program, skip the move t0, ra
> > > > instruction to ensure the correct logic and copy of the jump address.
> > > >
> > > > Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
> > > > ---
> > > > arch/loongarch/net/bpf_jit.c | 15 ++++++++++++++-
> > > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> > > > index 3dbabacc8856..0c16a1b18e8f 100644
> > > > --- a/arch/loongarch/net/bpf_jit.c
> > > > +++ b/arch/loongarch/net/bpf_jit.c
> > > > @@ -1290,6 +1290,10 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> > > > void *new_addr)
> > >
> > > The signature of bpf_arch_text_poke() was changed in v6.19 ([1]), please rebase.
> > >
> > > [1]: https://github.com/torvalds/linux/commit/ae4a3160d19cd16b874737ebc1798c7bc2fe3c9e
> >
> > Thank you for your review and for pointing out the API change in v6.19.
> >
> > I believe my patch series already accounts for this. It was developed on
> > top of commit ae4a3160d19c ("bpf: specify the old and new poke_type for bpf_arch_text_poke"),
> > so all modifications to bpf_arch_text_poke() call sites within my
> > patches should already be using the updated signature.
>
> Fine, it seems like the LoongArch tree is not up-to-date.
LoongArch tree now updated to 6.19-rc2, hope patches can be applied cleanly.
Huacai
>
> >
> > Please let me know if you find any inconsistencies or if further
> > adjustments are needed.
> >
> > Best regards,
> > Chenghao
> >
> > >
> > > > {
> > > > int ret;
> > > > + unsigned long size = 0;
> > > > + unsigned long offset = 0;
> > > > + char namebuf[KSYM_NAME_LEN];
> > > > + void *image = NULL;
> > > > bool is_call;
> > > > u32 old_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> > > > u32 new_insns[LOONGARCH_LONG_JUMP_NINSNS] = {[0 ... 4] = INSN_NOP};
> > > > @@ -1297,9 +1301,18 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type old_t,
> > > > /* Only poking bpf text is supported. Since kernel function entry
> > > > * is set up by ftrace, we rely on ftrace to poke kernel functions.
> > > > */
> > > > - if (!is_bpf_text_address((unsigned long)ip))
> > > > + if (!__bpf_address_lookup((unsigned long)ip, &size, &offset, namebuf))
> > > > return -ENOTSUPP;
> > > >
> > > > + image = ip - offset;
> > > > + /* zero offset means we're poking bpf prog entry */
> > > > + if (offset == 0)
> > > > + /* skip to the nop instruction in bpf prog entry:
> > > > + * move t0, ra
> > > > + * nop
> > > > + */
> > > > + ip = image + LOONGARCH_INSN_SIZE;
> > > > +
> > > > is_call = old_t == BPF_MOD_CALL;
> > > > ret = emit_jump_or_nops(old_addr, ip, old_insns, is_call);
> > > > if (ret)
> > > > --
> > > > 2.25.1
> > > >
>
^ permalink raw reply
* [PATCH] riscv: trace: fix snapshot deadlock with sbi ecall
From: Martin Kaiser @ 2025-12-23 13:50 UTC (permalink / raw)
To: Paul Walmsley, Palmer Dabbelt
Cc: linux-riscv, linux-trace-kernel, linux-kernel, Martin Kaiser
If sbi_ecall.c's functions are traceable,
echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter
may get the kernel into a deadlock.
(Functions in sbi_ecall.c are excluded from tracing if
CONFIG_RISCV_ALTERNATIVE_EARLY is set.)
__sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code
raises an IPI interrupt, which results in another call to __sbi_ecall
and another snapshot...
All it takes to get into this endless loop is one initial __sbi_ecall.
On RISC-V systems without SSTC extension, the clock events in
timer-riscv.c issue periodic sbi ecalls, making the problem easy to
trigger.
Always exclude the sbi_ecall.c functions from tracing to fix the
potential deadlock.
sbi ecalls can easiliy be logged via trace events, excluding ecall
functions from function tracing is not a big limitation.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
---
arch/riscv/kernel/Makefile | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 9026400cba10..cabb99cadfb6 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -3,12 +3,6 @@
# Makefile for the RISC-V Linux kernel
#
-ifdef CONFIG_FTRACE
-CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_patch.o = $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_sbi.o = $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
-endif
CFLAGS_syscall_table.o += $(call cc-disable-warning, override-init)
CFLAGS_compat_syscall_table.o += $(call cc-disable-warning, override-init)
@@ -24,7 +18,6 @@ CFLAGS_sbi_ecall.o := -mcmodel=medany
ifdef CONFIG_FTRACE
CFLAGS_REMOVE_alternative.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_cpufeature.o = $(CC_FLAGS_FTRACE)
-CFLAGS_REMOVE_sbi_ecall.o = $(CC_FLAGS_FTRACE)
endif
ifdef CONFIG_RELOCATABLE
CFLAGS_alternative.o += -fno-pie
@@ -43,6 +36,14 @@ CFLAGS_sbi_ecall.o += -D__NO_FORTIFY
endif
endif
+ifdef CONFIG_FTRACE
+CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_patch.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_sbi.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_sbi_ecall.o = $(CC_FLAGS_FTRACE)
+endif
+
always-$(KBUILD_BUILTIN) += vmlinux.lds
obj-y += head.o
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v9] dma-buf: add some tracepoints to debug.
From: Steven Rostedt @ 2025-12-23 16:44 UTC (permalink / raw)
To: Xiang Gao
Cc: sumit.semwal, christian.koenig, mhiramat, linux-media, dri-devel,
linux-kernel, mathieu.desnoyers, dhowells, kuba, brauner, akpm,
linux-trace-kernel, gaoxiang17
In-Reply-To: <20251223032749.1371913-1-gxxa03070307@gmail.com>
On Tue, 23 Dec 2025 11:27:49 +0800
Xiang Gao <gxxa03070307@gmail.com> wrote:
>
> +#define CREATE_TRACE_POINTS
> +#include <trace/events/dma_buf.h>
> +
> +/*
> + * dmabuf->name must be accessed with holding dmabuf->name_lock.
> + * we need to take the lock around the tracepoint call itself where
> + * it is called in the code.
> + *
> + * Note: FUNC##_enabled() is a static branch that will only
> + * be set when the trace event is enabled.
> + */
> +#define DMA_BUF_TRACE(FUNC, ...) \
> + do { \
> + if (FUNC##_enabled()) { \
> + guard(spinlock)(&dmabuf->name_lock); \
> + FUNC(__VA_ARGS__); \
> + } else if (IS_ENABLED(CONFIG_LOCKDEP)) { \
> + /* Expose this lock when lockdep is enabled */ \
> + guard(spinlock)(&dmabuf->name_lock); \
> + } \
> + } while (0)
> +
I hate to make another comment here, but I was just thinking that this can
be made to look a little nicer. Basically, we want to make sure that when
LOCKDEP is active, we always take the lock. But we also need to take the
lock when tracing is enabled. The tracepoint itself is a static branch,
which means it is a nop when not active, so there's no real problem with
calling it. Thus, this could look better as:
#define DMA_BUF_TRACE(FUNC, ...) \
do { \
/* Always expose lock if lockdep is enabled */ \
if (IS_ENABLED(CONFIG_LOCKDEP) || FUNC##_enabled()) { \
guard(spinlock)(&dmabuf->name_lock); \
FUNC(__VA_ARGS__); \
} \
} while (0)
-- Steve
^ permalink raw reply
* Re: [PATCH] tracing: Do not register unsupported perf events
From: Namhyung Kim @ 2025-12-23 18:22 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Ian Rogers, Arnaldo Carvalho de Melo, Jiri Olsa
In-Reply-To: <20251216182440.147e4453@gandalf.local.home>
Hi Steve,
On Tue, Dec 16, 2025 at 06:24:40PM -0500, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> Synthetic events currently do not have a function to register perf events.
> This leads to calling the tracepoint register functions with a NULL
> function pointer which triggers:
>
> ------------[ cut here ]------------
> WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272
> Modules linked in: kvm_intel kvm irqbypass
> CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> RIP: 0010:tracepoint_add_func+0x357/0x370
> Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f
> RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246
> RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000
> RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8
> RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780
> R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a
> R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78
> FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0
> Call Trace:
> <TASK>
> tracepoint_probe_register+0x5d/0x90
> synth_event_reg+0x3c/0x60
> perf_trace_event_init+0x204/0x340
> perf_trace_init+0x85/0xd0
> perf_tp_event_init+0x2e/0x50
> perf_try_init_event+0x6f/0x230
> ? perf_event_alloc+0x4bb/0xdc0
> perf_event_alloc+0x65a/0xdc0
> __se_sys_perf_event_open+0x290/0x9f0
> do_syscall_64+0x93/0x7b0
> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
> ? trace_hardirqs_off+0x53/0xc0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Instead, have the code return -ENODEV, which doesn't warn and has perf
> error out with:
>
> # perf record -e synthetic:futex_wait
> Error:
> The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).
> "dmesg | grep -i perf" may provide additional information.
>
> Ideally perf should support synthetic events, but for now just fix the
> warning. The support can come later.
>
> Cc: stable@vger.kernel.org
> Fixes: 4b147936fa509 ("tracing: Add support for 'synthetic' events")
> Reported-by: Ian Rogers <irogers@google.com>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Thanks,
Namhyung
> ---
> kernel/trace/trace_events.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index a5a93d243047..754b14ca87a7 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -710,6 +710,8 @@ int trace_event_reg(struct trace_event_call *call,
>
> #ifdef CONFIG_PERF_EVENTS
> case TRACE_REG_PERF_REGISTER:
> + if (!call->class->perf_probe)
> + return -ENODEV;
> return tracepoint_probe_register(call->tp,
> call->class->perf_probe,
> call);
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
From: Steven Rostedt @ 2025-12-23 18:34 UTC (permalink / raw)
To: Aaron Tomlin
Cc: mhiramat, mark.rutland, mathieu.desnoyers, corbet, sean,
linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <20251223035622.2084081-1-atomlin@atomlin.com>
On Mon, 22 Dec 2025 22:56:22 -0500
Aaron Tomlin <atomlin@atomlin.com> wrote:
> Add support for displaying bitmasks in human-readable list format (e.g.,
> 0,2-5,7) in addition to the default hexadecimal bitmap representation.
> This is particularly useful when tracing CPU masks and other large
> bitmasks where individual bit positions are more meaningful than their
> hexadecimal encoding.
>
> When the "bitmask-list" option is enabled, the printk "%*pbl" format
> specifier is used to render bitmasks as comma-separated ranges, making
> trace output easier to interpret for complex CPU configurations and
> large bitmask values.
Hmm, I have a couple of issues with this change. One, this is global. It
affects all instances. The other is that if this is going to be done, then
instead of adding a parameter to trace_seq_bitmask(), another trace_seq_*
API should be created. Perhaps trace_seq_bitmask_cnt()? And have
trace_print_bitmask_seq() call them separately.
I'm still not convinced that this is needed. What examples do you see?
Should it be only for CPU bitmasks?
I think a bit more thought needs to be made on a change like this. There's
other options that were added that I now regret. I don't want to add
another one I wish we didn't have.
-- Steve
^ permalink raw reply
* Re: [PATCH] tracing: Do not register unsupported perf events
From: Steven Rostedt @ 2025-12-23 21:46 UTC (permalink / raw)
To: Namhyung Kim
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Ian Rogers, Arnaldo Carvalho de Melo, Jiri Olsa
In-Reply-To: <aUrd2k8ckouCB_bQ@google.com>
On Tue, 23 Dec 2025 10:22:18 -0800
Namhyung Kim <namhyung@kernel.org> wrote:
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
>
> Thanks,
> Namhyung
>
> > ---
> > kernel/trace/trace_events.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> > index a5a93d243047..754b14ca87a7 100644
> > --- a/kernel/trace/trace_events.c
> > +++ b/kernel/trace/trace_events.c
> > @@ -710,6 +710,8 @@ int trace_event_reg(struct trace_event_call *call,
> >
> > #ifdef CONFIG_PERF_EVENTS
> > case TRACE_REG_PERF_REGISTER:
> > + if (!call->class->perf_probe)
> > + return -ENODEV;
Thanks Namhyung (and Jiri), but this actually already made it upstream as
it was a bug fix and I wanted to get it into the next rc release (rc2).
But, the real fix is having perf be able to handle synthetic_events as real
events.
Can you please review this patch:
https://lore.kernel.org/linux-trace-kernel/20251217113920.50b56246@gandalf.local.home/
I plan on queuing that for the next merge window.
Thanks,
-- Steve
> > return tracepoint_probe_register(call->tp,
> > call->class->perf_probe,
> > call);
> > --
^ permalink raw reply
* Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
From: Aaron Tomlin @ 2025-12-23 22:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mark.rutland, mathieu.desnoyers, corbet, sean,
linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <20251223133452.416fd539@gandalf.local.home>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Tue, Dec 23, 2025 at 01:34:52PM -0500, Steven Rostedt wrote:
> On Mon, 22 Dec 2025 22:56:22 -0500
> Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> > Add support for displaying bitmasks in human-readable list format (e.g.,
> > 0,2-5,7) in addition to the default hexadecimal bitmap representation.
> > This is particularly useful when tracing CPU masks and other large
> > bitmasks where individual bit positions are more meaningful than their
> > hexadecimal encoding.
> >
> > When the "bitmask-list" option is enabled, the printk "%*pbl" format
> > specifier is used to render bitmasks as comma-separated ranges, making
> > trace output easier to interpret for complex CPU configurations and
> > large bitmask values.
>
> Hmm, I have a couple of issues with this change. One, this is global. It
> affects all instances. The other is that if this is going to be done, then
> instead of adding a parameter to trace_seq_bitmask(), another trace_seq_*
> API should be created. Perhaps trace_seq_bitmask_cnt()? And have
> trace_print_bitmask_seq() call them separately.
>
> I'm still not convinced that this is needed. What examples do you see?
> Should it be only for CPU bitmasks?
>
> I think a bit more thought needs to be made on a change like this. There's
> other options that were added that I now regret. I don't want to add
> another one I wish we didn't have.
>
Hi Steve,
Thank you for the feedback.
Regarding the scope, I take your point that a global flag is perhaps too
blunt an instrument. I can see how making this instance-aware would be
preferable. I can look into refactoring this to ensure we pull the flags
from the specific trace_array associated with the current buffer instance
rather than the global state.
I agree with your suggestion to avoid polluting the existing
trace_seq_bitmask() signature. This would allow trace_print_bitmask_seq()
to branch between the two formats cleanly, as you suggested
As for the use case, I find this particularly invaluable when debugging IPI
latency or affinity issues on high-core-count systems. I typically run this
with the "nop" tracer enabled, focusing specifically on the
events/ipi/ipi_send_cpumask/ event.
When dealing with 128+ logical cores, interpreting a raw hexadecimal bitmap
to identify targeted CPUs is mentally taxing and prone to error. For
example, if I am investigating why CPU 6 is being interrupted, I might use
a filter such as "cpumask & CPU{6}". Seeing the resulting output as a range
list (e.g., 0-7) rather than a hexadecimal bitmask allows one to deduce
almost instantly which cluster of CPUs is involved in the IPI broadcast.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
From: kernel test robot @ 2025-12-23 22:33 UTC (permalink / raw)
To: Aaron Tomlin, rostedt, mhiramat, mark.rutland, mathieu.desnoyers,
corbet
Cc: oe-kbuild-all, atomlin, sean, linux-kernel, linux-trace-kernel,
linux-doc
In-Reply-To: <20251223035622.2084081-1-atomlin@atomlin.com>
Hi Aaron,
kernel test robot noticed the following build errors:
[auto build test ERROR on trace/for-next]
[also build test ERROR on linus/master v6.19-rc2 next-20251219]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aaron-Tomlin/tracing-Add-bitmask-list-option-for-human-readable-bitmask-display/20251223-120923
base: https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace for-next
patch link: https://lore.kernel.org/r/20251223035622.2084081-1-atomlin%40atomlin.com
patch subject: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
config: s390-randconfig-r071-20251224 (https://download.01.org/0day-ci/archive/20251224/202512240638.SumtF5C4-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251224/202512240638.SumtF5C4-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512240638.SumtF5C4-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
kernel/trace/trace_output.c: In function 'trace_print_bitmask_seq':
>> kernel/trace/trace_output.c:202:33: error: implicit declaration of function 'trace_get_global_array'; did you mean 'ftrace_init_global_array_ops'? [-Werror=implicit-function-declaration]
const struct trace_array *tr = trace_get_global_array();
^~~~~~~~~~~~~~~~~~~~~~
ftrace_init_global_array_ops
>> kernel/trace/trace_output.c:202:33: warning: initialization of 'const struct trace_array *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
cc1: some warnings being treated as errors
vim +202 kernel/trace/trace_output.c
196
197 const char *
198 trace_print_bitmask_seq(struct trace_seq *p, void *bitmask_ptr,
199 unsigned int bitmask_size)
200 {
201 const char *ret = trace_seq_buffer_ptr(p);
> 202 const struct trace_array *tr = trace_get_global_array();
203 bool show_bitmask_list = tr->trace_flags &
204 TRACE_ITER(BITMASK_LIST);
205
206 trace_seq_bitmask(p, bitmask_ptr, bitmask_size * 8,
207 show_bitmask_list);
208 trace_seq_putc(p, 0);
209
210 return ret;
211 }
212 EXPORT_SYMBOL_GPL(trace_print_bitmask_seq);
213
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
From: kernel test robot @ 2025-12-23 23:26 UTC (permalink / raw)
To: Aaron Tomlin, rostedt, mhiramat, mark.rutland, mathieu.desnoyers,
corbet
Cc: oe-kbuild-all, atomlin, sean, linux-kernel, linux-trace-kernel,
linux-doc
In-Reply-To: <20251223035622.2084081-1-atomlin@atomlin.com>
Hi Aaron,
kernel test robot noticed the following build errors:
[auto build test ERROR on trace/for-next]
[also build test ERROR on linus/master v6.19-rc2 next-20251219]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Aaron-Tomlin/tracing-Add-bitmask-list-option-for-human-readable-bitmask-display/20251223-120923
base: https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace for-next
patch link: https://lore.kernel.org/r/20251223035622.2084081-1-atomlin%40atomlin.com
patch subject: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
config: i386-randconfig-141-20251224 (https://download.01.org/0day-ci/archive/20251224/202512240709.cPAuuxFj-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251224/202512240709.cPAuuxFj-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512240709.cPAuuxFj-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/trace/trace_output.c: In function 'trace_print_bitmask_seq':
kernel/trace/trace_output.c:202:40: error: implicit declaration of function 'trace_get_global_array'; did you mean 'ftrace_init_global_array_ops'? [-Wimplicit-function-declaration]
202 | const struct trace_array *tr = trace_get_global_array();
| ^~~~~~~~~~~~~~~~~~~~~~
| ftrace_init_global_array_ops
>> kernel/trace/trace_output.c:202:40: error: initialization of 'const struct trace_array *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
vim +202 kernel/trace/trace_output.c
196
197 const char *
198 trace_print_bitmask_seq(struct trace_seq *p, void *bitmask_ptr,
199 unsigned int bitmask_size)
200 {
201 const char *ret = trace_seq_buffer_ptr(p);
> 202 const struct trace_array *tr = trace_get_global_array();
203 bool show_bitmask_list = tr->trace_flags &
204 TRACE_ITER(BITMASK_LIST);
205
206 trace_seq_bitmask(p, bitmask_ptr, bitmask_size * 8,
207 show_bitmask_list);
208 trace_seq_putc(p, 0);
209
210 return ret;
211 }
212 EXPORT_SYMBOL_GPL(trace_print_bitmask_seq);
213
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] tracing: Add bitmask-list option for human-readable bitmask display
From: Aaron Tomlin @ 2025-12-24 0:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mark.rutland, mathieu.desnoyers, corbet, sean,
linux-kernel, linux-trace-kernel, linux-doc
In-Reply-To: <20251223133452.416fd539@gandalf.local.home>
[-- Attachment #1: Type: text/plain, Size: 5807 bytes --]
On Tue, Dec 23, 2025 at 01:34:52PM -0500, Steven Rostedt wrote:
> On Mon, 22 Dec 2025 22:56:22 -0500
> Aaron Tomlin <atomlin@atomlin.com> wrote:
>
> > Add support for displaying bitmasks in human-readable list format (e.g.,
> > 0,2-5,7) in addition to the default hexadecimal bitmap representation.
> > This is particularly useful when tracing CPU masks and other large
> > bitmasks where individual bit positions are more meaningful than their
> > hexadecimal encoding.
> >
> > When the "bitmask-list" option is enabled, the printk "%*pbl" format
> > specifier is used to render bitmasks as comma-separated ranges, making
> > trace output easier to interpret for complex CPU configurations and
> > large bitmask values.
>
> Hmm, I have a couple of issues with this change. One, this is global. It
> affects all instances. The other is that if this is going to be done, then
> instead of adding a parameter to trace_seq_bitmask(), another trace_seq_*
> API should be created. Perhaps trace_seq_bitmask_cnt()? And have
> trace_print_bitmask_seq() call them separately.
>
> I'm still not convinced that this is needed. What examples do you see?
> Should it be only for CPU bitmasks?
>
> I think a bit more thought needs to be made on a change like this. There's
> other options that were added that I now regret. I don't want to add
> another one I wish we didn't have.
>
Hi Steven,
Regarding the scope, I take your point that a global flag is perhaps too
blunt an instrument. I can certainly refactor this to be instance-aware by
passing the trace_iterator through the call chain.
As for the use case, I find this particularly invaluable when debugging IPI
latency or affinity issues on high-core-count systems. I typically run this
with the "nop" tracer and enable only the events/ipi/ipi_send_cpumask/
event.
When dealing with 128+ logical cores, interpreting a raw hexadecimal bitmap
to identify targeted CPUs is taxing and prone to error. For example, if I
am investigating why CPU 6 is being interrupted, I might use a filter like
"cpumask & CPU{6}". Seeing the resulting output as a range list (e.g., 0-7)
rather than a hexadecimal bitmask allows one to deduce almost instantly
which cluster of CPUs is involved in the IPI broadcast.
To avoid duplication, I am of the opinion that we should maintain a single
trace_seq_bitmask() and simply extend it. However, I am happy to extend the
API if you prefer. Given that struct trace_iterator *iter is available in
the output path, how about the following (not yet fully tested):
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 3690221ba3d8..0a2b8229b999 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -38,7 +38,10 @@ const char *trace_print_symbols_seq_u64(struct trace_seq *p,
*symbol_array);
#endif
-const char *trace_print_bitmask_seq(struct trace_seq *p, void *bitmask_ptr,
+struct trace_iterator;
+struct trace_event;
+
+const char *trace_print_bitmask_seq(struct trace_iterator *iter, void *bitmask_ptr,
unsigned int bitmask_size);
const char *trace_print_hex_seq(struct trace_seq *p,
@@ -54,9 +57,6 @@ trace_print_hex_dump_seq(struct trace_seq *p, const char *prefix_str,
int prefix_type, int rowsize, int groupsize,
const void *buf, size_t len, bool ascii);
-struct trace_iterator;
-struct trace_event;
-
int trace_raw_output_prep(struct trace_iterator *iter,
struct trace_event *event);
extern __printf(2, 3)
diff --git a/include/trace/stages/stage3_trace_output.h b/include/trace/stages/stage3_trace_output.h
index 1e7b0bef95f5..fce85ea2df1c 100644
--- a/include/trace/stages/stage3_trace_output.h
+++ b/include/trace/stages/stage3_trace_output.h
@@ -39,7 +39,7 @@
void *__bitmask = __get_dynamic_array(field); \
unsigned int __bitmask_size; \
__bitmask_size = __get_dynamic_array_len(field); \
- trace_print_bitmask_seq(p, __bitmask, __bitmask_size); \
+ trace_print_bitmask_seq(iter, __bitmask, __bitmask_size); \
})
#undef __get_cpumask
@@ -51,7 +51,7 @@
void *__bitmask = __get_rel_dynamic_array(field); \
unsigned int __bitmask_size; \
__bitmask_size = __get_rel_dynamic_array_len(field); \
- trace_print_bitmask_seq(p, __bitmask, __bitmask_size); \
+ trace_print_bitmask_seq(iter, __bitmask, __bitmask_size); \
})
#undef __get_rel_cpumask
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index cc2d3306bb60..b312d67815fa 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -195,13 +195,18 @@ EXPORT_SYMBOL(trace_print_symbols_seq_u64);
#endif
const char *
-trace_print_bitmask_seq(struct trace_seq *p, void *bitmask_ptr,
+trace_print_bitmask_seq(struct trace_iterator *iter, void *bitmask_ptr,
unsigned int bitmask_size)
{
- const char *ret = trace_seq_buffer_ptr(p);
-
- trace_seq_bitmask(p, bitmask_ptr, bitmask_size * 8);
- trace_seq_putc(p, 0);
+ struct trace_seq *s = &iter->seq;
+ const struct trace_array *tr = iter->tr;
+ const char *ret = trace_seq_buffer_ptr(s);
+ bool show_bitmask_list = tr->trace_flags &
+ TRACE_ITER(BITMASK_LIST);
+
+ trace_seq_bitmask(s, bitmask_ptr, bitmask_size * 8,
+ show_bitmask_list);
+ trace_seq_putc(s, 0);
return ret;
}
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* [PATCH v10] dma-buf: add some tracepoints to debug.
From: Xiang Gao @ 2025-12-24 1:34 UTC (permalink / raw)
To: sumit.semwal, christian.koenig, rostedt, mhiramat
Cc: linux-media, dri-devel, linux-kernel, mathieu.desnoyers, dhowells,
kuba, brauner, akpm, linux-trace-kernel, gaoxiang17
From: gaoxiang17 <gaoxiang17@xiaomi.com>
Since we can only inspect dmabuf by iterating over process FDs or the
dmabuf_list, we need to add our own tracepoints to track its status in
real time in production.
For example:
binder:3016_1-3102 [006] ...1. 255.126521: dma_buf_export: exp_name=qcom,system size=12685312 ino=2738
binder:3016_1-3102 [006] ...1. 255.126528: dma_buf_fd: exp_name=qcom,system size=12685312 ino=2738 fd=8
binder:3016_1-3102 [006] ...1. 255.126642: dma_buf_mmap_internal: exp_name=qcom,system size=28672 ino=2739
kworker/6:1-86 [006] ...1. 255.127194: dma_buf_put: exp_name=qcom,system size=12685312 ino=2738
RenderThread-9293 [006] ...1. 316.618179: dma_buf_get: exp_name=qcom,system size=12771328 ino=2762 fd=176
RenderThread-9293 [006] ...1. 316.618195: dma_buf_dynamic_attach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
RenderThread-9293 [006] ...1. 318.878220: dma_buf_detach: exp_name=qcom,system size=12771328 ino=2762 attachment:ffffff880a18dd00 is_dynamic=0 dev_name=kgsl-3d0
Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
---
drivers/dma-buf/dma-buf.c | 49 +++++++++-
include/trace/events/dma_buf.h | 157 +++++++++++++++++++++++++++++++++
2 files changed, 204 insertions(+), 2 deletions(-)
create mode 100644 include/trace/events/dma_buf.h
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index edaa9e4ee4ae..5e6f65cd0306 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -35,6 +35,26 @@
#include "dma-buf-sysfs-stats.h"
+#define CREATE_TRACE_POINTS
+#include <trace/events/dma_buf.h>
+
+/*
+ * dmabuf->name must be accessed with holding dmabuf->name_lock.
+ * we need to take the lock around the tracepoint call itself where
+ * it is called in the code.
+ *
+ * Note: FUNC##_enabled() is a static branch that will only
+ * be set when the trace event is enabled.
+ */
+#define DMA_BUF_TRACE(FUNC, ...) \
+ do { \
+ /* Always expose lock if lockdep is enabled */ \
+ if (IS_ENABLED(CONFIG_LOCKDEP) || FUNC##_enabled()) { \
+ guard(spinlock)(&dmabuf->name_lock); \
+ FUNC(__VA_ARGS__); \
+ } \
+ } while (0)
+
static inline int is_dma_buf_file(struct file *);
static DEFINE_MUTEX(dmabuf_list_mutex);
@@ -220,6 +240,8 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
+ DMA_BUF_TRACE(trace_dma_buf_mmap_internal, dmabuf);
+
return dmabuf->ops->mmap(dmabuf, vma);
}
@@ -745,6 +767,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
__dma_buf_list_add(dmabuf);
+ DMA_BUF_TRACE(trace_dma_buf_export, dmabuf);
+
return dmabuf;
err_dmabuf:
@@ -768,10 +792,16 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_export, "DMA_BUF");
*/
int dma_buf_fd(struct dma_buf *dmabuf, int flags)
{
+ int fd;
+
if (!dmabuf || !dmabuf->file)
return -EINVAL;
- return FD_ADD(flags, dmabuf->file);
+ fd = FD_ADD(flags, dmabuf->file);
+ if (fd >= 0)
+ DMA_BUF_TRACE(trace_dma_buf_fd, dmabuf, fd);
+
+ return fd;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF");
@@ -786,6 +816,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF");
struct dma_buf *dma_buf_get(int fd)
{
struct file *file;
+ struct dma_buf *dmabuf;
file = fget(fd);
@@ -797,7 +828,11 @@ struct dma_buf *dma_buf_get(int fd)
return ERR_PTR(-EINVAL);
}
- return file->private_data;
+ dmabuf = file->private_data;
+
+ DMA_BUF_TRACE(trace_dma_buf_get, dmabuf, fd);
+
+ return dmabuf;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_get, "DMA_BUF");
@@ -817,6 +852,8 @@ void dma_buf_put(struct dma_buf *dmabuf)
return;
fput(dmabuf->file);
+
+ DMA_BUF_TRACE(trace_dma_buf_put, dmabuf);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_put, "DMA_BUF");
@@ -971,6 +1008,9 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
list_add(&attach->node, &dmabuf->attachments);
dma_resv_unlock(dmabuf->resv);
+ DMA_BUF_TRACE(trace_dma_buf_dynamic_attach, dmabuf, attach,
+ dma_buf_attachment_is_dynamic(attach), dev);
+
return attach;
err_attach:
@@ -1015,6 +1055,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
+ DMA_BUF_TRACE(trace_dma_buf_detach, dmabuf, attach,
+ dma_buf_attachment_is_dynamic(attach), attach->dev);
+
kfree(attach);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_detach, "DMA_BUF");
@@ -1480,6 +1523,8 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
+ DMA_BUF_TRACE(trace_dma_buf_mmap, dmabuf);
+
return dmabuf->ops->mmap(dmabuf, vma);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, "DMA_BUF");
diff --git a/include/trace/events/dma_buf.h b/include/trace/events/dma_buf.h
new file mode 100644
index 000000000000..2c9ba8533467
--- /dev/null
+++ b/include/trace/events/dma_buf.h
@@ -0,0 +1,157 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM dma_buf
+
+#if !defined(_TRACE_DMA_BUF_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_DMA_BUF_H
+
+#include <linux/dma-buf.h>
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(dma_buf,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf),
+
+ TP_STRUCT__entry(
+ __string( exp_name, dmabuf->exp_name)
+ __field( size_t, size)
+ __field( ino_t, ino)
+ ),
+
+ TP_fast_assign(
+ __assign_str(exp_name);
+ __entry->size = dmabuf->size;
+ __entry->ino = dmabuf->file->f_inode->i_ino;
+ ),
+
+ TP_printk("exp_name=%s size=%zu ino=%lu",
+ __get_str(exp_name),
+ __entry->size,
+ __entry->ino)
+);
+
+DECLARE_EVENT_CLASS(dma_buf_attach_dev,
+
+ TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
+ bool is_dynamic, struct device *dev),
+
+ TP_ARGS(dmabuf, attach, is_dynamic, dev),
+
+ TP_STRUCT__entry(
+ __string( dev_name, dev_name(dev))
+ __string( exp_name, dmabuf->exp_name)
+ __field( size_t, size)
+ __field( ino_t, ino)
+ __field( struct dma_buf_attachment *, attach)
+ __field( bool, is_dynamic)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name);
+ __assign_str(exp_name);
+ __entry->size = dmabuf->size;
+ __entry->ino = dmabuf->file->f_inode->i_ino;
+ __entry->is_dynamic = is_dynamic;
+ __entry->attach = attach;
+ ),
+
+ TP_printk("exp_name=%s size=%zu ino=%lu attachment:%p is_dynamic=%d dev_name=%s",
+ __get_str(exp_name),
+ __entry->size,
+ __entry->ino,
+ __entry->attach,
+ __entry->is_dynamic,
+ __get_str(dev_name))
+);
+
+DECLARE_EVENT_CLASS(dma_buf_fd,
+
+ TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+ TP_ARGS(dmabuf, fd),
+
+ TP_STRUCT__entry(
+ __string( exp_name, dmabuf->exp_name)
+ __field( size_t, size)
+ __field( ino_t, ino)
+ __field( int, fd)
+ ),
+
+ TP_fast_assign(
+ __assign_str(exp_name);
+ __entry->size = dmabuf->size;
+ __entry->ino = dmabuf->file->f_inode->i_ino;
+ __entry->fd = fd;
+ ),
+
+ TP_printk("exp_name=%s size=%zu ino=%lu fd=%d",
+ __get_str(exp_name),
+ __entry->size,
+ __entry->ino,
+ __entry->fd)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_export,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_mmap_internal,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_mmap,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf, dma_buf_put,
+
+ TP_PROTO(struct dma_buf *dmabuf),
+
+ TP_ARGS(dmabuf)
+);
+
+DEFINE_EVENT(dma_buf_attach_dev, dma_buf_dynamic_attach,
+
+ TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
+ bool is_dynamic, struct device *dev),
+
+ TP_ARGS(dmabuf, attach, is_dynamic, dev)
+);
+
+DEFINE_EVENT(dma_buf_attach_dev, dma_buf_detach,
+
+ TP_PROTO(struct dma_buf *dmabuf, struct dma_buf_attachment *attach,
+ bool is_dynamic, struct device *dev),
+
+ TP_ARGS(dmabuf, attach, is_dynamic, dev)
+);
+
+DEFINE_EVENT(dma_buf_fd, dma_buf_fd,
+
+ TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+ TP_ARGS(dmabuf, fd)
+);
+
+DEFINE_EVENT(dma_buf_fd, dma_buf_get,
+
+ TP_PROTO(struct dma_buf *dmabuf, int fd),
+
+ TP_ARGS(dmabuf, fd)
+);
+
+#endif /* _TRACE_DMA_BUF_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.34.1
^ permalink raw reply related
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