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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1B3CC54EE9 for ; Tue, 20 Sep 2022 06:02:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230323AbiITGCy (ORCPT ); Tue, 20 Sep 2022 02:02:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230320AbiITGCt (ORCPT ); Tue, 20 Sep 2022 02:02:49 -0400 X-Greylist: delayed 443 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 19 Sep 2022 23:02:44 PDT Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DA175C9CF; Mon, 19 Sep 2022 23:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id E4C2D205E3; Tue, 20 Sep 2022 07:54:44 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swpeMJd9catj; Tue, 20 Sep 2022 07:54:44 +0200 (CEST) Received: from mailout2.secunet.com (mailout2.secunet.com [62.96.220.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 6396520561; Tue, 20 Sep 2022 07:54:44 +0200 (CEST) Received: from cas-essen-01.secunet.de (unknown [10.53.40.201]) by mailout2.secunet.com (Postfix) with ESMTP id 52A6C80004A; Tue, 20 Sep 2022 07:54:44 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by cas-essen-01.secunet.de (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 20 Sep 2022 07:54:44 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 20 Sep 2022 07:54:43 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 75FF531829FB; Tue, 20 Sep 2022 07:54:43 +0200 (CEST) Date: Tue, 20 Sep 2022 07:54:43 +0200 From: Steffen Klassert To: Daniel Jordan CC: , , , , Subject: Re: [PATCH] padata: fix lockdep warning in padata serialization Message-ID: <20220920055443.GI2950045@gauss3.secunet.de> References: <20220919151248.smfo7nq6yoqzy2vo@oracle.com> <20220920003908.391835-1-eadavis@sina.com> <20220920014711.bvreurf4ex44w6oj@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20220920014711.bvreurf4ex44w6oj@oracle.com> X-ClientProxiedBy: cas-essen-01.secunet.de (10.53.40.201) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 19, 2022 at 09:47:11PM -0400, Daniel Jordan wrote: > On Tue, Sep 20, 2022 at 08:39:08AM +0800, eadavis@sina.com wrote: > > From: Edward Adam Davis > > > > On Mon, 19 Sep 2022 11:12:48 -0400, Daniel Jordan wrote: > > > Hi Edward, > > > > > > On Mon, Sep 19, 2022 at 09:05:55AM +0800, eadavis@sina.com wrote: > > > > From: Edward Adam Davis > > > > > > > > Parallelized object serialization uses spin_unlock for unlocking a spin lock > > > > that was previously locked with spin_lock. > > > > > > There's nothing unusual about that, though? > > > > > > > This caused the following lockdep warning about an inconsistent lock > > > > state: > > > > > > > > inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. > > > > > > Neither HARDIRQ-ON-W nor IN-HARDIRQ-W appear in the syzbot report, did > > > you mean SOFTIRQ-ON-W and IN-SOFTIRQ-W? > > Yes, I want say: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. > > > > > > > We must use spin_lock_irqsave, because it is possible to trigger tipc > > > > from an irq handler. > > > > > > A softirq handler, not a hardirq handler. I'd suggest using > > > spin_lock_bh() instead of _irqsave in your patch. > > I think _irqsave better than _bh, it can save the irq context, but _bh not, > > and in tipc call trace contain SOFTIRQ-ON-W and IN-SOFTIRQ-W. > > _irqsave saving the context is about handling nested hardirq disables. > It's not needed here since we don't need to care about disabling > hardirq. > > _bh is for disabling softirq, a different context from hardirq. We want > _bh here since the deadlock happens when a CPU takes the lock in both > task and softirq context. padata uses _bh lock variants because it can > be called in softirq context but not hardirq. Let's be consistent and > do it in this case too. padata_do_serial is called with BHs off, so using spin_lock_bh should not fix anything here. I guess the problem is that we call padata_find_next after we enabled the BHs in padata_reorder.