Hi, On Tue, May 31, 2022 at 04:59:36PM +1000, Michael Ellerman wrote: > The ppc_inst_as_str() macro tries to make printing variable length, > aka "prefixed", instructions convenient. It mostly succeeds, but it does > hide an on-stack buffer, which triggers stack protector. > > More problematically it doesn't compile at all with GCC 12, due to the > fact that it returns the char buffer declared inside the macro: > > arch/powerpc/kernel/trace/ftrace.c: In function '__ftrace_modify_call': > ./include/linux/printk.h:475:44: error: using a dangling pointer to '__str' > [-Werror=dangling-pointer=] > 475 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, > ##__VA_ARGS__) > ... > arch/powerpc/kernel/trace/ftrace.c:567:17: note: in expansion of macro > 'pr_err' > 567 | pr_err("Not expected bl: opcode is %s\n", > ppc_inst_as_str(op)); > | ^~~~~~ > ./arch/powerpc/include/asm/inst.h:156:14: note: '__str' declared here > 156 | char __str[PPC_INST_STR_LEN]; \ > | ^~~~~ > > This could be fixed by having the caller declare the buffer, but in some > places there'd need to be two buffers. In all cases where > ppc_inst_as_str() is used the output is not really meant for user > consumption, it's almost always indicative of a kernel bug. > > A simpler solution is to just print the value as an unsigned long. For > normal instructions the output is identical. For prefixed instructions > the value is printed as a single 64-bit quantity, whereas previously the > low half was printed first. But that is good enough for debug output, > especially as prefixed instructions will be rare in practice. > > Old: > c000000000111170 60420000 ori r2,r2,0 > c000000000111174 04100001 e580fb00 .long 0xe580fb0004100001 > > New: > c00000000010f90c 60420000 ori r2,r2,0 > c00000000010f910 e580fb0004100001 .long 0xe580fb0004100001 > > Reported-by: Bagas Sanjaya <bagasdo...@gmail.com> > Reported-by: Petr Mladek <pmla...@suse.com> > Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
The arch/powerpc/kernel/trace/ftrace.c builds successfully, however there is also other build error for which I have reported at [1]. Thanks. Tested-by: Bagas Sanjaya <bagasdo...@gmail.com> [1]: https://lore.kernel.org/linuxppc-dev/ypbucprm61rli...@debian.me/ -- An old man doll... just what I always wanted! - Clara