linux-kernel - Spinlock recursion detected on preempt-RT and interrupt handler set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 25 Jan 2009 22:46:10 +0100
From:	Remy Bohmer <linux@...mer.net>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	linux-rt-users <linux-rt-users@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Spinlock recursion detected on preempt-RT and interrupt handler 
	set_type code

Hello All,

I ran into a spinlock recursion problem while testing the locking
corrctness of a 2.6.24.7-rt26-kernel on a Freescale iMX processor
(ARM). Unfortunately this Freescale architecture code is not in
mainline, but at least the blackfin architecture seems to have the
same setup (looking at bfin_gpio_irq_type() ), so it is not a
Freescale only problem.

What happens is that these routines are called in this order:
-> request_irq()
    -> setup_irq()  --> Lock the spinlock
(spin_lock_irqsave(&desc->lock, flags)) for the first time
        -> gpio_set_irq_type()  (or bfin_gpio_irq_type() on blackfin
in arch/blackfin/mach-common/ints-priority-sc.c)
            -> set_irq_handler()
               -> __set_irq_handler()   --> Locks the same spinlock a
2nd time, resulting in a BUG/hang, see below

I am looking at this code for a while now, and have not found a proper
solution to solve this problem yet. Does anyone have a great idea?

Kind Regards,

Remy


[    3.705384] BUG: spinlock recursion on CPU#0, swapper/1
[    3.710630]  lock: c03bc3c4, .magic: dead4ead, .owner: swapper/1,
.owner_cpu: 0
[    3.717944] [<c0034da8>] (dump_stack+0x0/0x14) from [<c016b558>]
(spin_bug+0x94/0xa8)
[    3.725867] [<c016b4c4>] (spin_bug+0x0/0xa8) from [<c02d49c4>]
(_raw_spin_lock+0x50/0x130)
[    3.734219]  r6:c7c26000 r5:c03bc3c4 r4:c03bc3c4
[    3.738890] [<c02d4974>] (_raw_spin_lock+0x0/0x130) from
[<c02d4250>] (__spin_lock_irqsave+0x28/0x30)
[    3.748181] [<c02d4228>] (__spin_lock_irqsave+0x0/0x30) from
[<c007cd44>] (__set_irq_handler+0x90/0x16c)
[    3.757731]  r5:0000007a r4:c03bc344
[    3.761343] [<c007ccb4>] (__set_irq_handler+0x0/0x16c) from
[<c00424a8>] (gpio_set_irq_type+0xd4/0x138)
[    3.770814] [<c00423d4>] (gpio_set_irq_type+0x0/0x138) from
[<c007c178>] (setup_irq+0x12c/0x20c)
[    3.779688]  r6:c7e877e0 r5:c03bc344 r4:00000000
[    3.784356] [<c007c04c>] (setup_irq+0x0/0x20c) from [<c007c2f0>]
(request_irq+0x98/0xc0)
[    3.792512] [<c007c258>] (request_irq+0x0/0xc0) from [<c01fb210>]
(clearpad_probe+0x3a0/0x414)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/