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 8C1C5C433F5 for ; Wed, 2 Mar 2022 15:31:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243478AbiCBPc0 (ORCPT ); Wed, 2 Mar 2022 10:32:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243474AbiCBPcZ (ORCPT ); Wed, 2 Mar 2022 10:32:25 -0500 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C53E27CDE for ; Wed, 2 Mar 2022 07:31:42 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E902F5C0070; Wed, 2 Mar 2022 10:31:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 02 Mar 2022 10:31:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=P0UyEhJ4bWlfeh/CE NyMsA94qtM/zUSyHBvGgQ8gS70=; b=LBovM/unksIfyIvdREn554y7zbNwoRmrp tGWGnSjMewTOLV3CHXWL68VWDXvJHlF40dke9YMmF7I0dIJFg+tXhGYuX0ysOwx2 /SGMh/SeUXieJi77fNMvZkWepQ+EumqJUNukQSLieZC/HtxWB+pcd3WlFNh9Aer/ 3p+eeABsFLRDsyCgYx4KQtvZgeBaXwhJqJHKNv15syi26Sipm06QBV4D6svBmSNz uQ9pVws8PQVYS/fMheFuuepSyY1wPtn8qrARgGLlvNAe8x3tb/T9KjkYhH1nf6fs 0ZxcJs7G3m7R6F6z8TJSEh546mqcRyXLbygjRjfgQ/oJvX/xZlfDw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddtgedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedtffekkeefudffveegueejffejhfetgfeuuefgvedtieehudeuueekhfduheel teenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiug hoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 2 Mar 2022 10:31:39 -0500 (EST) Date: Wed, 2 Mar 2022 17:31:36 +0200 From: Ido Schimmel To: Vladimir Oltean Cc: "netdev@vger.kernel.org" , "David S. Miller" , Jakub Kicinski , John Fastabend , Petr Machata Subject: Re: [PATCH net] net: dcb: flush lingering app table entries for unregistered devices Message-ID: References: <20220224160154.160783-1-vladimir.oltean@nxp.com> <20220301163632.pcag3zgluewlwnh3@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220301163632.pcag3zgluewlwnh3@skbuf> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Mar 01, 2022 at 04:36:32PM +0000, Vladimir Oltean wrote: > On Tue, Mar 01, 2022 at 06:23:16PM +0200, Ido Schimmel wrote: > > On Thu, Feb 24, 2022 at 06:01:54PM +0200, Vladimir Oltean wrote: > > > +static void dcbnl_flush_dev(struct net_device *dev) > > > +{ > > > + struct dcb_app_type *itr, *tmp; > > > + > > > + spin_lock(&dcb_lock); > > > > Should this be spin_lock_bh()? According to commit 52cff74eef5d ("dcbnl > > : Disable software interrupts before taking dcb_lock") this lock can be > > acquired from softIRQ. > > Could be. I didn't notice the explanation and I was even wondering in > which circumstance would it be needed to disable softirqs... > Now that I see the explanation I think the dcb_rpl -> cxgb4_dcb_handle_fw_update > -> dcb_ieee_setapp call path is problematic, when a different > DCB-enabled interface unregisters concurrently with a firmware event. Yep. Can you please send a fix so that it gets into Jakub's PR tomorrow?