Re: [PATCH v7 0/4] tracing: improve symbolic printing

[Steven Rostedt]

On Tue, 22 Sep 2026 13:08:39 +0200
Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:

> Hi,
> 
> Resend with the selftests and the two sashiko findings.

Hi Johannes,

Could you also add code in the samples/trace_events directory. Perhaps add
a new event?

This will make it easier to understand exactly how to add new __print_sym()s.

FYI, this series did pass all my tests.

Thanks,

-- Steve


> 
> v2 was:
>  - rebased on 6.9-rc1
>  - always search for __print_sym() and get rid of the DYNPRINT flag
>    and associated code; I think ideally we'll just remove the older
>    __print_symbolic() entirely
>  - use ':' as the separator instead of "//" since that makes searching
>    for it much easier and it's still not a valid char in an identifier
>  - fix RCU
> 
> v3:
>  - fix #undef issues
>  - fix drop_monitor default
>  - rebase on linux-trace/for-next (there were no conflicts)
>  - move net patches to 3/4
>  - clarify symbol name matching logic (and remove ")" from it)
> 
> v4:
>  - fix non-module build and possibly dynamic event handling
> 
> v5: (https://lore.kernel.org/all/20240614081956.19832-6-johannes@xxxxxxxxxxxxxxxx/)
>  - fix build warning in non-module build
> 
> v6: (https://lore.kernel.org/linux-trace-kernel/20260921101538.97286-6-johannes@xxxxxxxxxxxxxxxx/)
>  - rebase
>  - fix nit from Paolo (I hope, I don't remember changing it
>    but it looks fixed!)
>  - fix crash due to wrong data placement
> 
> v7: (this version)
>  - update ovs selftest
>  - don't ifdef drop_reason_lookup() prototype
>  - fix section alignment
> 
> 
> To recap, it's annoying to have
> 
>  irq/65-iwlwifi:-401   [000]    22.790000: kfree_skb:  ...  reason: 0x20000
> 
> and much nicer to see
> 
>  irq/65-iwlwifi:-401   [000]    22.790000: kfree_skb:  ...  reason: RX_DROP_MONITOR
> 
> but this doesn't work now because __print_symbolic() can only
> deal with a hard-coded list (which is actually really big.)
> 
> So here's __print_sym() which doesn't build the list into the
> kernel image, but creates it at runtime. For userspace, it
> will look the same as __print_symbolic() (it literally shows
> __print_symbolic() to userspace) so no changes are needed,
> but the actual list of values exposed to userspace in there
> is built dynamically. For SKB drop reasons, this then has all
> the reasons known when userspace queries the trace format.
> 
> I guess patches 3/4 should go through net-next, so not sure
> how to handle this patch series. Or perhaps, as this will likely
> not cause conflicts (in fact I've been rebasing it for years now),
> go through tracing anyway with an Ack from netdev? But I can
> also just wait for the trace patch(es) to land and resubmit the
> net patches after. Assuming this looks good at all :-)
> 
> Thanks,
> johannes