When running some ptrace single step tests on x86-32 machine, the below problem is triggered:
BUG: sleeping function called from invalid context at linux-rt/kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 0, pid: 1041, name: dummy2 INFO: lockdep is turned off. Preemption disabled at:[<c100326f>] do_debug+0x1f/0x1a0
CPU: 10 PID: 1041 Comm: dummy2 Tainted: G W 4.1.13-rt13 #1 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 00000000 00000000 e1811e80 c1aa8306 00000000 e1811ea8 c1080517 c1d8b2e8 c100326f c100326f 00000411 e5b7d5b4 e1d521c4 00000005 e1811f74 e1811ec4 c1ab0eff e1d51cc0 e5b7d180 c1081403 e5b7d180 e5b7d180 e1811ee4 c1064b5a Call Trace: [<c1aa8306>] dump_stack+0x46/0x5c [<c1080517>] ___might_sleep+0x137/0x220 [<c100326f>] ? do_debug+0x1f/0x1a0 [<c100326f>] ? do_debug+0x1f/0x1a0 [<c1ab0eff>] rt_spin_lock+0x1f/0x80 [<c1081403>] ? preempt_count_sub+0xb3/0x110 [<c1064b5a>] do_force_sig_info+0x2a/0xc0 [<c106567d>] force_sig_info+0xd/0x10 [<c1010cff>] send_sigtrap+0x6f/0x80 [<c10033b1>] do_debug+0x161/0x1a0 [<c1ab2921>] debug_stack_correct+0x2e/0x35
Signal send delay is just available for x86-64, x86-32 needs it too.
Signed-off-by: Yang Shi yang.shi@linaro.org --- arch/x86/include/asm/signal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h index b1b08a2..0e7bfe9 100644 --- a/arch/x86/include/asm/signal.h +++ b/arch/x86/include/asm/signal.h @@ -32,7 +32,7 @@ typedef struct { * TIF_NOTIFY_RESUME and set up the signal to be sent on exit of the * trap. */ -#if defined(CONFIG_PREEMPT_RT_FULL) && defined(CONFIG_X86_64) +#if defined(CONFIG_PREEMPT_RT_FULL) #define ARCH_RT_DELAYS_SIGNAL_SEND #endif
* Yang Shi | 2015-12-10 10:58:51 [-0800]:
When running some ptrace single step tests on x86-32 machine, the below problem is triggered:
BUG: sleeping function called from invalid context at linux-rt/kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 0, pid: 1041, name: dummy2 INFO: lockdep is turned off. Preemption disabled at:[<c100326f>] do_debug+0x1f/0x1a0
CPU: 10 PID: 1041 Comm: dummy2 Tainted: G W 4.1.13-rt13 #1 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 00000000 00000000 e1811e80 c1aa8306 00000000 e1811ea8 c1080517 c1d8b2e8 c100326f c100326f 00000411 e5b7d5b4 e1d521c4 00000005 e1811f74 e1811ec4 c1ab0eff e1d51cc0 e5b7d180 c1081403 e5b7d180 e5b7d180 e1811ee4 c1064b5a Call Trace: [<c1aa8306>] dump_stack+0x46/0x5c [<c1080517>] ___might_sleep+0x137/0x220 [<c100326f>] ? do_debug+0x1f/0x1a0 [<c100326f>] ? do_debug+0x1f/0x1a0 [<c1ab0eff>] rt_spin_lock+0x1f/0x80 [<c1081403>] ? preempt_count_sub+0xb3/0x110 [<c1064b5a>] do_force_sig_info+0x2a/0xc0 [<c106567d>] force_sig_info+0xd/0x10 [<c1010cff>] send_sigtrap+0x6f/0x80 [<c10033b1>] do_debug+0x161/0x1a0 [<c1ab2921>] debug_stack_correct+0x2e/0x35
Signal send delay is just available for x86-64, x86-32 needs it too.
This is new, this was not the case earlier. New means since v4.0-rc1 which is when 959274753857 ("x86, traps: Track entry into and exit from IST context") got merged. Since now ist_enter() disables preemption in any case, our hacks to conditional_sti_ist() are pointless and could be removed.
Sebastian
On 12/11/2015 10:05 AM, Sebastian Andrzej Siewior wrote:
- Yang Shi | 2015-12-10 10:58:51 [-0800]:
When running some ptrace single step tests on x86-32 machine, the below problem is triggered:
BUG: sleeping function called from invalid context at linux-rt/kernel/locking/rtmutex.c:917 in_atomic(): 1, irqs_disabled(): 0, pid: 1041, name: dummy2 INFO: lockdep is turned off. Preemption disabled at:[<c100326f>] do_debug+0x1f/0x1a0
CPU: 10 PID: 1041 Comm: dummy2 Tainted: G W 4.1.13-rt13 #1 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 00000000 00000000 e1811e80 c1aa8306 00000000 e1811ea8 c1080517 c1d8b2e8 c100326f c100326f 00000411 e5b7d5b4 e1d521c4 00000005 e1811f74 e1811ec4 c1ab0eff e1d51cc0 e5b7d180 c1081403 e5b7d180 e5b7d180 e1811ee4 c1064b5a Call Trace: [<c1aa8306>] dump_stack+0x46/0x5c [<c1080517>] ___might_sleep+0x137/0x220 [<c100326f>] ? do_debug+0x1f/0x1a0 [<c100326f>] ? do_debug+0x1f/0x1a0 [<c1ab0eff>] rt_spin_lock+0x1f/0x80 [<c1081403>] ? preempt_count_sub+0xb3/0x110 [<c1064b5a>] do_force_sig_info+0x2a/0xc0 [<c106567d>] force_sig_info+0xd/0x10 [<c1010cff>] send_sigtrap+0x6f/0x80 [<c10033b1>] do_debug+0x161/0x1a0 [<c1ab2921>] debug_stack_correct+0x2e/0x35
Signal send delay is just available for x86-64, x86-32 needs it too.
This is new, this was not the case earlier. New means since v4.0-rc1 which
Yes, it is. We didn't find this problem in earlier version kernel (I'd say 3.x).
is when 959274753857 ("x86, traps: Track entry into and exit from IST context") got merged. Since now ist_enter() disables preemption in any case, our hacks to conditional_sti_ist() are pointless and could be removed.
I'm supposed you will revert it and not need a revert patch from me.
Thanks for the deeper cause analysis.
Yang
Sebastian
On Fri, 11 Dec 2015, Shi, Yang wrote:
On 12/11/2015 10:05 AM, Sebastian Andrzej Siewior wrote:
- Yang Shi | 2015-12-10 10:58:51 [-0800]:
Signal send delay is just available for x86-64, x86-32 needs it too.
This is new, this was not the case earlier. New means since v4.0-rc1 which
Yes, it is. We didn't find this problem in earlier version kernel (I'd say 3.x).
is when 959274753857 ("x86, traps: Track entry into and exit from IST context") got merged. Since now ist_enter() disables preemption in any case, our hacks to conditional_sti_ist() are pointless and could be removed.
I'm supposed you will revert it and not need a revert patch from me.
Why do you think that reverting it is a good idea? Just because we can or what?
No, we fix it up on the RT side.
Thanks,
tglx
2015年12月12日星期六，Thomas Gleixner tglx@linutronix.de 写道：
On Fri, 11 Dec 2015, Shi, Yang wrote:
On 12/11/2015 10:05 AM, Sebastian Andrzej Siewior wrote:
- Yang Shi | 2015-12-10 10:58:51 [-0800]:
Signal send delay is just available for x86-64, x86-32 needs it too.
This is new, this was not the case earlier. New means since v4.0-rc1
which
Yes, it is. We didn't find this problem in earlier version kernel (I'd
say
3.x).
is when 959274753857 ("x86, traps: Track entry into and exit from IST context") got merged. Since now ist_enter() disables preemption in any case, our hacks to conditional_sti_ist() are pointless and could be removed.
I'm supposed you will revert it and not need a revert patch from me.
Why do you think that reverting it is a good idea? Just because we can or what?
At the first place, I thought the conditional_sti_ist doesn't make sense anymore as what Sebastian mentioned. So, I'm supposed Steven's patch should be removed.
No, we fix it up on the RT side.
This directed me look into the code a little further.
It sounds the conditional approach may be still feasible with ist_begin_non_atomic.
I will look into it further then propose a fix.
Thanks, Yang
Thanks,
tglx-- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org javascript:; More majordomo info at http://vger.kernel.org/majordomo-info.html
linaro-kernel@lists.linaro.org
-
Sebastian Andrzej Siewior -
Shi, Yang -
Thomas Gleixner -
Yang Shi -
Yang Shi