linux-stable.git/drivers/tty/sysrq.c, branch v5.8

kernel: rename show_stack_loglvl() => show_stack()

2020-06-09T16:39:13+00:00

Now the last users of show_stack() got converted to use an explicit log
level, show_stack_loglvl() can drop it's redundant suffix and become once
again well known show_stack().

Signed-off-by: Dmitry Safonov 
Signed-off-by: Andrew Morton 
Link: http://lkml.kernel.org/r/20200418201944.482088-51-dima@arista.com
Signed-off-by: Linus Torvalds

sysrq: use show_stack_loglvl()

2020-06-09T16:39:12+00:00

Show the stack trace on a CPU with the same log level as "CPU%d" header.

Signed-off-by: Dmitry Safonov 
Signed-off-by: Andrew Morton 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Link: http://lkml.kernel.org/r/20200418201944.482088-45-dima@arista.com
Signed-off-by: Linus Torvalds

tty/sysrq: constify the the sysrq_key_op(s)

2020-05-15T12:53:19+00:00

All the users threat them as immutable - annotate them as such.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Emil Velikov 
Link: https://lore.kernel.org/r/20200513214351.2138580-3-emil.l.velikov@gmail.com
Signed-off-by: Greg Kroah-Hartman

tty/sysrq: constify the sysrq API

2020-05-15T12:53:19+00:00

The user is not supposed to thinker with the underlying sysrq_key_op.
Make that explicit by adding a handful of const notations.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Emil Velikov 
Link: https://lore.kernel.org/r/20200513214351.2138580-2-emil.l.velikov@gmail.com
Signed-off-by: Greg Kroah-Hartman

tty/sysrq: alpha: export and use __sysrq_get_key_op()

2020-05-15T12:53:18+00:00

Export a pointer to the sysrq_get_key_op(). This way we can cleanly
unregister it, instead of the current solutions of modifuing it inplace.

Since __sysrq_get_key_op() is no longer used externally, let's make it
a static function.

This patch will allow us to limit access to each and every sysrq op and
constify the sysrq handling.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-kernel@vger.kernel.org
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-alpha@vger.kernel.org
Signed-off-by: Emil Velikov 
Link: https://lore.kernel.org/r/20200513214351.2138580-1-emil.l.velikov@gmail.com
Signed-off-by: Greg Kroah-Hartman

tty/sysrq: Export sysrq_mask(), sysrq_toggle_support()

2020-04-20T17:37:42+00:00

Build fix for serial_core being module:
  ERROR: modpost: "sysrq_toggle_support" [drivers/tty/serial/serial_core.ko] undefined!
  ERROR: modpost: "sysrq_mask" [drivers/tty/serial/serial_core.ko] undefined!

Fixes: eaee41727e6d ("sysctl/sysrq: Remove __sysrq_enabled copy")
Cc: Jiri Slaby 
Reported-by: "kernelci.org bot" 
Reported-by: Michael Ellerman 
Reported-by: Stephen Rothwell 
Signed-off-by: Dmitry Safonov 
Link: https://lore.kernel.org/r/20200420172317.599611-1-dima@arista.com
Signed-off-by: Greg Kroah-Hartman

sysctl/sysrq: Remove __sysrq_enabled copy

2020-03-07T08:52:02+00:00

Many embedded boards have a disconnected TTL level serial which can
generate some garbage that can lead to spurious false sysrq detects.

Currently, sysrq can be either completely disabled for serial console
or always disabled (with CONFIG_MAGIC_SYSRQ_SERIAL), since
commit 732dbf3a6104 ("serial: do not accept sysrq characters via serial port")

At Arista, we have such boards that can generate BREAK and random
garbage. While disabling sysrq for serial console would solve
the problem with spurious false sysrq triggers, it's also desirable
to have a way to enable sysrq back.

Having the way to enable sysrq was beneficial to debug lockups with
a manual investigation in field and on the other side preventing false
sysrq detections.

As a preparation to add sysrq_toggle_support() call into uart,
remove a private copy of sysrq_enabled from sysctl - it should reflect
the actual status of sysrq.

Furthermore, the private copy isn't correct already in case
sysrq_always_enabled is true. So, remove __sysrq_enabled and use a
getter-helper sysrq_mask() to check sysrq_key_op enabled status.

Cc: Iurii Zaikin 
Cc: Jiri Slaby 
Cc: Luis Chamberlain 
Cc: Kees Cook 
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Dmitry Safonov 
Link: https://lore.kernel.org/r/20200302175135.269397-2-dima@arista.com
Signed-off-by: Greg Kroah-Hartman

proc: convert everything to "struct proc_ops"

2020-02-04T03:05:26+00:00

The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in
seq_file.h.

Conversion rule is:

	llseek		=> proc_lseek
	unlocked_ioctl	=> proc_ioctl

	xxx		=> proc_xxx

	delete ".owner = THIS_MODULE" line

[akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c]
[sfr@canb.auug.org.au: fix kernel/sched/psi.c]
  Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au
Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2
Signed-off-by: Alexey Dobriyan 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sysrq: Remove sysrq_handler_registered

2019-12-17T13:46:23+00:00

sysrq_toggle_support() can be called in parallel, in return calling
input_(un)register_handler(), which fortunately is safe to call
in parallel and regardless of registered/unregistered status of
sysrq_handler.
Remove sysrq_handler_registered as it doesn't have any function there
and may confuse reader about possible race.

Signed-off-by: Dmitry Safonov 
Link: https://lore.kernel.org/r/20191213000657.931618-2-dima@arista.com
Signed-off-by: Greg Kroah-Hartman

panic: avoid the extra noise dmesg

2019-05-15T02:52:51+00:00

When kernel panic happens, it will first print the panic call stack,
then the ending msg like:

[   35.743249] ---[ end Kernel panic - not syncing: Fatal exception
[   35.749975] ------------[ cut here ]------------

The above message are very useful for debugging.

But if system is configured to not reboot on panic, say the
"panic_timeout" parameter equals 0, it will likely print out many noisy
message like WARN() call stack for each and every CPU except the panic
one, messages like below:

	WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190
	Call Trace:
	
	try_to_wake_up
	default_wake_function
	autoremove_wake_function
	__wake_up_common
	__wake_up_common_lock
	__wake_up
	wake_up_klogd_work_func
	irq_work_run_list
	irq_work_tick
	update_process_times
	tick_sched_timer
	__hrtimer_run_queues
	hrtimer_interrupt
	smp_apic_timer_interrupt
	apic_timer_interrupt

For people working in console mode, the screen will first show the panic
call stack, but immediately overridden by these noisy extra messages,
which makes debugging much more difficult, as the original context gets
lost on screen.

Also these noisy messages will confuse some users, as I have seen many bug
reporters posted the noisy message into bugzilla, instead of the real
panic call stack and context.

Adding a flag "suppress_printk" which gets set in panic() to avoid those
noisy messages, without changing current kernel behavior that both panic
blinking and sysrq magic key can work as is, suggested by Petr Mladek.

To verify this, make sure kernel is not configured to reboot on panic and
in console
 # echo c > /proc/sysrq-trigger
to see if console only prints out the panic call stack.

Link: http://lkml.kernel.org/r/1551430186-24169-1-git-send-email-feng.tang@intel.com
Signed-off-by: Feng Tang 
Suggested-by: Petr Mladek 
Reviewed-by: Petr Mladek 
Acked-by: Steven Rostedt (VMware) 
Acked-by: Sergey Senozhatsky 
Cc: Thomas Gleixner 
Cc: Kees Cook 
Cc: Borislav Petkov 
Cc: Andi Kleen 
Cc: Peter Zijlstra 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Sasha Levin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds