Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp3342673rwe; Mon, 29 Aug 2022 09:49:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR4MBTD7CmxBu/m2nifoxEb+lFP07kJBvzb+4wDV7DKHGA0oxwOroEIQd76ihw/zC79Apjc7 X-Received: by 2002:a05:6a00:2293:b0:538:47a7:6fa with SMTP id f19-20020a056a00229300b0053847a706famr4802505pfe.17.1661791748884; Mon, 29 Aug 2022 09:49:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661791748; cv=none; d=google.com; s=arc-20160816; b=xvJGsvBjLIfFYKGumrRbJudXui2gMDC6Wi60GQ8mIiAqM1wlupxr9EexOwBCJCiRut fImn2223Kfat3Q9erKA8Fbo7vtEzI+6MJ/ehMn2QqlWi0fhfFp+JYAMk0e0/4un+22t2 8jGCMuQSJEgjmHDjczpkhBglfxJJd/nQYHmc5/zX7Y40SFfx1ahIPijmiyc2ZErMEBlB A7j8fBN0Vns0JtSy2o5KAsDXiH53uHGDgmFfVBCGkjHjl5KDloEYTMeU9vIgjagBJKmY iquGE9B7xy9vRoyGHThZWYZVUTXSbTedhRbfRg6cT2Zq1XSWWL23U/jj9wSHbV/pjbtN +ZSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=KwCsREdznoy00YBbgW4AErRvUc6/IZZWjwk9hxW6AGA=; b=h2IC16w/ugbwdS8bBeIW0rCER+kh1KI2FR3Bk+QDhvzHf5TEJBXAv+yKxOQXobrv8y gGIXolZ0Iw2RGiq1xJ0E50rjisanZjuRjEnKikfSoLzTJ0Dcuy9FD6ArcCg2aVUi790V xJRD6v240wXssSh+7ALDYrIlttIfkIVtt4ZsUbp7BW/+AFXI3qtdPGJm3UcdUxNkj9fQ JXLeB6bf1STOJk05IlXh2lSTNiaESyRj57HSOGX9C6qPW63ZQhlGvN7sP/spedwcXUz/ PXpLPY7yiBEbUs/R+hEWYCWywlxucsFoO0dZbm2EsauRAZaVKVFWPPUe3npTFbV3XJfr iwkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="D/FS6bps"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a65-20020a639044000000b0042b8d806ec7si4734132pge.694.2022.08.29.09.48.57; Mon, 29 Aug 2022 09:49:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="D/FS6bps"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229737AbiH2Q3m (ORCPT + 99 others); Mon, 29 Aug 2022 12:29:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229708AbiH2Q3j (ORCPT ); Mon, 29 Aug 2022 12:29:39 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4ADFB99B5F for ; Mon, 29 Aug 2022 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661790577; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KwCsREdznoy00YBbgW4AErRvUc6/IZZWjwk9hxW6AGA=; b=D/FS6bpsvzNNXbb9JJmeqydat6upgDOHPda6LlJMRqEzXg2HiQky7ViOj0m4/4xbo1YmmU 6FkGRFHD+9hcdGWdUrIXCEEbPtH+nteB1R1GwiQcH3je2D7dKxY0hIOm3ghscozCGyzSCv CUquhQZJii9OgagYD3gKguc609lEaLA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-578-l71OkxkgNkaAprZ_YuryrQ-1; Mon, 29 Aug 2022 12:29:33 -0400 X-MC-Unique: l71OkxkgNkaAprZ_YuryrQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EB84A811E81; Mon, 29 Aug 2022 16:29:32 +0000 (UTC) Received: from p1.luc.cera.cz (unknown [10.40.195.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id D6B89C15BB3; Mon, 29 Aug 2022 16:29:30 +0000 (UTC) Date: Mon, 29 Aug 2022 18:29:29 +0200 From: Ivan Vecera To: "Laba, SlawomirX" Cc: "netdev@vger.kernel.org" , "Keller, Jacob E" , "Piotrowski, Patryk" , Vitaly Grinberg , "Brandeburg, Jesse" , "Nguyen, Anthony L" , "David S. Miller" , "Eric Dumazet" , Jakub Kicinski , Paolo Abeni , Jeff Kirsher , "moderated list:INTEL ETHERNET DRIVERS" , open list Subject: Re: [PATCH net] iavf: Detach device during reset task Message-ID: <20220829182929.2822fafc@p1.luc.cera.cz> In-Reply-To: References: <20220818165558.997984-1-ivecera@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 22 Aug 2022 17:42:44 +0000 "Laba, SlawomirX" wrote: > > -----Original Message----- > > From: ivecera > > Sent: Thursday, August 18, 2022 6:56 PM > > To: netdev@vger.kernel.org > > Cc: Keller, Jacob E ; Piotrowski, Patryk > > ; Vitaly Grinberg ; > > Brandeburg, Jesse ; Nguyen, Anthony L > > ; David S. Miller ; Eric > > Dumazet ; Jakub Kicinski ; Paolo > > Abeni ; Jeff Kirsher ; > > moderated list:INTEL ETHERNET DRIVERS ; > > open list > > Subject: [PATCH net] iavf: Detach device during reset task > > > > iavf_reset_task() takes crit_lock at the beginning and holds it during whole call. > > The function subsequently calls > > iavf_init_interrupt_scheme() that grabs RTNL. Problem occurs when userspace > > initiates during the reset task any ndo callback that runs under RTNL like > > iavf_open() because some of that functions tries to take crit_lock. This leads to > > classic A-B B-A deadlock scenario. > > > > To resolve this situation the device should be detached in > > iavf_reset_task() prior taking crit_lock to avoid subsequent ndos running under > > RTNL and reattach the device at the end. > > > > Fixes: 62fe2a865e6d ("i40evf: add missing rtnl_lock() around > > i40evf_set_interrupt_capability") > > Cc: Jacob Keller > > Cc: Patryk Piotrowski > > Tested-by: Vitaly Grinberg > > Signed-off-by: Ivan Vecera > > --- > > drivers/net/ethernet/intel/iavf/iavf_main.c | 22 +++++++++++++++------ > > 1 file changed, 16 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c > > b/drivers/net/ethernet/intel/iavf/iavf_main.c > > index f39440ad5c50..ee8f911b57ea 100644 > > --- a/drivers/net/ethernet/intel/iavf/iavf_main.c > > +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c > > @@ -2877,6 +2877,13 @@ static void iavf_reset_task(struct work_struct > > *work) > > int i = 0, err; > > bool running; > > > > + /* > > + * Detach interface to avoid subsequent NDO callbacks > > + */ > > nit: > The comment should start this way: /* Detach ... Will fix. > > + rtnl_lock(); > > + netif_device_detach(netdev); > > + rtnl_unlock(); > > + > > /* When device is being removed it doesn't make sense to run the reset > > * task, just return in such a case. > > */ > > @@ -2884,7 +2891,7 @@ static void iavf_reset_task(struct work_struct *work) > > if (adapter->state != __IAVF_REMOVE) > > queue_work(iavf_wq, &adapter->reset_task); > > > > - return; > > + goto reset_finish; > > Correct me if I'm wrong. > In case when you fail to grab a crit_lock you'd jump to the reset_finish label and unlock the locks you didn't lock. You're right.. I tried to dedup mutex unlocks after testing and missed this path. Will fix by v2. Thanks, I. > > } > > > > while (!mutex_trylock(&adapter->client_lock)) > > @@ -2954,7 +2961,6 @@ static void iavf_reset_task(struct work_struct *work) > > > > if (running) { > > netif_carrier_off(netdev); > > - netif_tx_stop_all_queues(netdev); > > adapter->link_up = false; > > iavf_napi_disable_all(adapter); > > } > > @@ -3081,10 +3087,8 @@ static void iavf_reset_task(struct work_struct > > *work) > > > > adapter->flags &= ~IAVF_FLAG_REINIT_ITR_NEEDED; > > > > - mutex_unlock(&adapter->client_lock); > > - mutex_unlock(&adapter->crit_lock); > > + goto reset_finish; > > > > - return; > > reset_err: > > if (running) { > > set_bit(__IAVF_VSI_DOWN, adapter->vsi.state); @@ -3092,9 > > +3096,15 @@ static void iavf_reset_task(struct work_struct *work) > > } > > iavf_disable_vf(adapter); > > > > + dev_err(&adapter->pdev->dev, "failed to allocate resources during > > +reinit\n"); > > + > > +reset_finish: > > mutex_unlock(&adapter->client_lock); > > mutex_unlock(&adapter->crit_lock); > > - dev_err(&adapter->pdev->dev, "failed to allocate resources during > > reinit\n"); > > + > > + rtnl_lock(); > > + netif_device_attach(netdev); > > + rtnl_unlock(); > > } > > > > /** > > -- > > 2.35.1 >