Messages in this thread | | | Date | Thu, 16 Jun 2022 11:34:00 -0400 | From | Steven Rostedt <> | Subject | Re: possible trace_printk() bug in v5.19-rc1 |
| |
On Thu, 16 Jun 2022 15:22:26 +0000 Chuck Lever III <chuck.lever@oracle.com> wrote:
> Hi Steve- > > Since v5.19-rc1, trace_printk() no longer displays a function > name, but rather a kernel address. I don't have time at the > moment to track this down to a specific commit, just parking > it here in case someone can get to it sooner than me. > > <idle>-0 [003] 269.397568: bprint: 0xffffffffc0cccab7: nf=0xffff888172dbfba0 still on the LRU or a dispose list > <idle>-0 [003] 269.397576: bprint: 0xffffffffc0cccafa: nf=0xffff888172dbfba0 > <idle>-0 [003] 269.397583: bprint: 0xffffffffc0cccab7: nf=0xffff8881726cd4d8 still on the LRU or a dispose list > <idle>-0 [003] 269.397584: bprint: 0xffffffffc0cccafa: nf=0xffff8881726cd4d8 >
It uses the normal vsprintf() in the kernel (that is, it prints the function address just like printk() does with %pS). So if trace_printk() is broken, then so is printk().
But one reason for this is if you have a trace_printk() in a module, do the record, and then remove the module. The function name will also be removed from kallsyms, leaving you with only the function address.
Did you remove any modules before displaying the trace?
-- Steve
| |