Thread (15 messages) flat view 15 messages, 2 authors, 2h ago

Re: [PATCH net-next v10 2/7] r8169: refactor RX path to prepare for multi-queue

From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-08-10 21:26:27
Also in: lkml

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
r8169: refactor RX path to prepare for multi-queue

This patch refactors the RX path by introducing a per-queue array
struct rtl8169_rx_ring, allocating the netdev with devm_alloc_etherdev_mqs(),
and updating related initialization and cleanup routines.
quoted hunk ↗ jump to hunk
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 8f3a5c50299ff..924df06398287 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -5873,9 +5995,15 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (rc)
 		return rc;
 
+	tp->rx_ring = kcalloc(tp->num_rx_rings, sizeof(struct rtl8169_rx_ring), GFP_KERNEL);
+	if (!tp->rx_ring)
+		return -ENOMEM;
+
[Severity: Medium]
Does this code leak the rx_ring array on driver removal?

tp->rx_ring is explicitly allocated with kcalloc() here, but it appears there
is no corresponding kfree(tp->rx_ring) in rtl_remove_one(). Since
devm_kcalloc() isn't used, shouldn't tp->rx_ring be freed when the device is
unbound?
 	tp->rtl8169_napi = kcalloc(tp->irq_nvecs, sizeof(struct napi_struct), GFP_KERNEL);
-	if (!tp->rtl8169_napi)
+	if (!tp->rtl8169_napi) {
+		kfree(tp->rx_ring);
 		return -ENOMEM;
+	}
-- 
pw-bot: cr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help