Hi Petr, Sorry for the noise.
The previous revisions were not sent automatically by an AI agent, but I did use AI assistance while working on this thread and I should have disclosed that according to Documentation/process/coding-assistants.rst. More importantly, I should have slowed down and answered the design questions first instead of posting another implementation so quickly. After going back through the bug report, the code, and a local reproducer, I think the original bug report is valid: module tracepoint_string() entries do not currently show up in printk_formats. The implementation gap seems to be that the module path handles __trace_printk_fmt, but there is no equivalent handling for a module's __tracepoint_str entries, so printk_formats has no module-side source from which to enumerate them. What I got wrong in the previous versions was the direction of the fix. I treated the missing module __tracepoint_str handling as if it should reuse the module trace_printk storage model, which made the mapping persist beyond module unload. I agree that this is not the right lifetime semantics for tracepoint_string(). So I do not plan to send another patch revision until the intended module lifetime behavior is clear. At this point, the direction that seems right to me is to make module tracepoint_string() mappings visible while the module is alive, without simply reusing the trace_printk persistence model. Thanks, Cao Assisted-by: Codex:GPT-5.4
