linux-stable.git/drivers/tty/sysrq.c, branch linux-5.6.y

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

tty/sysrq: Convert show_lock to raw_spinlock_t

2019-03-27T16:24:55+00:00

Systems which don't provide arch_trigger_cpumask_backtrace() will
invoke showacpu() from a smp_call_function() function which is invoked
with disabled interrupts even on -RT systems.

The function acquires the show_lock lock which only purpose is to
ensure that the CPUs don't print simultaneously. Otherwise the
output would clash and it would be hard to tell the output from CPUx
apart from CPUy.

On -RT the spin_lock() can not be acquired from this context. A
raw_spin_lock() is required. It will introduce the system's latency
by performing the sysrq request and other CPUs will block on the lock
until the request is done. This is okay because the user asked for a
backtrace of all active CPUs and under "normal circumstances in
production" this path should not be triggered.

Signed-off-by: Julien Grall 
[bigeasy@linuxtronix.de: commit description]
Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman

sysrq: Remove duplicated sysrq message

2019-01-22T12:46:53+00:00

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")
Signed-off-by: Petr Mladek 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Greg Kroah-Hartman

sysrq: Restore original console_loglevel when sysrq disabled

2019-01-22T12:46:53+00:00

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").

Signed-off-by: Petr Mladek 
Reviewed-by: Sergey Senozhatsky 
Reviewed-by: Steven Rostedt (VMware) 
Signed-off-by: Greg Kroah-Hartman

tty/sysrq: Do not call sync directly from sysrq_do_reset()

2018-12-05T11:02:12+00:00

sysrq_do_reset() is called in softirq context, so it cannot call
sync() directly. Instead, call orderly_reboot(), which creates a work
item to run /sbin/reboot, or do emergency_sync and restart if the
command fails.

Signed-off-by: Mark Tomlinson 
Signed-off-by: Greg Kroah-Hartman

sysrq: Use panic() to force a crash

2018-11-27T10:16:35+00:00

sysrq_handle_crash() currently forces a crash by dereferencing a
NULL pointer, which is undefined behavior in C. Just call panic()
instead, which is simpler and doesn't depend on compiler specific
handling of the undefined behavior.

Remove the comment on why the RCU lock needs to be released, it isn't
accurate anymore since the crash now isn't handled by the page fault
handler (for reference: the comment was added by commit 984cf355aeaa
("sysrq: Fix warning in sysrq generated crash.")). Releasing the lock
is still good practice though.

Suggested-by: Greg Kroah-Hartman 
Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Greg Kroah-Hartman

tty/sysrq: add of_node_put()

2018-11-27T10:16:35+00:00

of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
bl_idle_init() doesn't do that, so fix it.

Signed-off-by: Yangtao Li 
Signed-off-by: Greg Kroah-Hartman

signal: send_sig_all no longer needs SEND_SIG_FORCED

2018-09-11T19:19:07+00:00

Now that send_signal always delivers SEND_SIG_PRIV signals to a pid
namespace init it is no longer necessary to use SEND_SIG_FORCED when
calling do_send_sig_info to ensure that pid namespace inits are
signaled and possibly killed.  Using SEND_SIG_PRIV is sufficient.

So use SEND_SIG_PRIV so that userspace when it receives a SIGTERM can
tell that the kernel sent the signal and not some random userspace
application.

Fixes: b82c32872db2 ("sysrq: use SEND_SIG_FORCED instead of force_sig()")
Reviewed-by: Thomas Gleixner 
Signed-off-by: "Eric W. Biederman"