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 749B6C4332F for ; Tue, 18 Oct 2022 15:59:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229925AbiJRP71 (ORCPT ); Tue, 18 Oct 2022 11:59:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231473AbiJRP7Q (ORCPT ); Tue, 18 Oct 2022 11:59:16 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BCA3C97F7 for ; Tue, 18 Oct 2022 08:59:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9F352B81E8F for ; Tue, 18 Oct 2022 15:59:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F067AC433D6; Tue, 18 Oct 2022 15:59:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666108748; bh=rjrUbHLaZN5f2R/gvig9BxR9nepn3CO42tejBn7K1CM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KgDJLeRHPG1KMYft4H/kUrIAYigOE292+wPuIrW6ey7wE2XK+GqryJGozQ6N6JDHN 1d5KN3B0KLcYvdnHZOjFzdvBPJ1j5b/Wjkgi+Ysunub0cR0eM1uSX3sqqfdGY2iNr2 IsL7gvFJe7uE/QwVVW7T7R7q8WAx07MKwQ4EmRunkuwDJoTQG0rE/1yOvftcqlAUFi mFQjcNQ1tYwN3mvKgKJS5BPrBBe7mgj1LbhlOLQrcBcOUWA3LQGk3DtO1iS8ID8GDE GG2xj6erYR/YG1GTtewiHlNzvWhMlpsSMwTBN60504GNbCi3ustyHNZV1KTVVtmuSS 2v4THYliNSxOA== Date: Tue, 18 Oct 2022 08:59:06 -0700 From: Jakub Kicinski To: =?UTF-8?B?w43DsWlnbw==?= Huguet Cc: Andrew Lunn , irusskikh@marvell.com, dbogdanov@marvell.com, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org, Li Liang Subject: Re: [PATCH net] atlantic: fix deadlock at aq_nic_stop Message-ID: <20221018085906.76f70073@kernel.org> In-Reply-To: References: <20221014103443.138574-1-ihuguet@redhat.com> <20221017194404.0f841a52@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 18 Oct 2022 08:15:38 +0200 =C3=8D=C3=B1igo Huguet wrote: > Interesting solution, I didn't even think of something like this. > However, despite not being 100% sure, I think that it's not valid in > this case because the work's task communicates with fw and uses > resources that are deinitialized at ndo_stop. That's why I think that > just holding a reference to the device is not enough. You hold a reference to the netdev just to be able to take rtnl_lock() and check if it's still running. If it is UP you're protected from it going down due to rtnl_lock you took. If it's DOWN, as you say, it's not safe to access all the bits so just unlock and return. But because you're holding the reference it's safe to cancel_work() without _sync on down, because the work itself will check if it should have been canceled. Dunno if that's a good explanation :S