Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp25859928rwd; Mon, 3 Jul 2023 01:57:24 -0700 (PDT) X-Google-Smtp-Source: APBJJlGCKUsz1MdMQWcOAGOIXUwilq8xy+VFT5PAXPMfXyu8ZbzBEQBKed8b0JTt36v1C+CINOq8 X-Received: by 2002:a05:6870:cc8e:b0:19e:34f8:4d4f with SMTP id ot14-20020a056870cc8e00b0019e34f84d4fmr11742340oab.32.1688374644283; Mon, 03 Jul 2023 01:57:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688374644; cv=none; d=google.com; s=arc-20160816; b=P491osoBfmA+LdDQ1NaTfCAhCZ7O1BSZ8pBx4nj4HBcwGk5+/86tA8a5k/Wz4qzwnp 1LTtgEXoumu+ZKuTFlXuSo/lIXV8PR9Mj8XRWpyL4P49e5LGuhAGSphSkypOjq/hS4cC JMszJuTxuzJjTaXxxk1Xxw/MhUMyhBMsWB2vq0jPOIHy8ewRq79UidT868u4kHtr3Q5d EzlZwJOZwyKMigXJBdKdzSxDc9N6wwz/XQw0eoIdwoOtePcGoO4z0n0j7I4ms4ZMqNG3 zObIDnIi8twN3Q0rkVfn6tBNia74EJsWJBKtGYdBfeuvz37m2X2btgHqc0u9GJXqIOT+ q5AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature:dkim-filter; bh=wLvOYsL0xTLNog9Esl1IJpg/jgFjcy1xWtdfH3ZESbc=; fh=qKGHJM/OaNHTo96+1HG2BqACTjy4q9C0dbufp/+3Ef4=; b=BAq31cPL6rmiEfvoOrpxbed3siq8qGvVmMWbO4tujtZertetN35Eg/oxhRZdTdbolg we/vmZpDm2lgPQxgVE/ROcKXujm8LF+d/oY85TjR6sRVw/EfIORp5OW0BvhuN3TOzWsc fAjYTcmP7oPyRlWWmL7NIFWrkVqWLK6PPJLX/CmHy6OzHFwLGINpmqDzSYsm2RDgdPNu toP9NpWSRbpvfHn3tcYIVs7CSPX3p1OKpBd85x7bGdU/p2isEw3cBaJvgcioLnYQVweK zNUwAse2G/sfC91H0+3wu+kwt+XA9CUA2gkgZf30e3rCspWgUG0ShmCHfkDDtaJ6r7xO PsTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=qJlSF5nC; 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=linux.microsoft.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c28-20020a631c1c000000b0055759bb6883si17995605pgc.63.2023.07.03.01.57.10; Mon, 03 Jul 2023 01:57:24 -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=@linux.microsoft.com header.s=default header.b=qJlSF5nC; 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=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230263AbjGCIuH (ORCPT + 99 others); Mon, 3 Jul 2023 04:50:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229888AbjGCIuC (ORCPT ); Mon, 3 Jul 2023 04:50:02 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 949DB10C7; Mon, 3 Jul 2023 01:49:41 -0700 (PDT) Received: by linux.microsoft.com (Postfix, from userid 1099) id 7CEF720AECAD; Mon, 3 Jul 2023 01:49:34 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7CEF720AECAD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1688374174; bh=wLvOYsL0xTLNog9Esl1IJpg/jgFjcy1xWtdfH3ZESbc=; h=From:To:Cc:Subject:Date:From; b=qJlSF5nCdYP0m5NBCth77epMbBD9PUok8pnsnPduqP6HFaKbBSJC0KSBX05iB8Sb0 xxdrowkaHthO5XOKYwfC4/e6I2tLXTWZE+qRanRUbKzGXXCrGW02hIh6e8wh2ahiCL MmC/+4wcXVueI45GKAIoAjb2/nCQW2dMTVqawiEU= From: souradeep chakrabarti To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, longli@microsoft.com, sharmaajay@microsoft.com, leon@kernel.org, cai.huoqing@linux.dev, ssengar@linux.microsoft.com, vkuznets@redhat.com, tglx@linutronix.de, linux-hyperv@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org Cc: stable@vger.kernel.org, schakrabarti@microsoft.com, Souradeep Chakrabarti Subject: [PATCH V4 net] net: mana: Fix MANA VF unload when host is unresponsive Date: Mon, 3 Jul 2023 01:49:31 -0700 Message-Id: <1688374171-10534-1-git-send-email-schakrabarti@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham 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 From: Souradeep Chakrabarti When unloading the MANA driver, mana_dealloc_queues() waits for the MANA hardware to complete any inflight packets and set the pending send count to zero. But if the hardware has failed, mana_dealloc_queues() could wait forever. Fix this by adding a timeout to the wait. Set the timeout to 120 seconds, which is a somewhat arbitrary value that is more than long enough for functional hardware to complete any sends. Signed-off-by: Souradeep Chakrabarti --- V3 -> V4: * Fixed the commit message to describe the context. * Removed the vf_unload_timeout, as it is not required. --- drivers/net/ethernet/microsoft/mana/mana_en.c | 26 ++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index a499e460594b..d26f1da70411 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -2346,7 +2346,10 @@ static int mana_dealloc_queues(struct net_device *ndev) { struct mana_port_context *apc = netdev_priv(ndev); struct gdma_dev *gd = apc->ac->gdma_dev; + unsigned long timeout; struct mana_txq *txq; + struct sk_buff *skb; + struct mana_cq *cq; int i, err; if (apc->port_is_up) @@ -2363,15 +2366,32 @@ static int mana_dealloc_queues(struct net_device *ndev) * to false, but it doesn't matter since mana_start_xmit() drops any * new packets due to apc->port_is_up being false. * - * Drain all the in-flight TX packets + * Drain all the in-flight TX packets. + * A timeout of 120 seconds for all the queues is used. + * This will break the while loop when h/w is not responding. + * This value of 120 has been decided here considering max + * number of queues. */ + + timeout = jiffies + 120 * HZ; for (i = 0; i < apc->num_queues; i++) { txq = &apc->tx_qp[i].txq; - - while (atomic_read(&txq->pending_sends) > 0) + while (atomic_read(&txq->pending_sends) > 0 && + time_before(jiffies, timeout)) { usleep_range(1000, 2000); + } } + for (i = 0; i < apc->num_queues; i++) { + txq = &apc->tx_qp[i].txq; + cq = &apc->tx_qp[i].tx_cq; + while (atomic_read(&txq->pending_sends)) { + skb = skb_dequeue(&txq->pending_skbs); + mana_unmap_skb(skb, apc); + napi_consume_skb(skb, cq->budget); + atomic_sub(1, &txq->pending_sends); + } + } /* We're 100% sure the queues can no longer be woken up, because * we're sure now mana_poll_tx_cq() can't be running. */ -- 2.34.1