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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20BB2C433DB for ; Thu, 18 Feb 2021 15:46:17 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5284B64E6F for ; Thu, 18 Feb 2021 15:46:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5284B64E6F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gnYXPkUV44ZYEyVOc2/F+7scGdisCV0pLvIoqccXch0=; b=XrpkkwzS1ry2/OQsXyDyggbeL bBy2JH0oh6VJ4YKBF5R6fSbSqBX3wNp+l94kHdcE0jKDIMFLbWFr9YnKaAZN1CKESdi4YvAYEFoCJ o9awBzBkpBrJrxAkQ0gIM24aY+mMvvymMpEK31U4b3NlhA9R2uRCHYfWBQevRhfDFD49bpWYGcX0/ 9mNwCMealx/Ov5F2l4vkAy0y6CXOI4IjjpeV1B0AzVOLaT9XJPbWV1zh+4IpHQjsCQ75qf1e8TdO5 iqwmXWfWKrq2HY5CuFFhwT6mPNcPFQvOFvD6cRFFdrZts8x5wXr79J2hztFqiixeWqokxxeY+/b9F C335P1mhw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lClTh-0005hK-OD; Thu, 18 Feb 2021 15:44:29 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lClTf-0005gw-2x for linux-arm-kernel@lists.infradead.org; Thu, 18 Feb 2021 15:44:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0F01E1042; Thu, 18 Feb 2021 07:44:26 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.48.237]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D35F33F73D; Thu, 18 Feb 2021 07:44:23 -0800 (PST) Date: Thu, 18 Feb 2021 15:44:20 +0000 From: Mark Rutland To: Will Deacon Subject: Re: [PATCH v2] arm64: spectre: Prevent lockdep splat on v4 mitigation enable path Message-ID: <20210218154420.GB91307@C02TD0UTHF1T.local> References: <20210218140346.5224-1-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210218140346.5224-1-will@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210218_104427_267507_DAADE7E9 X-CRM114-Status: GOOD ( 25.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Lorenzo Pieralisi , "Paul E . McKenney" , Saravana Kannan , Peter Zijlstra , Marc Zyngier , Boqun Feng , Sami Tolvanen , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 18, 2021 at 02:03:46PM +0000, Will Deacon wrote: > The Spectre-v4 workaround is re-configured when resuming from suspend, > as the firmware may have re-enabled the mitigation despite the user > previously asking for it to be disabled. > > Enabling or disabling the workaround can result in an undefined > instruction exception on CPUs which implement PSTATE.SSBS but only allow > it to be configured by adjusting the SPSR on exception return. We handle > this by installing an 'undef hook' which effectively emulates the access. > > Installing this hook requires us to take a couple of spinlocks both to > avoid corrupting the internal list of hooks but also to ensure that we > don't run into an unhandled exception. Unfortunately, when resuming from > suspend, we haven't yet called rcu_idle_exit() and so lockdep gets angry > about "suspicious RCU usage". In doing so, it tries to print a warning, > which leads it to get even more suspicious, this time about itself: > > | rcu_scheduler_active = 2, debug_locks = 1 > | RCU used illegally from extended quiescent state! > | 1 lock held by swapper/0: > | #0: (logbuf_lock){-.-.}-{2:2}, at: vprintk_emit+0x88/0x198 > | > | Call trace: > | dump_backtrace+0x0/0x1d8 > | show_stack+0x18/0x24 > | dump_stack+0xe0/0x17c > | lockdep_rcu_suspicious+0x11c/0x134 > | trace_lock_release+0xa0/0x160 > | lock_release+0x3c/0x290 > | _raw_spin_unlock+0x44/0x80 > | vprintk_emit+0xbc/0x198 > | vprintk_default+0x44/0x6c > | vprintk_func+0x1f4/0x1fc > | printk+0x54/0x7c > | lockdep_rcu_suspicious+0x30/0x134 > | trace_lock_acquire+0xa0/0x188 > | lock_acquire+0x50/0x2fc > | _raw_spin_lock+0x68/0x80 > | spectre_v4_enable_mitigation+0xa8/0x30c > | __cpu_suspend_exit+0xd4/0x1a8 > | cpu_suspend+0xa0/0x104 > | psci_cpu_suspend_enter+0x3c/0x5c > | psci_enter_idle_state+0x44/0x74 > | cpuidle_enter_state+0x148/0x2f8 > | cpuidle_enter+0x38/0x50 > | do_idle+0x1f0/0x2b4 > > Prevent these splats by running __cpu_suspend_exit() with RCU watching. > > Cc: Mark Rutland > Cc: Lorenzo Pieralisi > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Marc Zyngier > Cc: Saravana Kannan > Suggested-by: "Paul E . McKenney" > Reported-by: Sami Tolvanen > Fixes: c28762070ca6 ("arm64: Rewrite Spectre-v4 mitigation code") > Signed-off-by: Will Deacon FWIW: Acked-by: Mark Rutland I reckon we might want to restructure the SSBS emulation in future as a cleaner fix; the oddity here is that we transiently register the hook, where we could instead unconditionally register it at boot time and have the hook itself decide whether it should apply a fixup. When entering an exception from the idle task enter_from_kernel_mode() will handle the RCU entry, so the hook would be able to use that without issue. Thanks, Mark. > --- > > v2: Use RCU_NONIDLE() instead of eliding the spinlock > > arch/arm64/kernel/suspend.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c > index a67b37a7a47e..d7564891ffe1 100644 > --- a/arch/arm64/kernel/suspend.c > +++ b/arch/arm64/kernel/suspend.c > @@ -119,7 +119,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long)) > if (!ret) > ret = -EOPNOTSUPP; > } else { > - __cpu_suspend_exit(); > + RCU_NONIDLE(__cpu_suspend_exit()); > } > > unpause_graph_tracing(); > -- > 2.30.0.478.g8a0d178c01-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel