[PATCH] powerpc/64: Drop ppc_inst_as_str()

[Bagas Sanjaya]

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 <bagasdotme at gmail.com>
> Reported-by: Petr Mladek <pmladek at suse.com>
> Signed-off-by: Michael Ellerman <mpe at 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 <bagasdotme at gmail.com>

[1]: https://lore.kernel.org/linuxppc-dev/YpbUcPrm61RLIiZF@debian.me/

-- 
An old man doll... just what I always wanted! - Clara