Re: LTS "sysrq: Restore original console_loglevel when sysrq disabled"

[gregkh@xxxxxxxxxxxxxxxxxxx]

On Mon, Mar 02, 2020 at 07:42:55AM +0000, Rantala, Tommi T. (Nokia - FI/Espoo) wrote:
> Hi Greg, Sasha,
> 
> Can you cherry-pick these two sysrq patches to LTS kernels?
> They're introduced in v5.1-rc1 and should go to all prior LTS versions.
> 
> 
> commit 075e1a0c50f59ea210561d0d0fedbd945615df78
> Author: Petr Mladek <pmladek@xxxxxxxx>
> Date:   Fri Jan 11 13:45:15 2019 +0100
> 
>     sysrq: Restore original console_loglevel when sysrq disabled
>     
>     The sysrq header line is printed with an increased loglevel
>     to provide users some positive feedback.
>     
>     The original loglevel is not restored when the sysrq operation
>     is disabled. This bug was introduced in 2.6.12 (pre-git-history)
>     by the commit ("Allow admin to enable only some of the Magic-Sysrq
>     functions").
> 
> 
> commit c3fee60908db4a8594f2e4a2131998384b8fa006
> Author: Petr Mladek <pmladek@xxxxxxxx>
> Date:   Fri Jan 11 17:20:37 2019 +0100
> 
>     sysrq: Remove duplicated sysrq message
>     
>     The commit 97f5f0cd8cd0a0544 ("Input: implement SysRq as a separate
> input
>     handler") added pr_fmt() definition. It caused a duplicated message
>     prefix in the sysrq header messages, for example:
>     
>     [  177.053931] sysrq: SysRq : Show backtrace of all active CPUs
>     [  742.864776] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c)
>     
>     Fixes: 97f5f0cd8cd0a05 ("Input: implement SysRq as a separate input
> handler")
> 

Both now queued up, thanks.

greg k-h