From nobody Fri Apr 3 09:43:26 2026 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75DEE375F99 for ; Wed, 1 Apr 2026 04:19:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775017182; cv=none; b=kGBCPZL3qXuUzWp2uiX4CUs/GlvuPjV5gbiQCc3E5QCiEkgz8yWcnBcatOZvvllTGRAu6BxRFa59ud/Xns/86Mv5mZj/7IFuM0o5TVrQA6/d8iI2zDka3TbJayz1pyn8DFyrWhoI9DaFdBqpThCGI6Cbod42iy2Dyi3GSOmU6Ww= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775017182; c=relaxed/simple; bh=bQF1B63XcSzzW4Me2ZXYMgmme68wMnnLs+ouzSS6L0o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Dogx83Aj/3N8O6TSp+my2j5DIp+iMrQRxmj8gD3B+9cMuqmV0MI1qdmE0DKBB/nkmWJ31xDRYUntf3AlG7HrbN7gybQBNKAB0OgoUc3hJt685Ttc1ChI/97J5NXUB+weIs7bqbVLc7KaG3GmH+1DurJYM3NwQRi3NX/30dOIsEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OVrHqiAx; arc=none smtp.client-ip=209.85.210.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OVrHqiAx" Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-7d86eb7c854so3418053a34.3 for ; Tue, 31 Mar 2026 21:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775017180; x=1775621980; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=DSD4qx/2JYM1VePcNlk14SPwVbO4qzamhYtHorOqJMs=; b=OVrHqiAxAkZKmdHA96j+FdaxWtp1x7oZ6BKNQTpBAyEKTYS137yxFTALfghB+kxEAH H+eeLuIatOurk2VcLSV++NiX29yc9wgXnyGUb/VH9w9MKn0D+MgcS9AvA1ns1o0yKKQH PP8ItPWMtnQpKJ+eMZhPorqzmgtEP7R9OVsR+ud7KlG+DvUNgSyt6UbzeAqRGA+CYwdf tRjskykQ5A8j/Q+SJHKiuCww9oc02alh7scPaAwZuJKJ48lerOkmMmvwFYxfkiVjOFg+ 67TQLAQ2w73XvGxThfc4s1JKSKhZkWed/n0JHi04G3YVLmeiY8Ckn/x/dRu3hjbuHz49 vX5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775017180; x=1775621980; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=DSD4qx/2JYM1VePcNlk14SPwVbO4qzamhYtHorOqJMs=; b=juZPecci6Bgem2+l54s0i9bv9n7LAzrS/luZ55yh8/3mw3n4boEHjMALYHLhKFAzEv mIL24GQPOcj+WBnhiliMzfJRq5HUv3CL7MJD3e8vATH1B3fIcWuNHcZOqieexN1yFhVz rsHZOoffy2xM/pZJUbWfl85QFA1ZAgmo+XLdD1PTtbqoHKuMXKu1Cw+m03ElmiSluc29 E7A2e79RlTA6Q5jwqaxoFk4nI/p3UbIEPytOi97IfRVlvCgCgOBbZwQPH7C/Za8o47ek rCDaGzstWZzOR0i0OkL/RmtL9lrCVId1qEQGkbcLtwM7VgoyIs8Zi5R2L24v2e49ptWZ +pMg== X-Forwarded-Encrypted: i=1; AJvYcCUJGXGth7+fWepgbFWg64kXM8ZSpWNdaNdWrUV2Abz4kaRUJezITsKD+fQBkm6iWfV96cSGUHmXh9krSMw=@vger.kernel.org X-Gm-Message-State: AOJu0YxYEwm+JMvtz2N6ebNowwHUbE3G/7JedDXaeBnxR74rvm61m5rw TLJoJWo9nEamDI2ESlaNDnVSNf2VKGlwxpGF0ANP0t6niERKEQuwioC8 X-Gm-Gg: ATEYQzwaCvSJEk7ckT8HdvHZeixFbb31mUSLa9xtfqvnlkQMDu196dfARmPNuW5yoAA SLeg88/pdhflOSiLYUytAWt046v/Qjtzspzxe+54B6kBd9c9X3osGVna9PbjsX9KSB49B9dLx5c XaeagxQwzhsaaBzXlwxnFx18e+j1KyPiJpWh1kI1UYSVkmYctS5dryxtKy4UM26XVmxZfTI/jDF 0+YP4c/yTMXMeDXHn6bieQ/Df1Hbk/grXw78gwm0UuuuvFsU1pOtA+oufupPTDblLMYN0w7Jl5b PDdzoADGQeGUjZLB7UCakhuAauiA3bPAfYAX41nejxQL89C4pXYJBhPAUScvXtTJdQ14qxYaM9B g6V+DSlMMrZlQorGfgCh7Kw3KTsA63LMOXQxdFEnBACit8QwvBpYlrMNT22pEgY7TYU5zZTV5/g uP/RYHSSVZGNeWp7FfhVAnl1HOxRO95NPhE5/PqfJYDBBk220uXhVXcGJXkLU= X-Received: by 2002:a05:6830:452a:b0:7d7:db95:eee9 with SMTP id 46e09a7af769-7db994cf1b0mr1337728a34.30.1775017180356; Tue, 31 Mar 2026 21:19:40 -0700 (PDT) Received: from localhost (static-23-234-115-121.cust.tzulo.com. [23.234.115.121]) by smtp.gmail.com with UTF8SMTPSA id 46e09a7af769-7da0a384631sm9647188a34.7.2026.03.31.21.19.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Mar 2026 21:19:39 -0700 (PDT) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Maxime Coquelin , Alexandre Torgue , "Russell King (Oracle)" , Maxime Chevallier , Ovidiu Panait , Vladimir Oltean , Baruch Siach , Serge Semin , Giuseppe Cavallaro , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sam Edwards , stable@vger.kernel.org Subject: [PATCH net v4 1/2] net: stmmac: Prevent NULL deref when RX memory exhausted Date: Tue, 31 Mar 2026 21:19:28 -0700 Message-ID: <20260401041929.12392-2-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260401041929.12392-1-CFSworks@gmail.com> References: <20260401041929.12392-1-CFSworks@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=3D0 for CPU, OWN=3D1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions." In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=3D0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=3D1). If it fails any allocation, it simply stops early (leaving OWN=3D0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=3D1, buffer valid) - `full` (OWN=3D0, buffer valid and populated) - `dirty` (OWN=3D0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by further tightening the clamp from `dma_rx_size - 1` to `dma_rx_size - stmmac_rx_dirty() - 1`, subtracting any remnant dirty entries and limiting the loop so that `cur_rx` cannot catch back up to `dirty_rx`. This carries no risk of arithmetic underflow: since the maximum possible return value of stmmac_rx_dirty() is `dma_rx_size - 1`, the worst the clamp can do is prevent the loop from running at all. Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D221010 Cc: stable@vger.kernel.org Signed-off-by: Sam Edwards --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/ne= t/ethernet/stmicro/stmmac/stmmac_main.c index 13d3cac056be..fc11f75f7dc0 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -5609,7 +5609,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int li= mit, u32 queue) =20 dma_dir =3D page_pool_get_dma_dir(rx_q->page_pool); bufsz =3D DIV_ROUND_UP(priv->dma_conf.dma_buf_sz, PAGE_SIZE) * PAGE_SIZE; - limit =3D min(priv->dma_conf.dma_rx_size - 1, (unsigned int)limit); + limit =3D min(priv->dma_conf.dma_rx_size - stmmac_rx_dirty(priv, queue) -= 1, + (unsigned int)limit); =20 if (netif_msg_rx_status(priv)) { void *rx_head; --=20 2.52.0 From nobody Fri Apr 3 09:43:26 2026 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E62636C9C2 for ; Wed, 1 Apr 2026 04:19:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775017187; cv=none; b=cKPlORJpv3v7g8p4HMJylBeNMxbtKIUrSEs+n4/FUNqivVdRSeKo6XaLsyE53Geet0nhkhRWNp1O9GAjbynxSyI/x+zUMtsq6DFe1sUtHF9Up3+49eMfsvbCA9WlPgmJM2b6IJkfpBiBXDDIatsszuYETyR+sbUO3d3Dpz5nbf8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775017187; c=relaxed/simple; bh=GAdIAHgb5u8TBTPtWedEhpVmApFhU9W97TdtUCLjE8k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y5ba6BOPlGnFTv+TqnZVo8cBs4G1P7kL+UR8lFoELChUEq5H/04WKxvediY/SQ0whnMhLvWbJeTJIZ2NEEjj8a5OTHSqPznGISFCqHNAJq7BK6KHCWyu3lT8LhUc8TgN77iIph8v4TMYNw5TZzCEfaC16abTNRAAROVPHPF1I6I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jgLk86pz; arc=none smtp.client-ip=209.85.210.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jgLk86pz" Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-7d74dbfe84cso4398998a34.1 for ; Tue, 31 Mar 2026 21:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775017185; x=1775621985; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=p8Gs/LCy7pdaKThZ7lAOXGPZaybDiCKVdDXO7zMbjMs=; b=jgLk86pzUrhwLsvuIoofPtJtdzC9jkp4q2yu3+b+aD6v9CY80WufZD792fupnei2r7 tqjNCBl5Ulp5cxpPneOUj1FYB3oOaItKxVBatGJsc6lInjVkADEvab5R85HjQAi81png WrMdFJb4FwdlxcaAoKGG7bJkcCCJKkJQGc/HaaiCC7UKViaaKSP3kXzTzXLnrZDOH7S7 zDMMNPo486tkY9NrGNmCCiee1Yrp/CPxo9KtA99sV3Q8SdR3tA2TYIJBYkcQrvIn3pPh 1JymKGhRzo6IZtdJxLtziS/2RD15DKuMmR+0T6NMWNY6p5DzV0ry4wGS4FLqM8sPl0P2 J5OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775017185; x=1775621985; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=p8Gs/LCy7pdaKThZ7lAOXGPZaybDiCKVdDXO7zMbjMs=; b=QmRYI+sJSYyLdwUwKe+Abg69eIsxOQzuuPH4TqHuleiCMeWbNgF4USbgje3i09BqMg 7xyy/MdtVNdDgEDjvsGas9ARwPG84/FaWoO+FwKWmVsOg0APKnpJ5CoKYqkT3EpbL3dT BOTjV72wgz59DOXmm2hwrc7c5fVZFbAbOWEeo1CeIVRctaegorMkz3cfuTymX3gpRPeI x4a6q924bUAO5cwM+HaA/k9D3O5mvD5CvH5mS/ME2i8/HSa1M6i0eAJoVXJfAYzee6jq aemYMr5lXoRvSyd3ur3nlPEGqxF9qv0B6HvMPtwZdeibXIFxH/mEgAF0S4LMii/t9DK9 LHkA== X-Forwarded-Encrypted: i=1; AJvYcCU+yQUN8EmcWx0ygKSk26fxsi/ncW+eA9msMTrdkSQeZovAFcurIlep87JlM6SsQUzqxzg7uRGeA0PFkiE=@vger.kernel.org X-Gm-Message-State: AOJu0YyDyOGTnvjTr2CuBWNF2A/trGJ0ChkX+X3mCFgJX5O7wLRuJR5+ xoMjCIIV3qV1bQFk/W1xvc3VlBgKT0YcWXOvI8mbaKsIriwA78Psxo0v X-Gm-Gg: ATEYQzw4pqTiTfCOH8ydqBtxDaQbIrQ/SK3lJVBtmGPe4RWCLN7ET2zINKI7yNIhURX gQFYnBfxsKeLAB8OuB62mTyfEP5cikFIl2LGMdJ/WBZi54Y3nkJgv8FPcP1mbfRTLmG5/AJVUjJ 9niA8vGmedBYG8RMEt1LcN7Fh3g/2T2zGlfAyNo93H8v6pbibZTADIQUxbv7w3hRp9oy6ldmDQ+ 6+SPtUfEJ5fkYg9e3JulMzoQmy5MOr9+VI+cjsW/+Sjc6iqm7NdnWI06EbuZ4AcNNP5Cs5JWK3N oHOYAcRmq/1rWdFcweCYx9m5FyVWb1MB3SrLLuW1EXJ3aKMkPWH8WEUb+izN2/AstZiwbkXwyFE Qo15u+aGi7X7f27KESVJyJ1g2x0XILFpFnEoo317P5KurfT6w8w8EtN8vjREzmvuwnMxS+imZAM IRRhCirosK9fNL6HAYEJRLMqMuG3YQgGGCoo4uroQRdrbAVT6dtjPqeLLKlR4= X-Received: by 2002:a05:6830:3709:b0:7c7:69c8:2d2 with SMTP id 46e09a7af769-7db9925b999mr1505891a34.13.1775017185265; Tue, 31 Mar 2026 21:19:45 -0700 (PDT) Received: from localhost (static-23-234-115-121.cust.tzulo.com. [23.234.115.121]) by smtp.gmail.com with UTF8SMTPSA id 46e09a7af769-7da0a7b5b41sm9925868a34.15.2026.03.31.21.19.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Mar 2026 21:19:44 -0700 (PDT) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Maxime Coquelin , Alexandre Torgue , "Russell King (Oracle)" , Maxime Chevallier , Ovidiu Panait , Vladimir Oltean , Baruch Siach , Serge Semin , Giuseppe Cavallaro , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Sam Edwards , stable@vger.kernel.org Subject: [PATCH net v4 2/2] net: stmmac: Prevent indefinite RX stall on buffer exhaustion Date: Tue, 31 Mar 2026 21:19:29 -0700 Message-ID: <20260401041929.12392-3-CFSworks@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260401041929.12392-1-CFSworks@gmail.com> References: <20260401041929.12392-1-CFSworks@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The stmmac driver handles interrupts in the usual NAPI way: an interrupt arrives, the NAPI instance is scheduled and interrupts are masked, and the actual work occurs in the NAPI polling function. Once no further work remains, interrupts are unmasked and the NAPI instance is put to sleep to await a future interrupt. In the receive case, the MAC only sends the interrupt when a DMA operation completes; thus the driver must make sure a usable RX DMA descriptor exists before expecting a future interrupt. The main receive loop in stmmac_rx() exits under one of 3 conditions: 1) It encounters a DMA descriptor with OWN=3D1, indicating that no further pending data exists. The MAC will use this descriptor for the next RX DMA operation, so the driver can expect a future interrupt. 2) It exhausts the NAPI budget. In this case, the driver doesn't know whether the MAC has any usable DMA descriptors. But when the driver consumes its full budget, that signals NAPI to keep polling, so the question is moot. 3) It runs out of (non-dirty) descriptors in the RX ring. In this case, the MAC will only have a usable descriptor if stmmac_rx_refill() succeeds (at least partially). Currently, stmmac_rx() lacks any check against scenario #3 and stmmac_rx_refill() failing: it will stop NAPI polling and unmask interrupts to await an interrupt that will never arrive, stalling the receive pipeline indefinitely. Also: even if not all descriptors are dirty, letting them accumulate risks dropping frames in the next incoming traffic burst, if large enough to exhaust the remaining valid ones. Fix both of these problems by checking stmmac_rx_dirty() before return: Use the same threshold as the zero-copy path (STMMAC_RX_FILL_BATCH) for an unacceptably high number of neglected dirties, and tell NAPI to keep polling (i.e. return budget) when that threshold is met. Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet cont= rollers.") Cc: stable@vger.kernel.org Signed-off-by: Sam Edwards --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/ne= t/ethernet/stmicro/stmmac/stmmac_main.c index fc11f75f7dc0..6822ca27cb0f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -5604,6 +5604,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int li= mit, u32 queue) unsigned int desc_size; struct sk_buff *skb =3D NULL; struct stmmac_xdp_buff ctx; + int budget =3D limit; int xdp_status =3D 0; int bufsz; =20 @@ -5870,6 +5871,14 @@ static int stmmac_rx(struct stmmac_priv *priv, int l= imit, u32 queue) priv->xstats.rx_dropped +=3D rx_dropped; priv->xstats.rx_errors +=3D rx_errors; =20 + /* stmmac_rx_refill() may fail, leaving some dirty entries behind. + * A few is OK, but if it gets out of hand, we risk dropping frames + * in the next traffic burst; in the worst case (100% dirty) we won't + * even receive any future "DMA completed" interrupts. + */ + if (unlikely(stmmac_rx_dirty(priv, queue) >=3D STMMAC_RX_FILL_BATCH)) + return budget; + return count; } =20 --=20 2.52.0