From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D42FC4332F for ; Mon, 25 Oct 2021 10:30:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 82A6C60E52 for ; Mon, 25 Oct 2021 10:30:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232854AbhJYKcn (ORCPT ); Mon, 25 Oct 2021 06:32:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230267AbhJYKcl (ORCPT ); Mon, 25 Oct 2021 06:32:41 -0400 Received: from metanate.com (unknown [IPv6:2001:8b0:1628:5005::111]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BE88C061745; Mon, 25 Oct 2021 03:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metanate.com; s=stronger; h=Content-Transfer-Encoding:Content-Type: References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID :Content-Description; bh=zaVg4jBc9F4rk3WaC2BbIGzIvbQck+4g8h3ofbOG7k0=; b=ZbPo LvulK7ILdjJM7xAIoJFe/wEuFTRA/Z/DLCyf3Sgu8avt1fA3+Vr/PuDRBSlUOyp4U1eLAKXpkr3lG +nS9h235f/vegS0mVCH6SnPgykf1731fOdCrc3O9HN8WjlxHZS3S5bTx2hiU+Xx5MQ3gk0E7/UeYz 9R3ThRzTLLsMIMYFOOOsioPE+TuH05PgCcqROAqLap5vOtW6KDNp7/MTxaZaoy+nckDiCP3kSgVOk mjdiQ00N/DttyPkVpi1AUZwAmt+3ws2xOu/R7bqCaF3Ib6Dy5F4rb+xSZZkhMv94phQF6/dRk1R3c M9+f3SpQolzKaOcME5T94uZBSeq7Hw==; Received: from [81.174.171.191] (helo=donbot) by email.metanate.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mexF6-0002VB-Gf; Mon, 25 Oct 2021 11:30:12 +0100 Date: Mon, 25 Oct 2021 11:30:07 +0100 From: John Keeping To: "Rafael J. Wysocki" Cc: linux-rt-users@vger.kernel.org, Pavel Machek , Len Brown , Greg Kroah-Hartman , Linux PM , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , Peter Zijlstra Subject: Re: [RFC PATCH RT] PM: runtime: avoid retry loops on RT Message-ID: <20211025113007.6d09bfed.john@metanate.com> In-Reply-To: References: <20211005155427.1591196-1-john@metanate.com> <20211005181706.66102578.john@metanate.com> <20211006191813.0e097b9f.john@metanate.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authenticated: YES Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Oct 2021 12:37:05 +0200 "Rafael J. Wysocki" wrote: > The initial motivation for adding irq_safe was to allow interrupt > handlers of some devices to use PM-runtime, but in RT kernels that's > possible regardless IIUC, so I don't see a reason for having irq_safe > at all in that case. I coded up the "no irq_safe" version but lockdep complains loudly about it: BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1111 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 237, name: pm-runtime-prio preempt_count: 0, expected: 0 RCU nest depth: 2, expected: 0 INFO: lockdep is turned off. CPU: 3 PID: 237 Comm: pm-runtime-prio Tainted: G W 5.15.0-rc6-rt13 #1 Hardware name: Rockchip (Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack_lvl+0x58/0x70) [] (dump_stack_lvl) from [] (__might_resched+0x1dc/0x270) [] (__might_resched) from [] (__pm_runtime_resume+0x2c/0x6c) [] (__pm_runtime_resume) from [] (pl330_issue_pending+0x60/0x84) [] (pl330_issue_pending) from [] (snd_dmaengine_pcm_trigger+0xec/0x14c) [] (snd_dmaengine_pcm_trigger) from [] (soc_component_trigger+0x20/0x38) [] (soc_component_trigger) from [] (snd_soc_pcm_component_trigger+0xd8/0xf4) [] (snd_soc_pcm_component_trigger) from [] (soc_pcm_trigger+0x48/0x154) [] (soc_pcm_trigger) from [] (snd_pcm_action_single+0x38/0x64) [] (snd_pcm_action_single) from [] (snd_pcm_action+0x5c/0x60) [] (snd_pcm_action) from [] (snd_pcm_action_lock_irq+0x28/0x3c) [] (snd_pcm_action_lock_irq) from [] (vfs_ioctl+0x20/0x38) [] (vfs_ioctl) from [] (sys_ioctl+0xc0/0x96c) [] (sys_ioctl) from [] (ret_fast_syscall+0x0/0x1c) Now that I have a reliable reproducer, it turns out the original patch in this thread also has problems and causes a WARN from RCU. The version I have now that seems to work and doesn't cause any dmesg complaints is below, but I'm really not sure if this is considered an acceptable use of schedule_rtlock() (I suspect this also fails to compile without CONFIG_PREEMPT_RT since schedule_rtlock() isn't declared in that case). -- >8 -- diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index ec94049442b9..79cf9997f71b 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -596,7 +596,7 @@ static int rpm_suspend(struct device *dev, int rpmflags) goto out; } - if (dev->power.irq_safe) { + if (dev->power.irq_safe && !IS_ENABLED(CONFIG_PREEMPT_RT)) { spin_unlock(&dev->power.lock); cpu_relax(); @@ -614,7 +614,10 @@ static int rpm_suspend(struct device *dev, int rpmflags) spin_unlock_irq(&dev->power.lock); - schedule(); + if (dev->power.irq_safe) + schedule_rtlock(); + else + schedule(); spin_lock_irq(&dev->power.lock); } @@ -777,7 +780,7 @@ static int rpm_resume(struct device *dev, int rpmflags) goto out; } - if (dev->power.irq_safe) { + if (dev->power.irq_safe && !IS_ENABLED(CONFIG_PREEMPT_RT)) { spin_unlock(&dev->power.lock); cpu_relax(); @@ -796,7 +799,10 @@ static int rpm_resume(struct device *dev, int rpmflags) spin_unlock_irq(&dev->power.lock); - schedule(); + if (dev->power.irq_safe) + schedule_rtlock(); + else + schedule(); spin_lock_irq(&dev->power.lock); }