In the PREEMPT-RT, signals sent in the atomic context are delayed
because of the usage of RT Mutex in the signals' code. This is done with
the -rt specific patch:
------------------------ %< ---------------------
Author: Oleg Nesterov <oleg@xxxxxxxxxx>
Date: Tue Jul 14 14:26:34 2015 +0200
signal/x86: Delay calling signals in atomic
------------------------ >% ---------------------
However, while running the Red Hat's 3.10 kernel-rt, we've got
the following sleeping function called in atomic message:
------------------------ %< ---------------------
[98808.179131] BUG: sleeping function called from invalid context at kernel/rtmutex.c:883
[98808.179133] in_atomic(): 0, irqs_disabled(): 1, pid: 15205, name: ptrace07
[98808.179134] INFO: lockdep is turned off.
[98808.179134] irq event stamp: 0
[98808.179136] hardirqs last enabled at (0): [< (null)>] (null)
[98808.179142] hardirqs last disabled at (0): [<ffffffffb7491959>] copy_process+0x849/0x1f80
[98808.179144] softirqs last enabled at (0): [<ffffffffb7491959>] copy_process+0x849/0x1f80
[98808.179146] softirqs last disabled at (0): [< (null)>] (null)
[98808.179149] CPU: 0 PID: 15205 Comm: ptrace07 Kdump: loaded Tainted: G W
------------ T 3.10.0-931.rt56.880.el7.x86_64.debug #1
[98808.179150] Hardware name: AMD Pike/Pike, BIOS WPK2815X_Weekly_12_08_15 08/13/2012
[98808.179151] Call Trace:
[98808.179155] [<ffffffffb7c2d3fc>] dump_stack+0x19/0x1b
[98808.179158] [<ffffffffb74de3dd>] __might_sleep+0x12d/0x1f0
[98808.179160] [<ffffffffb7c36af4>] rt_spin_lock+0x24/0x60
[98808.179163] [<ffffffffb74b00ac>] force_sig_info+0x17c/0x2c0
[98808.179164] [<ffffffffb74b0206>] force_sig+0x16/0x20
[98808.179167] [<ffffffffb741c395>] math_state_restore+0x115/0x1e0
[98808.179169] [<ffffffffb7c39755>] do_device_not_available+0x35/0x50
[98808.179172] [<ffffffffb7c44f9e>] device_not_available+0x1e/0x30
[98808.179174] ---------------------------
[98808.179174] | preempt count: 00000000 ]
[98808.179175] | 0-level deep critical section nesting:
[98808.179176] ----------------------------------------
------------------------ >% ---------------------
The -rt patch did not avoid the problem because, in this case, the
problem was not caused by preemption disabled, but irqs disabled.
This patch improves the previous patch by also checking if IRQs are
disabled.
I am suggesting this patch for -stable rt [3.10..3.18] branches because,
as far as I could see, this problem would not take place on
kernel-rt > 3.18 due to changes in the do_device_not_available(), that
does not call math_state_restore() anymore, because of changes in the
FPU code. However, the backport of FPU changes seems too be too complex,
justifying this band-aid patch.
Reported-by: Luis Claudio R. Goncalves <lgoncalv@xxxxxxxxxx>
Signed-off-by: Daniel Bristot de Oliveira <bristot@xxxxxxxxxx>
Tested-by: Luis Claudio R. Goncalves <lgoncalv@xxxxxxxxxx>
Cc: Clark Williams <williams@xxxxxxxxxx>
CC: Oleg Nesterov <oleg@xxxxxxxxxx>
Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
Cc: Luis Claudio R. Goncalves <lgoncalv@xxxxxxxxxx>
Cc: linux-rt-users@xxxxxxxxxxxxxxx
---
kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index ff47f666c629..69a8eebd8428 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1327,7 +1327,7 @@ int force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
* send the signal on exit of the trap.
*/
#ifdef ARCH_RT_DELAYS_SIGNAL_SEND
- if (in_atomic()) {
+ if (in_atomic() || irqs_disabled()) {
if (WARN_ON_ONCE(t != current))
return 0;
if (WARN_ON_ONCE(t->forced_info.si_signo))
--
2.17.1
