Triggering BUG on SIGSEGV signaling

Triggering BUG on SIGSEGV signaling

[Alexander Stein]

On our system (i.MX35 based, so ARMv6) is running a v3.10.47-rt50 kernel, I get the following output from serial console when the application tries to dereference a NULL pointer:
> BUG: sleeping function called from invalid context at kernel/rtmutex.c:659
> in_atomic(): 0, irqs_disabled(): 128, pid: 648, name: plccore-imx35-h
> CPU: 0 PID: 648 Comm: plccore-imx35-h Tainted: G           O 3.10.47-rt50 #1
> [<c001367c>] (unwind_backtrace+0x0/0x130) from [<c0011e50>] (show_stack+0x10/0x14)
> [<c0011e50>] (show_stack+0x10/0x14) from [<c03b0738>] (rt_spin_lock+0x18/0x2c)
> [<c03b0738>] (rt_spin_lock+0x18/0x2c) from [<c002fd44>] (do_force_sig_info+0x20/0xd8)
> [<c002fd44>] (do_force_sig_info+0x20/0xd8) from [<c0017dac>] (__do_user_fault+0x98/0xd8)
> [<c0017dac>] (__do_user_fault+0x98/0xd8) from [<c0018144>] (do_bad_area+0x6c/0x88)
> [<c0018144>] (do_bad_area+0x6c/0x88) from [<c00181cc>] (do_translation_fault+0x6c/0xa8)
> [<c00181cc>] (do_translation_fault+0x6c/0xa8) from [<c0008344>] (do_DataAbort+0x34/0x9c)
> [<c0008344>] (do_DataAbort+0x34/0x9c) from [<c000e914>] (__dabt_usr+0x34/0x40)
> Exception stack(0xc5c91fb0 to 0xc5c91ff8)
> 1fa0:                                     efcdefcd 00000001 00000001 00084690
> 1fc0: 00000010 00000000 00000000 00000003 014dd2c4 00000002 00000000 000000ff
> 1fe0: 0c8a7b41 be8c9b58 000219a8 000219c8 60000010 ffffffff

Reading the backtrace it seems that might_sleep() in rt_spin_lock_fastlock() raises this dump. The interrupts are apparently disabled.
Following the code path it seems to me, that (at lease in this case) ARCH_RT_DELAYS_SIGNAL_SEND must be supported on ARM too which AFAICS is for sending signals while being in_atomic.
Any comments on this? I wonder what makes this so special it didn't came up yet.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

Re: Triggering BUG on SIGSEGV signaling

[Alexander Stein]

On Tuesday 24 November 2015 12:09:12, Alexander Stein wrote:
> On our system (i.MX35 based, so ARMv6) is running a v3.10.47-rt50 kernel, I get the following output from serial console when the application tries to dereference a NULL pointer:
> > BUG: sleeping function called from invalid context at kernel/rtmutex.c:659
> > in_atomic(): 0, irqs_disabled(): 128, pid: 648, name: plccore-imx35-h
> > CPU: 0 PID: 648 Comm: plccore-imx35-h Tainted: G           O 3.10.47-rt50 #1
> > [<c001367c>] (unwind_backtrace+0x0/0x130) from [<c0011e50>] (show_stack+0x10/0x14)
> > [<c0011e50>] (show_stack+0x10/0x14) from [<c03b0738>] (rt_spin_lock+0x18/0x2c)
> > [<c03b0738>] (rt_spin_lock+0x18/0x2c) from [<c002fd44>] (do_force_sig_info+0x20/0xd8)
> > [<c002fd44>] (do_force_sig_info+0x20/0xd8) from [<c0017dac>] (__do_user_fault+0x98/0xd8)
> > [<c0017dac>] (__do_user_fault+0x98/0xd8) from [<c0018144>] (do_bad_area+0x6c/0x88)
> > [<c0018144>] (do_bad_area+0x6c/0x88) from [<c00181cc>] (do_translation_fault+0x6c/0xa8)
> > [<c00181cc>] (do_translation_fault+0x6c/0xa8) from [<c0008344>] (do_DataAbort+0x34/0x9c)
> > [<c0008344>] (do_DataAbort+0x34/0x9c) from [<c000e914>] (__dabt_usr+0x34/0x40)
> > Exception stack(0xc5c91fb0 to 0xc5c91ff8)
> > 1fa0:                                     efcdefcd 00000001 00000001 00084690
> > 1fc0: 00000010 00000000 00000000 00000003 014dd2c4 00000002 00000000 000000ff
> > 1fe0: 0c8a7b41 be8c9b58 000219a8 000219c8 60000010 ffffffff
> 
> Reading the backtrace it seems that might_sleep() in rt_spin_lock_fastlock() raises this dump. The interrupts are apparently disabled.
> Following the code path it seems to me, that (at lease in this case) ARCH_RT_DELAYS_SIGNAL_SEND must be supported on ARM too which AFAICS is for sending signals while being in_atomic.
> Any comments on this? I wonder what makes this so special it didn't came up yet.

For the records, it's the same bug which is fixed by https://kernel.googlesource.com/pub/scm/linux/kernel/git/rt/linux-rt-devel/+/v4.1.3-rt3-patches/patches/ARM-enable-irq-in-translation-section-permission-fau.patch
This also fixes my problem on the old kernel.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

Re: Triggering BUG on SIGSEGV signaling

[Sebastian Andrzej Siewior]

* Alexander Stein | 2015-11-26 13:10:04 [+0100]:

>For the records, it's the same bug which is fixed by https://kernel.googlesource.com/pub/scm/linux/kernel/git/rt/linux-rt-devel/+/v4.1.3-rt3-patches/patches/ARM-enable-irq-in-translation-section-permission-fau.patch
>This also fixes my problem on the old kernel.

Steven has been a good boy and merged this patch and a few others into
the latest v3.10 based -RT kernel. However if prefer to use v3.10.47-rt50
you might run into other bugs as well which are fixed in the meantime.

>Best regards,
>Alexander

Sebastian