From patchwork Mon Jun 26 11:34:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Kauer X-Patchwork-Id: 112891 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp7425776vqr; Mon, 26 Jun 2023 05:00:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5aSrBjcHozGrxB8bpRcXnfSRFkwNkpXLSmKW6dZt5wLgRhWeLpUJhXbN3jOqiPovp4Q3N8 X-Received: by 2002:a17:902:7b89:b0:1b7:e671:8b15 with SMTP id w9-20020a1709027b8900b001b7e6718b15mr2550395pll.22.1687780822073; Mon, 26 Jun 2023 05:00:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687780822; cv=none; d=google.com; s=arc-20160816; b=ntJMxrEBtSp0O5XS1RueS2SiNL3vOM1abZaJLHro+fIq+sqbPB912tsOnuw/vvFr6J 8FB7D8tgL5wEcoD98o6xJyv6qxatxFh4P9fId3YKtO32Xn7dxzmb5Ha4oNdUyb7jkLoq JFqZ2VVD2R+NMkcKKe5sYoknL4+4xluWaNSufGah6SmxbcxcOlm0n8crF675ntYK6+a8 d55mhgpUOS47lPvelBmselavaXu5gLlZ76gKuxhb9ETsFMOI7Ew/dMNNV5PiQo/erjWK LvHuBRHdr9DEBD3XHGHapm/BPyBm8RBaAq1tWcXeT1Nb7uzRgy7fA/RId0biBN1gvLdH Y8lw== 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 :message-id:date:subject:cc:to:dkim-signature:dkim-signature:from; bh=/lr3yIKV5fAO6P1uxCDLThWi2+XGH24iMml/rrOTEjA=; fh=01qHzDOdGfhjNUvy/3AK2w48jGNg+Otg0qK4oi+CQvs=; b=xZZ3bA6rDJn2MrbYXLQBAw4Q5Zhld1WxIYjhVHYjj9T8KFhADVPn/6idWZ4V3XHk5O fis66D0v+iiI+CRVw4O5zk4FDKvSOlxEPAqJJmYzM3KALWxhg4JEA2XUxmsy8LSl0xpb 5I+uYzf61DgcbIaj44UtTN/k0VkUeg96cbVf74LXvZ/scMdnwy83Ni4ZJc068xaIF+zg CUFXKwr2i/c+f6qUf+IfGxbFFWAsB8CLAjfFwitI6NbeGPFw128J54TfFlKUwQEKMqsd yme0ZTXIRVQNT8Ahv7mu4iqiKf6Zg1sDsfS+cF5dYCIPrs0YDXZuIUl7+6K2+5j1U+yd 69yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=yNE5hLWI; dkim=neutral (no key) header.i=@linutronix.de; 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=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d19-20020a170902b71300b001b66f00d40csi4692877pls.351.2023.06.26.05.00.07; Mon, 26 Jun 2023 05:00:21 -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=@linutronix.de header.s=2020 header.b=yNE5hLWI; dkim=neutral (no key) header.i=@linutronix.de; 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=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230358AbjFZLgO (ORCPT + 99 others); Mon, 26 Jun 2023 07:36:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230224AbjFZLfx (ORCPT ); Mon, 26 Jun 2023 07:35:53 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DF85269A; Mon, 26 Jun 2023 04:35:04 -0700 (PDT) From: Florian Kauer DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1687779301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/lr3yIKV5fAO6P1uxCDLThWi2+XGH24iMml/rrOTEjA=; b=yNE5hLWIZsx3KBeSYvm5WTS3Htutyh2DeyItMLEpbDP8q0GrZO6R/WXrcvoUXL9p6hdAlo e6R4pmjJWaKjvL233HS8eEWVYrvk6fmKPZhJzjp9LObXnYrGGK3s3atheGkIKx1QXXgwDa 1ZPMoalgmCTyUbQVqI2HN/6rGaIcMICx3FpzyTh4Vx123APY+CMkUG97NuMi8OsLhsobcw 161GViXKfgGvW+Iblux2JXkKePzba9WqwpKN8X6oIFc2qD2c42kRCHcvaGd/OBefDVPHZI AwSJjMtcqA+jWWMgdzlK/l7HJbWWPe2YffcJGzUHPfOlWCKalh+y6E1cDwLIgg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1687779301; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=/lr3yIKV5fAO6P1uxCDLThWi2+XGH24iMml/rrOTEjA=; b=RMzzaAPVzidc8n9yuCdJkO+h2kAprWob2yWDd7fLF8EQ4IXLkeWKO+Z8LqeRHSGyi+rXN6 iAGGNEzgUNKHJEDA== To: Jesse Brandeburg , Tony Nguyen , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vedang Patel , Maciej Fijalkowski , Jithu Joseph , Andre Guedes Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kurt@linutronix.de, florian.kauer@linutronix.de Subject: [PATCH net] igc: Prevent garbled TX queue with XDP ZEROCOPY Date: Mon, 26 Jun 2023 13:34:29 +0200 Message-Id: <20230626113429.24519-1-florian.kauer@linutronix.de> MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769766462308401016?= X-GMAIL-MSGID: =?utf-8?q?1769766462308401016?= When the TX queue is used both by an application using AF_XDP with ZEROCOPY as well as a second non-XDP application generating high traffic, the queue pointers can get in an invalid state. Most importantly, it can happen that next_to_use points to an entry where next_to_watch != 0. However, the implementation assumes at several places that this is never the case, so if it does hold, bad things happen. In particular, within the loop inside of igc_clean_tx_irq(), next_to_clean can overtake next_to_use. Finally, this prevents any further transmission via this queue and it never gets unblocked or signaled. Secondly, if the queue is in this garbled state, the inner loop of igc_clean_tx_ring() will never terminate, completely hogging a CPU core. The reason is that igc_xdp_xmit_zc() reads next_to_use before aquiring the lock, and writing it back (potentially unmodified) later. If it got modified before locking, the outdated next_to_use is written pointing to an entry that was already used elsewhere (and thus next_to_watch got written). Fixes: 9acf59a752d4 ("igc: Enable TX via AF_XDP zero-copy") Signed-off-by: Florian Kauer Reviewed-by: Kurt Kanzenbach Tested-by: Kurt Kanzenbach --- drivers/net/ethernet/intel/igc/igc_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c index eb4f0e562f60..2eff073ee771 100644 --- a/drivers/net/ethernet/intel/igc/igc_main.c +++ b/drivers/net/ethernet/intel/igc/igc_main.c @@ -2791,7 +2791,7 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring) struct netdev_queue *nq = txring_txq(ring); union igc_adv_tx_desc *tx_desc = NULL; int cpu = smp_processor_id(); - u16 ntu = ring->next_to_use; + u16 ntu; struct xdp_desc xdp_desc; u16 budget; @@ -2800,6 +2800,7 @@ static void igc_xdp_xmit_zc(struct igc_ring *ring) __netif_tx_lock(nq, cpu); + ntu = ring->next_to_use; budget = igc_desc_unused(ring); while (xsk_tx_peek_desc(pool, &xdp_desc) && budget--) {