Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp16013749rwd; Mon, 26 Jun 2023 04:45:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5LnC8JS8g3E2HXGGTLopgdXqW/5aJyAQESLa4PKfl+UKNufgTnureuhNr7qjWgkWt/7iTT X-Received: by 2002:a17:907:2d2b:b0:988:d6ca:ea72 with SMTP id gs43-20020a1709072d2b00b00988d6caea72mr18899246ejc.71.1687779903751; Mon, 26 Jun 2023 04:45:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687779903; cv=none; d=google.com; s=arc-20160816; b=AKBEVZqDB19LFHO8xDo8Yvin/WssgJneLuiHoF6BVxfEkLwapEVIIGy36qKQ3Kjdeg kHRzBJE33OeLhiP16vkyBg46LZAo+Q3uDtugKWDOqgLIeTNsIXyNdbKToYi02SczVFg7 cuX8HeXOloEkpOri31QabaUSQenrfiQ9+W7x++yNoiIqxZGkHVgz/bu9dJthPHM03maV VPp9JUia3HUk9gQB7dOfBUKQyQ/saIUBS6S45U5yW9xBo9HfEVdi8z0jG1/D8Lp9NL6f 0clOmOl2bOyqQKw1FvPa/bilWysM9yfI4RwmwZCJ9DC4kimztdLtTm48Eje7KbgrrN7s KmBQ== 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 header.s=2020e header.b=RMzzaAPV; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lc6-20020a170906f90600b00987ec4bedf0si2800950ejb.966.2023.06.26.04.44.38; Mon, 26 Jun 2023 04:45:03 -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 header.s=2020e header.b=RMzzaAPV; 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 S230249AbjFZLgN (ORCPT + 99 others); Mon, 26 Jun 2023 07:36:13 -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 Content-Transfer-Encoding: 8bit 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 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--) { -- 2.39.2