From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754783AbdFWWk5 (ORCPT ); Fri, 23 Jun 2017 18:40:57 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:44843 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752606AbdFWWkz (ORCPT ); Fri, 23 Jun 2017 18:40:55 -0400 Date: Fri, 23 Jun 2017 15:40:49 -0700 From: "Paul E. McKenney" To: Thomas Gleixner Cc: Brian Norris , Heiko Stuebner , Linus Walleij , linux-rockchip@lists.infradead.org, Julia Cartwright , LKML , linux-gpio@vger.kernel.org, John Keeping , linux-pm@vger.kernel.org, Doug Anderson , Peter Zijlstra , Tony Lindgren Subject: Re: [PATCH for 4.12] Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip" Reply-To: paulmck@linux.vnet.ibm.com References: <20170517225634.GA11404@google.com> <20170527021900.GA119873@google.com> <20170623205911.GA143883@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17062322-0040-0000-0000-0000036C27E7 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007279; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00878879; UDB=6.00437974; IPR=6.00659031; BA=6.00005438; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015946; XFM=3.00000015; UTC=2017-06-23 22:40:53 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17062322-0041-0000-0000-000007604198 Message-Id: <20170623224049.GP3721@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-23_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230384 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 24, 2017 at 12:12:49AM +0200, Thomas Gleixner wrote: > On Fri, 23 Jun 2017, Brian Norris wrote: > > > This reverts commit 88bb94216f59e10802aaf78c858a4146085faf18. > > > > It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1: > > > > [ 7226.716713] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238 > > [ 7226.716716] in_atomic(): 0, irqs_disabled(): 0, pid: 1708, name: bash > > [ 7226.716722] CPU: 1 PID: 1708 Comm: bash Not tainted 4.12.0-rc6+ #1213 > > [ 7226.716724] Hardware name: Google Kevin (DT) > > [ 7226.716726] Call trace: > > [ 7226.716738] [] dump_backtrace+0x0/0x24c > > [ 7226.716743] [] show_stack+0x20/0x28 > > [ 7226.716749] [] dump_stack+0x90/0xb0 > > [ 7226.716755] [] ___might_sleep+0x10c/0x124 > > [ 7226.716760] [] __might_sleep+0x78/0x88 > > [ 7226.716765] [] mutex_lock+0x2c/0x64 > > [ 7226.716771] [] rockchip_irq_bus_lock+0x30/0x3c > > [ 7226.716777] [] __irq_get_desc_lock+0x78/0x98 > > [ 7226.716782] [] irq_set_irq_wake+0x44/0x12c > > [ 7226.716787] [] dev_pm_arm_wake_irq+0x4c/0x58 > > [ 7226.716792] [] device_wakeup_arm_wake_irqs+0x3c/0x58 > > [ 7226.716796] [] dpm_suspend_noirq+0xf8/0x3a0 > > [ 7226.716800] [] suspend_devices_and_enter+0x1a4/0x9a8 > > [ 7226.716803] [] pm_suspend+0x664/0x6a4 > > [ 7226.716807] [] state_store+0xd4/0xf8 > > ... > > > > It was reported on -rc1, and it's still not fixed in -rc6, so it should > > just be reverted. > > > > + Thomas, in case he has thoughts > > + Peter and Paul, Tony > > > Subject was "[4.12 REGRESSION] pinctrl: rockchip: sleeping function > > called from atomic context" > > > > On Fri, May 26, 2017 at 07:19:00PM -0700, Brian Norris wrote: > > > Any thoughts? Revert the offending patch? I can spend a little more time > > > next week trying to debug what's actually going on if needed. > > > > > > On Wed, May 17, 2017 at 03:56:34PM -0700, Brian Norris wrote: > > > > > > The thing is, the documentation (and apparent design) suggest that > > > > calling sleeping functions from ->irq_bus_lock() is perfectly valid. I'm > > > > not 100% following the ___might_sleep() logic, but is this complaining > > > > because of the RCU read locking in device_wakeup_arm_wake_irqs()? I have > > > > CONFIG_PREEMPT_RCU and CONFIG_PREEMPT enabled, FWIW. > > Sigh, The real wreckage happened in commit: > > commit 4990d4fe327b9d9a7a3be7103a82699406fdde69 > Author: Tony Lindgren > Date: Mon May 18 15:40:29 2015 -0700 > > PM / Wakeirq: Add automated device wake IRQ handling > > which added that RCU locking stuff and thereby broke the long existing > bus_lock() facility of the interrupt core. > > irq_bus_lock/unlock was explicitely made to allow sleeping locks for > interrupt chips which hang behind slow busses like i2c or spi. It took us > quite some effort to get this done and that patch broke it permanently. > > I'm not sure what to do here. This is an ever recurring issue simply > because RT requires that sleeping locks can be taken inside rcu locked > regions. So sooner than later we need a resoilution for that problem. The usual advice would be for 4990d4fe327b ("PM / Wakeirq: Add automated device wake IRQ handling") to use SRCU rather than RCU. Is there some reason that won't work? And yes, my commit 5b72f9643b52a ("rcu: Complain if blocking in preemptible RCU read-side critical section") that is now in -tip needs adjustment for -rt. I can easily add "&& IS_ENABLED(CONFIG_PREEMPT_RT)" or whatever the current incantation is. Just let me know! Thanx, Paul