On Fri, Jan 20, 2017 at 5:13 PM, Julia Cartwright [off-list ref] wrote:

The MSM pinctrl driver currently implements an irq_chip for handling
GPIO interrupts; due to how irq_chip handling is done, it's necessary
for the irq_chip methods to be invoked from hardirq context, even on a
a real-time kernel.  Because the spinlock_t type becomes a "sleeping"
spinlock w/ RT kernels, it is not suitable to be used with irq_chips.

A quick audit of the operations under the lock reveal that they do only
minimal, bounded work, and are therefore safe to do under a raw
spinlock.

On real-time kernels, this fixes an OOPs which looks like the following,
as reported by Brian Wrenn:

    kernel BUG at kernel/locking/rtmutex.c:1014!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in: spidev_irq(O) smsc75xx wcn36xx [last unloaded: spidev]
    CPU: 0 PID: 1163 Comm: irq/144-mmc0 Tainted: G        W  O    4.4.9-linaro-lt-qcom #1
    PC is at rt_spin_lock_slowlock+0x80/0x2d8
    LR is at rt_spin_lock_slowlock+0x68/0x2d8
    [..]
  Call trace:
    rt_spin_lock_slowlock
    rt_spin_lock
    msm_gpio_irq_ack
    handle_edge_irq
    generic_handle_irq
    msm_gpio_irq_handler
    generic_handle_irq
    __handle_domain_irq
    gic_handle_irq

Cc: Bjorn Andersson <redacted>
Reported-by: Brian Wrenn <redacted>
Tested-by: Brian Wrenn <redacted>
Signed-off-by: Julia Cartwright <redacted>

Patch applied with Björn's ACK.
Thanks for a very nice patch!

Linus-  on quick glance, this is but one of many drivers which suffer
the same class of problem :(.  I'm wondering if we can do some
coccinelle magic to check specifically drivers which implement irq_chip
callbacks and use spin_locks...

That would be awesome. I'm aware of the problem, but irqchips
are kind of fragile, so patches definately need to be tested on
hardware. If we get some patches and good example into the
kernel, hopefully we can get the situation a bit better.

Yours,
Linus Walleij