please backport 833eacc7b5913da9896bacd30db7d490aa777868 to stable

please backport 833eacc7b5913da9896bacd30db7d490aa777868 to stable

[Uwe Kleine-König]

Hello,

on an mxs machine running a v4.9-rt kernel I saw the following
backtrace:

[   25.309794] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:987
[   25.309810] in_atomic(): 1, irqs_disabled(): 128, pid: 221, name: mrp62439d
[   25.309834] CPU: 0 PID: 221 Comm: mrp62439d Not tainted 4.9.109-20180709-1-rt76-00043-g80a57dee2c6b-dirty #43
[   25.309840] Hardware name: Freescale MXS (Device Tree)
[   25.309913] [<c000fad8>] (unwind_backtrace) from [<c000df34>] (show_stack+0x18/0x1c)
[   25.309957] [<c000df34>] (show_stack) from [<c0042924>] (___might_sleep+0xf8/0x164)
[   25.309996] [<c0042924>] (___might_sleep) from [<c04ec920>] (rt_spin_lock+0x20/0x6c)
[   25.310039] [<c04ec920>] (rt_spin_lock) from [<c02e5a20>] (gpio_to_desc+0x1c/0xbc)
[   25.310076] [<c02e5a20>] (gpio_to_desc) from [<c02ec358>] (mxs_gpio_set_irq_type+0x114/0x194)
[   25.310107] [<c02ec358>] (mxs_gpio_set_irq_type) from [<c00558d8>] (__irq_set_trigger+0x64/0x158)
[   25.310132] [<c00558d8>] (__irq_set_trigger) from [<c0055f74>] (__setup_irq+0x5a8/0x694)
[   25.310156] [<c0055f74>] (__setup_irq) from [<c0056408>] (request_threaded_irq+0xe4/0x18c)
[   25.310187] [<c0056408>] (request_threaded_irq) from [<c02e8650>] (gpio_ioctl+0x304/0x680)
[   25.310217] [<c02e8650>] (gpio_ioctl) from [<c01476a4>] (do_vfs_ioctl+0x98/0x970)
[   25.310241] [<c01476a4>] (do_vfs_ioctl) from [<c0147fb8>] (SyS_ioctl+0x3c/0x64)
[   25.310264] [<c0147fb8>] (SyS_ioctl) from [<c000a4d8>] (__sys_trace_return+0x0/0x10)

The problem is that __irq_set_trigger is called in atomic context (even on rt)
and mxs_gpio_set_irq_type calls gpio_get_value which takes the
(sleeping on rt) gpio_lock.

I didn't test 833eacc7b5913da9896bacd30db7d490aa777868 yet (I used

	val = readl(port->base + PINCTRL_DIN(port)) & pin_mask;

instead) but this commit should have the same effect.

Can you please backport this? (There are maybe some more similar
problems that were introduced in v4.5-rc1 / 0f4630f3720e7e, I didn't
check these though.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K�nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: please backport 833eacc7b5913da9896bacd30db7d490aa777868 to stable

[Sasha Levin]

On Mon, Nov 05, 2018 at 11:49:56AM +0100, Uwe Kleine-K�nig wrote:
>Hello,
>
>on an mxs machine running a v4.9-rt kernel I saw the following
>backtrace:
>
>[   25.309794] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:987
>[   25.309810] in_atomic(): 1, irqs_disabled(): 128, pid: 221, name: mrp62439d
>[   25.309834] CPU: 0 PID: 221 Comm: mrp62439d Not tainted 4.9.109-20180709-1-rt76-00043-g80a57dee2c6b-dirty #43
>[   25.309840] Hardware name: Freescale MXS (Device Tree)
>[   25.309913] [<c000fad8>] (unwind_backtrace) from [<c000df34>] (show_stack+0x18/0x1c)
>[   25.309957] [<c000df34>] (show_stack) from [<c0042924>] (___might_sleep+0xf8/0x164)
>[   25.309996] [<c0042924>] (___might_sleep) from [<c04ec920>] (rt_spin_lock+0x20/0x6c)
>[   25.310039] [<c04ec920>] (rt_spin_lock) from [<c02e5a20>] (gpio_to_desc+0x1c/0xbc)
>[   25.310076] [<c02e5a20>] (gpio_to_desc) from [<c02ec358>] (mxs_gpio_set_irq_type+0x114/0x194)
>[   25.310107] [<c02ec358>] (mxs_gpio_set_irq_type) from [<c00558d8>] (__irq_set_trigger+0x64/0x158)
>[   25.310132] [<c00558d8>] (__irq_set_trigger) from [<c0055f74>] (__setup_irq+0x5a8/0x694)
>[   25.310156] [<c0055f74>] (__setup_irq) from [<c0056408>] (request_threaded_irq+0xe4/0x18c)
>[   25.310187] [<c0056408>] (request_threaded_irq) from [<c02e8650>] (gpio_ioctl+0x304/0x680)
>[   25.310217] [<c02e8650>] (gpio_ioctl) from [<c01476a4>] (do_vfs_ioctl+0x98/0x970)
>[   25.310241] [<c01476a4>] (do_vfs_ioctl) from [<c0147fb8>] (SyS_ioctl+0x3c/0x64)
>[   25.310264] [<c0147fb8>] (SyS_ioctl) from [<c000a4d8>] (__sys_trace_return+0x0/0x10)
>
>The problem is that __irq_set_trigger is called in atomic context (even on rt)
>and mxs_gpio_set_irq_type calls gpio_get_value which takes the
>(sleeping on rt) gpio_lock.
>
>I didn't test 833eacc7b5913da9896bacd30db7d490aa777868 yet (I used
>
>	val = readl(port->base + PINCTRL_DIN(port)) & pin_mask;
>
>instead) but this commit should have the same effect.
>
>Can you please backport this? (There are maybe some more similar
>problems that were introduced in v4.5-rc1 / 0f4630f3720e7e, I didn't
>check these though.)

Queued for 4.9-4.19. Thank you.

--
Thanks,
Sasha