On 11/6/19 9:52 AM, Michael Ellerman wrote:
> Dmitry Safonov <d...@arista.com> writes:
>> Currently, the log-level of show_stack() depends on a platform
>> realization. It creates situations where the headers are printed with
>> lower log level or higher than the stacktrace (depending on
>> a platform or user).
>
> Yes, I've had bug reports where the stacktrace is missing, which is
> annoying. Thanks for trying to fix the problem.
>
>> Furthermore, it forces the logic decision from user to an architecture
>> side. In result, some users as sysrq/kdb/etc are doing tricks with
>> temporary rising console_loglevel while printing their messages.
>> And in result it not only may print unwanted messages from other CPUs,
>> but also omit printing at all in the unlucky case where the printk()
>> was deferred.
>>
>> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
>> an easier approach than introducing more printk buffers.
>> Also, it will consolidate printings with headers.
>>
>> Introduce show_stack_loglvl(), that eventually will substitute
>> show_stack().
>>
>> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
>> Cc: Michael Ellerman <m...@ellerman.id.au>
>> Cc: Paul Mackerras <pau...@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-d...@arista.com/T/#u
>> Signed-off-by: Dmitry Safonov <d...@arista.com>
>> ---
>> arch/powerpc/kernel/process.c | 18 +++++++++++++-----
>> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> This looks good to me.
>
> Acked-by: Michael Ellerman <m...@ellerman.id.au> (powerpc)
Thanks for the review and time!
--
Dmitry
