From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from mail.kernel.org ([198.145.29.99]:48134 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1730495AbeKGEfR (ORCPT <rfc822;stable@vger.kernel.org>);
        Tue, 6 Nov 2018 23:35:17 -0500
Date: Tue, 6 Nov 2018 14:06:17 -0500
From: Sasha Levin <sashal@kernel.org>
To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=
        <u.kleine-koenig@pengutronix.de>
Cc: stable@vger.kernel.org, kernel@pengutronix.de,
        Linus Walleij <linus.walleij@linaro.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: please backport 833eacc7b5913da9896bacd30db7d490aa777868 to
 stable
Message-ID: <20181106190617.GG151445@sasha-vm>
References: <20181105104956.fwly3zflzg6wtoqy@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20181105104956.fwly3zflzg6wtoqy@pengutronix.de>
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

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