* [PATCH iwl-next v1] ixgbe: Implement PCI reset handler
From: Sergey Temerkhanov @ 2026-06-17 8:43 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev
Implement PCI device reset handler to allow the network device to
get re-initialized and function after a PCI-level reset.
Signed-off-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 72 +++++++++++++++++++
2 files changed, 73 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 594ccb28da20..c4b0c5bb89c6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -912,6 +912,7 @@ enum ixgbe_state_t {
__IXGBE_PTP_TX_IN_PROGRESS,
__IXGBE_RESET_REQUESTED,
__IXGBE_PHY_INIT_COMPLETE,
+ __IXGBE_PCIE_RESET_IN_PROGRESS,
};
struct ixgbe_cb {
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ac274c73d61..a61ee5fff7be 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -12352,6 +12352,76 @@ static pci_ers_result_t ixgbe_io_slot_reset(struct pci_dev *pdev)
return result;
}
+#define IXGBE_PCIE_RESET_RETRIES 1000
+
+/**
+ * ixgbe_reset_prep - called before the pci bus is reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Prepare the card for a reset, preventing the service task from running.
+ */
+static void ixgbe_reset_prep(struct pci_dev *pdev)
+{
+ struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
+ unsigned int timeout = IXGBE_PCIE_RESET_RETRIES;
+
+ if (!adapter)
+ return;
+
+ /* Prevent the service task from being requeued in the timer callback
+ * while we're resetting.
+ */
+ if (test_bit(__IXGBE_SERVICE_INITED, &adapter->state)) {
+ timer_delete_sync(&adapter->service_timer);
+ /* Prevent the service task from running while we're resetting. */
+ cancel_work_sync(&adapter->service_task);
+ }
+
+ pci_clear_master(pdev);
+
+ while (test_and_set_bit(__IXGBE_RESETTING, &adapter->state) && --timeout)
+ usleep_range(1000, 2000);
+
+ if (!timeout) {
+ e_err(drv, "Timed out waiting for __IXGBE_RESETTING to be released. Reset is needed\n");
+ pci_set_master(pdev);
+ return;
+ }
+
+ set_bit(__IXGBE_PCIE_RESET_IN_PROGRESS, &adapter->state);
+ smp_mb__after_atomic();
+}
+
+/**
+ * ixgbe_reset_done - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Allow the service task to run and schedule re-initialization.
+ */
+static void ixgbe_reset_done(struct pci_dev *pdev)
+{
+ struct ixgbe_adapter *adapter = pci_get_drvdata(pdev);
+
+ smp_mb__before_atomic();
+ if (!test_and_clear_bit(__IXGBE_PCIE_RESET_IN_PROGRESS, &adapter->state)) {
+ e_err(drv, "Reset done called without PCIe reset in progress\n");
+ return;
+ }
+
+ /* Allow the service task to run */
+ if (!test_bit(__IXGBE_REMOVING, &adapter->state)) {
+ clear_bit(__IXGBE_RESETTING, &adapter->state);
+ smp_mb__after_atomic();
+ }
+
+ /* Schedule re-initialization */
+ if (!test_bit(__IXGBE_DOWN, &adapter->state)) {
+ set_bit(__IXGBE_RESET_REQUESTED, &adapter->state);
+ if (test_bit(__IXGBE_SERVICE_INITED, &adapter->state))
+ mod_timer(&adapter->service_timer, jiffies + 1);
+ }
+}
+
/**
* ixgbe_io_resume - called when traffic can start flowing again.
* @pdev: Pointer to PCI device
@@ -12384,6 +12454,8 @@ static const struct pci_error_handlers ixgbe_err_handler = {
.error_detected = ixgbe_io_error_detected,
.slot_reset = ixgbe_io_slot_reset,
.resume = ixgbe_io_resume,
+ .reset_prepare = ixgbe_reset_prep,
+ .reset_done = ixgbe_reset_done,
};
static DEFINE_SIMPLE_DEV_PM_OPS(ixgbe_pm_ops, ixgbe_suspend, ixgbe_resume);
base-commit: c50bfa9768ff3a5163746c6362a8a910a0b4dca0
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] Networking for 7.2
From: pr-tracker-bot @ 2026-06-17 8:41 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: torvalds, kuba, davem, netdev, linux-kernel, pabeni
In-Reply-To: <20260617000705.931602-1-kuba@kernel.org>
The pull request you sent on Tue, 16 Jun 2026 17:07:05 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git tags/net-next-7.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b85966adbf5de0668a815c6e3527f87e0c387fb4
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v18 net-next 01/11] net/nebula-matrix: add minimum nbl build framework
From: Uwe Kleine-König @ 2026-06-17 8:40 UTC (permalink / raw)
To: illusion.wang
Cc: dimon.zhao, alvin.wang, sam.chen, netdev, andrew+netdev, corbet,
kuba, horms, linux-doc, pabeni, vadim.fedorenko, lukas.bulwahn,
edumazet, enelsonmoore, skhan, hkallweit1, open list
In-Reply-To: <20260611044916.2383-2-illusion.wang@nebula-matrix.com>
[-- Attachment #1: Type: text/plain, Size: 3848 bytes --]
On Thu, Jun 11, 2026 at 12:49:00PM +0800, illusion.wang wrote:
> +static int nbl_probe(struct pci_dev *pdev,
> + const struct pci_device_id *id)
> +{
> + return 0;
> +}
> +
> +static void nbl_remove(struct pci_dev *pdev)
> +{
> +}
> [...]
> +static const struct pci_device_id nbl_id_table[] = {
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_LX),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_BASE_T),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_LX_BASE_T),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_LX_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_BASE_T_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18110_LX_BASE_T_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_LX),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_BASE_T),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_LX_BASE_T),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_LX_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_BASE_T_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + { PCI_DEVICE(NBL_VENDOR_ID, NBL_DEVICE_ID_M18000_LX_BASE_T_OCP),
> + .driver_data = BIT(NBL_CAP_HAS_NET_BIT) | BIT(NBL_CAP_IS_NIC_BIT) |
> + BIT(NBL_CAP_IS_LEONIS_BIT) },
> + /* required as sentinel */
> + {
> + 0,
Please drop this zero. The most usual style is `{ }`.
> + }
> +};
> +MODULE_DEVICE_TABLE(pci, nbl_id_table);
> +
> +static struct pci_driver nbl_driver = {
> + .name = NBL_DRIVER_NAME,
> + .id_table = nbl_id_table,
> + .probe = nbl_probe,
> + .remove = nbl_remove,
> +};
The pci bus probe function has (pci_device_probe() ->
__pci_device_probe()):
int error = 0;
if (drv->probe) {
...
}
return error;
So given that the probe function does nothing apart from returning zero,
you can just drop .probe(). (There is an additional check against
.id_table, but I'm pretty sure that isn't relevant because
pci_bus_match() already makes sure that there is a match.) The same is
true for .remove().
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net] net: rnpgbe: fix mailbox endianness handling
From: Dong Yibo @ 2026-06-17 8:35 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko
Cc: netdev, linux-kernel, dong100, yaojun
Mailbox data is exchanged through 32-bit MMIO accesses but the
mailbox payload is defined using little-endian FW structures with
__le16 and __le32 fields.
The mailbox read/write helpers previously operated on raw u32
buffers without performing endian conversion. On big-endian
systems this causes mailbox payload fields to be byte-swapped in
memory, resulting in corrupted FW command and reply structures.
Convert mailbox data between CPU-endian MMIO values and the
little-endian mailbox wire format using cpu_to_le32() on reads and
le32_to_cpu() on writes.
Also switch the helper interfaces to use void */const void * since
the mailbox transport layer operates on opaque payload buffers
rather than native-endian u32 arrays.
Fixes: 4543534c3ef5 ("net: rnpgbe: Add basic mbx ops support")
Signed-off-by: Dong Yibo <dong100@mucse.com>
---
drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.c | 16 ++++++++++------
drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.h | 5 +++--
.../net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c | 7 +++----
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.c b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.c
index de5e29230b3c..0fccfc49ffc7 100644
--- a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.c
+++ b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.c
@@ -166,10 +166,12 @@ static void mucse_mbx_inc_pf_ack(struct mucse_hw *hw)
*
* Return: 0 on success, negative errno on failure
**/
-static int mucse_read_mbx_pf(struct mucse_hw *hw, u32 *msg, u16 size)
+static int mucse_read_mbx_pf(struct mucse_hw *hw, void *msg, u16 size)
{
const int size_in_words = size / sizeof(u32);
struct mucse_mbx_info *mbx = &hw->mbx;
+ int off = MUCSE_MBX_FWPF_SHM;
+ __le32 *msg_le32 = msg;
int err;
err = mucse_obtain_mbx_lock_pf(hw);
@@ -177,7 +179,7 @@ static int mucse_read_mbx_pf(struct mucse_hw *hw, u32 *msg, u16 size)
return err;
for (int i = 0; i < size_in_words; i++)
- msg[i] = mbx_data_rd32(mbx, MUCSE_MBX_FWPF_SHM + 4 * i);
+ msg_le32[i] = cpu_to_le32(mbx_data_rd32(mbx, off + 4 * i));
/* Hw needs write data_reg at last */
mbx_data_wr32(mbx, MUCSE_MBX_FWPF_SHM, 0);
/* flush reqs as we have read this request data */
@@ -236,7 +238,7 @@ static int mucse_poll_for_msg(struct mucse_hw *hw)
* Return: 0 if it successfully received a message notification and
* copied it into the receive buffer, negative errno on failure
**/
-int mucse_poll_and_read_mbx(struct mucse_hw *hw, u32 *msg, u16 size)
+int mucse_poll_and_read_mbx(struct mucse_hw *hw, void *msg, u16 size)
{
int err;
@@ -290,10 +292,11 @@ static void mucse_mbx_inc_pf_req(struct mucse_hw *hw)
* Return: 0 if it successfully copied message into the buffer,
* negative errno on failure
**/
-static int mucse_write_mbx_pf(struct mucse_hw *hw, u32 *msg, u16 size)
+static int mucse_write_mbx_pf(struct mucse_hw *hw, const void *msg, u16 size)
{
const int size_in_words = size / sizeof(u32);
struct mucse_mbx_info *mbx = &hw->mbx;
+ const __le32 *msg_le32 = msg;
int err;
err = mucse_obtain_mbx_lock_pf(hw);
@@ -301,7 +304,8 @@ static int mucse_write_mbx_pf(struct mucse_hw *hw, u32 *msg, u16 size)
return err;
for (int i = 0; i < size_in_words; i++)
- mbx_data_wr32(mbx, MUCSE_MBX_FWPF_SHM + i * 4, msg[i]);
+ mbx_data_wr32(mbx, MUCSE_MBX_FWPF_SHM + i * 4,
+ le32_to_cpu(msg_le32[i]));
/* flush acks as we are overwriting the message buffer */
hw->mbx.fw_ack = mucse_mbx_get_fwack(mbx);
@@ -360,7 +364,7 @@ static int mucse_poll_for_ack(struct mucse_hw *hw)
* Return: 0 if it successfully copied message into the buffer and
* received an ack to that message within delay * timeout_cnt period
**/
-int mucse_write_and_wait_ack_mbx(struct mucse_hw *hw, u32 *msg, u16 size)
+int mucse_write_and_wait_ack_mbx(struct mucse_hw *hw, const void *msg, u16 size)
{
int err;
diff --git a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.h b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.h
index e6fcc8d1d3ca..25bfc97c24c0 100644
--- a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.h
+++ b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx.h
@@ -14,7 +14,8 @@
#define MUCSE_MBX_REQ BIT(0) /* Request a req to mailbox */
#define MUCSE_MBX_PFU BIT(3) /* PF owns the mailbox buffer */
-int mucse_write_and_wait_ack_mbx(struct mucse_hw *hw, u32 *msg, u16 size);
+int mucse_write_and_wait_ack_mbx(struct mucse_hw *hw,
+ const void *msg, u16 size);
void mucse_init_mbx_params_pf(struct mucse_hw *hw);
-int mucse_poll_and_read_mbx(struct mucse_hw *hw, u32 *msg, u16 size);
+int mucse_poll_and_read_mbx(struct mucse_hw *hw, void *msg, u16 size);
#endif /* _RNPGBE_MBX_H */
diff --git a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
index 8c8bd5e8e1db..2ac97915a098 100644
--- a/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
+++ b/drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
@@ -28,12 +28,11 @@ static int mucse_fw_send_cmd_wait_resp(struct mucse_hw *hw,
int err;
mutex_lock(&hw->mbx.lock);
- err = mucse_write_and_wait_ack_mbx(hw, (u32 *)req, len);
+ err = mucse_write_and_wait_ack_mbx(hw, req, len);
if (err)
goto out;
do {
- err = mucse_poll_and_read_mbx(hw, (u32 *)reply,
- sizeof(*reply));
+ err = mucse_poll_and_read_mbx(hw, reply, sizeof(*reply));
if (err)
goto out;
/* mucse_write_and_wait_ack_mbx return 0 means fw has
@@ -125,7 +124,7 @@ int mucse_mbx_powerup(struct mucse_hw *hw, bool is_powerup)
len = le16_to_cpu(req.datalen);
mutex_lock(&hw->mbx.lock);
- err = mucse_write_and_wait_ack_mbx(hw, (u32 *)&req, len);
+ err = mucse_write_and_wait_ack_mbx(hw, &req, len);
mutex_unlock(&hw->mbx.lock);
return err;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net] ipv6: ndisc: fix NULL deref in accept_untracked_na()
From: Jiayuan Chen @ 2026-06-17 8:32 UTC (permalink / raw)
To: Weiming Shi, David S . Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, linux-kernel, Xiang Mei
In-Reply-To: <20260617065512.2529757-2-bestswngs@gmail.com>
On 6/17/26 2:55 PM, Weiming Shi wrote:
> accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)
> and dereferences idev->cnf.accept_untracked_na without a NULL check,
Does ipv6_rpl_srh_rcv have same problem?
^ permalink raw reply
* Re: [REGRESSION 6.16] r8169 RTL8168h/8111h fails to probe — "Unable to change power state from D3cold to D0" — bisected to 4d4c10f763d7
From: Thorsten Leemhuis @ 2026-06-17 8:32 UTC (permalink / raw)
To: Josh Perry, mario.limonciello, bhelgaas
Cc: hkallweit1, nic_swsd, rafael, linux-pci, netdev, regressions
In-Reply-To: <d4aaa5e8-7366-461c-94b1-ccf3631c8bf9@6bit.com>
On 6/12/26 03:07, Josh Perry wrote:
> #regzbot introduced: 4d4c10f763d7
>
> Since v6.16 one of two onboard RTL8168h/8111h NICs on this board fails
> to probe on boot; the device drops to D3cold and the driver can't bring
> it back:
FWIW, that commit is 4d4c10f763d780 ("PCI: Explicitly put devices into
D0 when initializing") [v6.16-rc1] from Mario, who is already CCed, but
looks like might be on holiday or something due to inactivity on the
lists in the recent days. So it might take a few days before this moves on.
Josh, this is not my area of expertise, but there are two things I guess
might be helpful:
* retry with 7.1
* upload "dmesg" and "sudo lspci -vvv" output from working and broken
kernels somewhere (like bugzilla.kernel.org).
Ciao, Thorsten
> r8169 0000:02:00.0 eth0: RTL8168h/8111h, 00:2b:67:48:40:01, XID 541,
> IRQ 137
> r8169 0000:04:00.0: Unable to change power state from D3cold to D0,
> device inaccessible
> r8169 0000:04:00.0: Mem-Wr-Inval unavailable
> r8169 0000:04:00.0: error -EIO: PCI read failed
> r8169 0000:04:00.0: probe with driver r8169 failed with error -5
>
> The board has two identical RTL8168h NICs (both XID 541): 0000:02:00.0
> and 0000:04:00.0. Only 04:00.0 fails — its sibling 02:00.0, on a
> different root port, probes and works normally on the very same kernel
> and boot. The failing NIC then does not appear (no enp4s0), taking the
> machine's WAN offline. This strongly suggests the problem is port/
> topology-specific rather than device- or driver-specific: the upstream
> port behind 04:00.0 is placed in D3cold and the endpoint cannot be
> resumed to D0.
>
> Hardware: RTL8168h/8111h, XID 541, PCI 04:00.0 (onboard 1GbE).
> Platform: Lenovo ThinkCentre M90n-1 (11AHS0B200), BIOS M2AKT49A
> (2026-03-25, latest available). Firmware is current, so this is not a
> platform-firmware issue.
>
> Bisection: v6.15 good, v6.16 bad (verified by booting both). I then
> reverted 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when
> initializing") together with its follow-up 907a7a2e5bf4 ("PCI/PM: Set up
> runtime PM even for devices without PCI PM") on top of 6.16.7: the NIC
> probes and links at 1Gbps/Full normally, with no workaround:
>
> r8169 0000:04:00.0 eth1: RTL8168h/8111h, 00:2b:67:48:40:02, XID 541,
> IRQ 138
> r8169 0000:04:00.0 enp4s0: Link is Up - 1Gbps/Full - flow control rx/tx
>
> Workaround: booting an unmodified v6.16+ kernel with pcie_port_pm=off
> also restores the NIC, which is consistent with the upstream port being
> placed in D3cold and the device failing to resume to D0 after the
> explicit-D0 init change.
>
> The follow-up 907a7a2e5bf4 does not fix this resume case: v6.18.33 is
> still affected (retested today on current firmware).
>
> Happy to test patches or provide full dmesg / lspci.
>
^ permalink raw reply
* Re: [PATCH net-next v6 1/2] dinghai: add ZTE network driver support
From: Uwe Kleine-König @ 2026-06-17 8:30 UTC (permalink / raw)
To: han.junyang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, linux-kernel,
netdev, ran.ming, han.chengfei, zhang.yanze
In-Reply-To: <20260616213057452I2KLm3mVgWYl_SUTy_YYS@zte.com.cn>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Hello,
On Tue, Jun 16, 2026 at 09:30:57PM +0800, han.junyang@zte.com.cn wrote:
> +static const struct pci_device_id dh_pf_pci_table[] = {
> + { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_PF_DEVICE_ID), 0 },
> + { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_VF_DEVICE_ID), 0 },
> + { 0, }
> +};
Please make this:
+static const struct pci_device_id dh_pf_pci_table[] = {
+ { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_PF_DEVICE_ID) },
+ { PCI_DEVICE(ZXDH_PF_VENDOR_ID, ZXDH_VF_DEVICE_ID) },
+ { }
+};
(because the assignment to .driver_data is superflous and initializing
it using a list expression is in the way for one of my patch quests).
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 5.10.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:27 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Jakub Kicinski, Eric W. Biederman, Eric Dumazet,
linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 1bfede407270d..05fcbfacc3433 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -198,6 +198,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 743716ebebdb9..bda3add65c76e 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1341,6 +1341,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 5.15.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:27 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Jakub Kicinski, Eric Dumazet, Eric W. Biederman,
linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index afd9060c5421c..8a61011fdaeef 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -198,6 +198,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index cfacf8965bc59..c644d59d70900 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1664,6 +1664,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 6.1.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:27 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Eric W. Biederman, linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 98c669ad51414..da4affff65476 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index e1e8c825483aa..dac8cc5a79f5a 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1707,6 +1707,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 6.6.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:26 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Eric W. Biederman, linux-can, netdev, linux-kernel
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/veth.c | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 98c669ad51414..da4affff65476 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 2b3b0beb55c88..ba4ca6c6bc9d8 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1857,6 +1857,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* [PATCH 6.12.y] net: add missing ns_capable check for peer netns
From: Maximilian Heyne @ 2026-06-17 8:25 UTC (permalink / raw)
To: stable
Cc: Maximilian Heyne, Marc Kleine-Budde, Vincent Mailhol, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Daniel Borkmann, Nikolay Aleksandrov, Eric W. Biederman,
linux-can, netdev, linux-kernel, bpf
The upstream commit 7b735ef81286 ("rtnetlink: add missing
netlink_ns_capable() check for peer netns") doesn't apply on older
stable kernels due to refactoring. Therefore, this patch is an attempt
to implement the same capability check just directly in the respective
interface types.
Approximate the netlink_ns_capable check with an ns_capable check. As
the newlink operation is synchronous this should result in the same
behavior.
Without this commit, for example, the following command creating a veth
device in network namespace of pid 1 succeeds:
$ unshare -U -r -n -- bash -c '
ip link add veth0 type veth peer name foobar netns 1
sleep 60' &
$ ip link show foobar
13: foobar@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 96:09:69:92:92:cc brd ff:ff:ff:ff:ff:ff link-netnsid 1
With this patch, it's returning -EPERM.
This fixes CVE-2026-31692
Cc: stable@vger.kernel.org
Fixes: 81adee47dfb6 ("net: Support specifying the network namespace upon device creation.")
Assisted-by: Kiro:claude
Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
---
drivers/net/can/vxcan.c | 5 +++++
drivers/net/netkit.c | 5 +++++
drivers/net/veth.c | 5 +++++
3 files changed, 15 insertions(+)
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 9e1b7d41005f8..851c93bf0b310 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -211,6 +211,11 @@ static int vxcan_newlink(struct net *net, struct net_device *dev,
if (IS_ERR(peer_net))
return PTR_ERR(peer_net);
+ if (!ns_capable(peer_net->user_ns, CAP_NET_ADMIN)) {
+ put_net(peer_net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(peer_net, ifname, name_assign_type,
&vxcan_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
index fba2c734f0ec7..e0c42fa0c835c 100644
--- a/drivers/net/netkit.c
+++ b/drivers/net/netkit.c
@@ -413,6 +413,11 @@ static int netkit_new_link(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, ifname_assign_type,
&netkit_link_ops, tbp, extack);
if (IS_ERR(peer)) {
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 77e4b0d1ca557..6ffde7ee2119d 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -1854,6 +1854,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (IS_ERR(net))
return PTR_ERR(net);
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
peer = rtnl_create_link(net, ifname, name_assign_type,
&veth_link_ops, tbp, extack);
if (IS_ERR(peer)) {
--
2.50.1
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* Re: [PATCH net v3] net: pch_gbe: handle TX skb allocation failure
From: Simon Horman @ 2026-06-17 8:24 UTC (permalink / raw)
To: Ruoyu Wang
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Masayuki Ohtake, netdev, linux-kernel
In-Reply-To: <20260615125043.3537046-1-ruoyuw560@gmail.com>
On Mon, Jun 15, 2026 at 08:50:42PM +0800, Ruoyu Wang wrote:
> pch_gbe_alloc_tx_buffers() allocates an skb for each TX descriptor and
> then passes the returned pointer to skb_reserve(). If netdev_alloc_skb()
> fails, skb_reserve() dereferences NULL.
>
> Make pch_gbe_alloc_tx_buffers() return an error when an skb allocation
> fails. On failure, let pch_gbe_alloc_tx_buffers() clean the partially
> allocated TX ring before returning the error. While bringing the device
> up, release the RX buffer pool through a shared cleanup helper before
> unwinding the IRQ setup.
>
> Fixes: 77555ee72282 ("net: Add Gigabit Ethernet driver of Topcliff PCH")
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> Changes in v3:
> - Move the partial TX ring cleanup into pch_gbe_alloc_tx_buffers(), as
> suggested by Simon Horman.
>
> Changes in v2:
> - Add the kernel-doc return value description for
> pch_gbe_alloc_tx_buffers().
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if admin queue returns EBUSY
From: Robert Malz @ 2026-06-17 8:11 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <IA3PR11MB8986729EE79F3F3FBAAC68C9E5E42@IA3PR11MB8986.namprd11.prod.outlook.com>
(resend)
Hey Aleksandr,
Thanks for taking a look at this.
exit loop, just like in OOT, happens during:
> if (hw->adminq.sq_last_status != LIBIE_AQ_RC_EBUSY ||
> retry_cnt > ICE_SQ_SEND_MAX_EXECUTE)
> break;
And by the way, I have v3 ready, which I plan to send 24 hours after
the initial submission, it doesn't change any code but I want to keep
the netdev bots happy.
Thanks,
Robert
On Wed, Jun 17, 2026 at 9:47 AM Loktionov, Aleksandr
<aleksandr.loktionov@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Robert Malz via Intel-wired-lan
> > Sent: Wednesday, June 17, 2026 12:08 AM
> > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>
> > Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org
> > Subject: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if
> > admin queue returns EBUSY
> >
> > When the admin queue command to read NVM returns EBUSY, the driver
> > currently treats it as a fatal error and aborts the entire read
> > operation. This can cause spurious NVM read failures during periods
> > of high firmware activity.
> >
> > Add retry logic to ice_read_flat_nvm() that handles EBUSY responses
> > from the admin queue. When an EBUSY error is encountered, release
> > the NVM resource lock, wait for ICE_SQ_SEND_DELAY_TIME_MS, re-
> > acquire it, and retry the failed read. The retry is attempted up to
> > ICE_SQ_SEND_MAX_EXECUTE times before giving up.
> >
> > Code was extracted from OOT ice driver 1.15.4 release. Additional
> > change was made to reset last_cmd in case of retry to make sure that
> > all commands are retried properly.
> >
> > Fixes: e94509906d6b ("ice: create function to read a section of the
> > NVM and Shadow RAM")
> > Signed-off-by: Robert Malz <robert.malz@canonical.com>
> > ---
> > Changes in v2:
> > - change ICE_AQ_RC_EBUSY -> LIBIE_AQ_RC_EBUSY
> >
> > drivers/net/ethernet/intel/ice/ice_nvm.c | 25 +++++++++++++++++++--
> > ---
> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_nvm.c
> > b/drivers/net/ethernet/intel/ice/ice_nvm.c
> > index 7e187a804dfa..b3120605d66f 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_nvm.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_nvm.c
> > @@ -67,6 +67,7 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> > u32 *length, u8 *data, {
> > u32 inlen = *length;
> > u32 bytes_read = 0;
> > + int retry_cnt = 0;
> > bool last_cmd;
> > int status;
> >
> > @@ -96,11 +97,25 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> > u32 *length, u8 *data,
> > offset, read_size,
> > data + bytes_read, last_cmd,
> > read_shadow_ram, NULL);
> > - if (status)
> > - break;
> > -
> > - bytes_read += read_size;
> > - offset += read_size;
> > + if (status) {
> > + if (hw->adminq.sq_last_status !=
> > LIBIE_AQ_RC_EBUSY ||
> > + retry_cnt > ICE_SQ_SEND_MAX_EXECUTE)
> > + break;
> > + ice_debug(hw, ICE_DBG_NVM,
> > + "NVM read EBUSY error, retry %d\n",
> > + retry_cnt + 1);
> > + last_cmd = false;
> > + ice_release_nvm(hw);
> > + msleep(ICE_SQ_SEND_DELAY_TIME_MS);
> > + status = ice_acquire_nvm(hw, ICE_RES_READ);
> > + if (status)
> > + break;
> > + retry_cnt++;
> It looks like you added the retry_cnt increment but you didn't add it into the loop exit condition.
>
>
> > + } else {
> > + bytes_read += read_size;
> > + offset += read_size;
> > + retry_cnt = 0;
> > + }
> > } while (!last_cmd);
> >
> > *length = bytes_read;
> > --
> > 2.34.1
>
^ permalink raw reply
* Re: [PATCH] e1000: Remove redundant else after return
From: Lovekesh Solanki @ 2026-06-17 7:58 UTC (permalink / raw)
To: andrew
Cc: andrew+netdev, anthony.l.nguyen, davem, edumazet, kuba,
lovekeshsolanki00, netdev, pabeni, przemyslaw.kitszel
In-Reply-To: <ead7bfc9-3978-4442-9cd1-23c2182b36b3@lunn.ch>
Hi Andrew,
I read the documentation you linked and understand simple standalone
cleanups are discouraged.
Thanks for the review, I will drop this patch.
Regards,
Lovekesh
^ permalink raw reply
* [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
From: Doruk Tan Ozturk @ 2026-06-17 7:58 UTC (permalink / raw)
To: jmaloy
Cc: davem, edumazet, kuba, pabeni, horms, aleksander.lobakin,
tung.quang.nguyen, tipc-discussion, netdev, linux-kernel,
Doruk Tan Ozturk, stable
tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to
crypto_aead_decrypt(req) without taking a reference on the netns, unlike
the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously
(e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs
tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the
meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the
per-netns tipc_crypto, and the completion then reads it:
tipc_aead_decrypt_done() dereferences aead->crypto->stats and
aead->crypto->net, and tipc_crypto_rcv_complete() dereferences
aead->crypto->aead[] and the node table -- reading freed memory.
Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):
BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)
Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51
Workqueue: events_unbound
Call Trace:
tipc_aead_decrypt_done (net/tipc/crypto.c:999)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 169:
__kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
tipc_crypto_start (net/tipc/crypto.c:1502)
tipc_init_net (net/tipc/core.c:72)
ops_init (net/core/net_namespace.c:137)
setup_net (net/core/net_namespace.c:446)
copy_net_ns (net/core/net_namespace.c:579)
create_new_namespaces (kernel/nsproxy.c:132)
__x64_sys_unshare (kernel/fork.c:3316)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Freed by task 8:
kfree (mm/slub.c:6566)
tipc_exit_net (net/tipc/core.c:119)
cleanup_net (net/core/net_namespace.c:704)
process_one_work (kernel/workqueue.c:3314)
kthread (kernel/kthread.c:436)
This is the same class of bug that commit e279024617134 ("net/tipc: fix
slab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt
side. The encrypt path takes maybe_get_net(aead->crypto->net) before
crypto_aead_encrypt() and drops it with put_net() on the synchronous
return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY
return keeps the reference for the async callback to release. The decrypt
path was left without the equivalent guard.
Mirror the encrypt-side fix on the decrypt path: take a net reference
before crypto_aead_decrypt() (failing with -ENODEV and the matching
bearer put if it cannot be acquired), keep it across the
-EINPROGRESS/-EBUSY async return, and drop it with put_net() on the
synchronous success/error return and at the end of
tipc_aead_decrypt_done().
Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is
flooded with crafted encrypted frames from an unknown peer (driving the
cluster-key decrypt path) while the bearer's netns is repeatedly torn
down. The completion must run asynchronously to outlive
tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts
synchronously, so the async path was exercised via cryptd offload. The
unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the
unpatched upstream path; tipc_aead_decrypt() still lacks
maybe_get_net(aead->crypto->net), so the completion can outlive the free
on any config where crypto_aead_decrypt() goes async.
Found by 0sec automated security-research tooling (https://0sec.ai).
Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
Cc: stable@vger.kernel.org
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
---
v4:
- Use the net parameter for maybe_get_net()/put_net() instead of
dereferencing aead->crypto->net, which is the per-netns structure at
risk during teardown (per the automated review forwarded by Simon
Horman). net == aead->crypto->net here; no functional change.
v3:
- Rewrite the changelog with the decoded stack trace and frame the
reproduction on the current tree (v7.1-rc7); drop the v6.12.92
references (Tung Quang Nguyen).
v2:
- Add Cc: stable@vger.kernel.org and Alexander Lobakin's Reviewed-by.
No functional change.
net/tipc/crypto.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index 6d3b6b89b1d1..16f1ed1f6b1b 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -941,12 +941,20 @@ static int tipc_aead_decrypt(struct net *net, struct tipc_aead *aead,
goto exit;
}
+ /* Get net to avoid freed tipc_crypto when delete namespace */
+ if (!maybe_get_net(net)) {
+ tipc_bearer_put(b);
+ rc = -ENODEV;
+ goto exit;
+ }
+
/* Now, do decrypt */
rc = crypto_aead_decrypt(req);
if (rc == -EINPROGRESS || rc == -EBUSY)
return rc;
tipc_bearer_put(b);
+ put_net(net);
exit:
kfree(ctx);
@@ -984,6 +992,7 @@ static void tipc_aead_decrypt_done(void *data, int err)
}
tipc_bearer_put(b);
+ put_net(net);
}
static inline int tipc_ehdr_size(struct tipc_ehdr *ehdr)
--
2.43.0
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH net v2] iavf: validate num_vsis in VIRTCHNL_OP_GET_VF_RESOURCES response
From: Romanowski, Rafal @ 2026-06-17 7:49 UTC (permalink / raw)
To: Simon Horman, Junrui Luo
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Mitch Williams, Greg Rose, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Yuhao Jiang,
stable@vger.kernel.org
In-Reply-To: <20260518185611.GF98116@horms.kernel.org>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Simon
> Horman
> Sent: Monday, May 18, 2026 8:56 PM
> To: Junrui Luo <moonafterrain@outlook.com>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Mitch Williams <mitch.a.williams@intel.com>; Greg Rose
> <gregory.v.rose@intel.com>; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Yuhao Jiang
> <danisjiang@gmail.com>; stable@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH net v2] iavf: validate num_vsis in
> VIRTCHNL_OP_GET_VF_RESOURCES response
>
> On Thu, May 14, 2026 at 02:55:04PM +0800, Junrui Luo wrote:
> > The VF allocates a fixed-size buffer for IAVF_MAX_VF_VSI (3) VSI
> > entries when processing a VIRTCHNL_OP_GET_VF_RESOURCES response from
> > the PF. However, num_vsis from the PF response is used unchecked as
> > the loop bound when iterating over vsi_res[] in multiple functions.
> >
> > A PF sending num_vsis greater than IAVF_MAX_VF_VSI, or the received
> > message is shorter than num_vsis claims leads to out-of-bounds
> > accesses on the vsi_res[] array.
> >
> > Clamp num_vsis based on the actual bytes copied from the PF response.
> >
> > Fixes: 5eae00c57f5e ("i40evf: main driver core")
> > Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
> > ---
> > Changes in v2:
> > - Clamp num_vsis based on actual received message length instead of
> > IAVF_MAX_VF_VSI suggested by Przemek
> > - Link to v1:
> >
> https://lore.kernel.org/r/SYBPR01MB7881AF11C45AEDC0D4CA89C1AF062@SYB
> PR
> > 01MB7881.ausprd01.prod.outlook.com
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> There is an AI-generated review of this patchset available on sashiko.dev.
> However, I believe that the issues raised there can be considered in the context of
> possible follow-up. I do not believe they should block progress of this patch.
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if admin queue returns EBUSY
From: Loktionov, Aleksandr @ 2026-06-17 7:47 UTC (permalink / raw)
To: Robert Malz, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <20260616220827.1647052-1-robert.malz@canonical.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Robert Malz via Intel-wired-lan
> Sent: Wednesday, June 17, 2026 12:08 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH v2] ice: retry reading NVM if
> admin queue returns EBUSY
>
> When the admin queue command to read NVM returns EBUSY, the driver
> currently treats it as a fatal error and aborts the entire read
> operation. This can cause spurious NVM read failures during periods
> of high firmware activity.
>
> Add retry logic to ice_read_flat_nvm() that handles EBUSY responses
> from the admin queue. When an EBUSY error is encountered, release
> the NVM resource lock, wait for ICE_SQ_SEND_DELAY_TIME_MS, re-
> acquire it, and retry the failed read. The retry is attempted up to
> ICE_SQ_SEND_MAX_EXECUTE times before giving up.
>
> Code was extracted from OOT ice driver 1.15.4 release. Additional
> change was made to reset last_cmd in case of retry to make sure that
> all commands are retried properly.
>
> Fixes: e94509906d6b ("ice: create function to read a section of the
> NVM and Shadow RAM")
> Signed-off-by: Robert Malz <robert.malz@canonical.com>
> ---
> Changes in v2:
> - change ICE_AQ_RC_EBUSY -> LIBIE_AQ_RC_EBUSY
>
> drivers/net/ethernet/intel/ice/ice_nvm.c | 25 +++++++++++++++++++--
> ---
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_nvm.c
> b/drivers/net/ethernet/intel/ice/ice_nvm.c
> index 7e187a804dfa..b3120605d66f 100644
> --- a/drivers/net/ethernet/intel/ice/ice_nvm.c
> +++ b/drivers/net/ethernet/intel/ice/ice_nvm.c
> @@ -67,6 +67,7 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> u32 *length, u8 *data, {
> u32 inlen = *length;
> u32 bytes_read = 0;
> + int retry_cnt = 0;
> bool last_cmd;
> int status;
>
> @@ -96,11 +97,25 @@ ice_read_flat_nvm(struct ice_hw *hw, u32 offset,
> u32 *length, u8 *data,
> offset, read_size,
> data + bytes_read, last_cmd,
> read_shadow_ram, NULL);
> - if (status)
> - break;
> -
> - bytes_read += read_size;
> - offset += read_size;
> + if (status) {
> + if (hw->adminq.sq_last_status !=
> LIBIE_AQ_RC_EBUSY ||
> + retry_cnt > ICE_SQ_SEND_MAX_EXECUTE)
> + break;
> + ice_debug(hw, ICE_DBG_NVM,
> + "NVM read EBUSY error, retry %d\n",
> + retry_cnt + 1);
> + last_cmd = false;
> + ice_release_nvm(hw);
> + msleep(ICE_SQ_SEND_DELAY_TIME_MS);
> + status = ice_acquire_nvm(hw, ICE_RES_READ);
> + if (status)
> + break;
> + retry_cnt++;
It looks like you added the retry_cnt increment but you didn't add it into the loop exit condition.
> + } else {
> + bytes_read += read_size;
> + offset += read_size;
> + retry_cnt = 0;
> + }
> } while (!last_cmd);
>
> *length = bytes_read;
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH net] netpoll: run NAPI poll in softirq context to avoid rq->lock self-deadlock
From: John Ogness @ 2026-06-17 7:42 UTC (permalink / raw)
To: Breno Leitao, Sebastian Andrzej Siewior, pmladek
Cc: Jakub Kicinski, Petr Mladek, Sergey Senozhatsky, Peter Zijlstra,
Vlad Poenaru, Thomas Gleixner, netdev, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Clark Williams,
Steven Rostedt, linux-rt-devel, linux-kernel, stable,
Frederic Weisbecker, Ingo Molnar, Vincent Guittot,
Dietmar Eggemann, K Prateek Nayak
In-Reply-To: <ajF5S0uY-8F0jzoh@gmail.com>
On 2026-06-16, Breno Leitao <leitao@debian.org> wrote:
>> So this is not an issue since commit 7eab73b18630e ("netconsole: convert
>> to NBCON console infrastructure"). Because from here now on writes are
>> deferred to the nbcon thread. So this purely about -stable in this case.
>
> Does the nbcon thread handle defer even for consoles that support atomic
> operations?
The all "printk deferred" variants have zero effect on nbcon
drivers. The "printk deferred" variants exist purely as duct tape for
legacy console drivers.
If nbcon drivers provide a safe write_atomic(), they will _always_ write
synchronously when the CPU is in an emergency state. Otherwise nbcon
drivers _always_ defer to their dedicated console printing kthread and
there they use the write_thread() callback.
> netconsole is marked with CON_NBCON_ATOMIC_UNSAFE, which means it rarely
> performs inline/direct printk and instead pushes to the thread, which
> flushes in a safe context.
CON_NBCON_ATOMIC_UNSAFE means it _never_ performs inline/direct printk
console writing. That flags means that in panic, at the _very_ end, just
before going into an infinite nop loop, the CON_NBCON_ATOMIC_UNSAFE
consoles will be flushed directly from the panic context.
> For drivers that behave correctly, I'd like to be able to drop
> CON_NBCON_ATOMIC_UNSAFE, potentially setting it at runtime based on the
> underlying driver capabilities. If netconsole is backed by a well-behaving
> network driver, we could eventually remove the flag (!?)
>
> Would that approach cause any issues?
Removing the flag means the driver can safely write from _any_ context
(including scheduler and NMI), regardless what locks that context may be
holding.
Note that the nbcon framework allows console drivers to mark unsafe
regions in themselves, where atomic writing would not be possible. In
such scenarios, it defers to the dedicated printing kthread (except
during panic, where more agressive tactics are used).
John Ogness
^ permalink raw reply
* RE: [linux-next:master] [selftests] a3f88d89f6: kernel-selftests-bpf.net.test_bridge_neigh_suppress.sh.arping.fail
From: Danielle Ratson @ 2026-06-17 7:29 UTC (permalink / raw)
To: Oliver Sang
Cc: oe-lkp@lists.linux.dev, lkp@intel.com, Jakub Kicinski,
Nikolay Aleksandrov, netdev@vger.kernel.org
In-Reply-To: <ai/3+f7LJp6pyLJi@xsang-OptiPlex-9020>
Hi Oliver,
Thank you for confirming the arping version. ARPing 2.25 by Thomas Habets has incompatible semantics for several flags that the test relies on (-D, b, -U, -A).
So, the failures are a tool version issue rather than a kernel regression.
This is not limited to the new commit- looking at the 56 failures in the added log, the other arping-based test cases that existed before commit a3f88d89f698 are also failing, which confirms the root cause.
The same assumption (iputils arping) is made by other net selftests as well:
test_vxlan_nh.sh, forwarding/vxlan_asymmetric.sh, and arp_ndisc_untracked_subnets.sh all use iputils-specific flags.
There are two options to address this on your end:
1. Install iputils-arping and ensure it takes precedence over ARPing 2.25 in PATH. Running "arping -V" should then show "iputils".
2. If that is not feasible, I can send a fix that adds an iputils version check to test_bridge_neigh_suppress.sh, causing it to SKIP cleanly when iputils arping is not present:
if ! arping -V 2>&1 | grep -q "iputils"; then
echo "SKIP: Test requires iputils arping"
exit $ksft_skip
fi
This will result in a SKIP rather than a FAIL for your environment.
Thanks,
Danielle
> -----Original Message-----
> From: Oliver Sang <oliver.sang@intel.com>
> Sent: Monday, 15 June 2026 16:03
> To: Danielle Ratson <danieller@nvidia.com>
> Cc: oe-lkp@lists.linux.dev; lkp@intel.com; Jakub Kicinski <kuba@kernel.org>;
> Nikolay Aleksandrov <razor@blackwall.org>; netdev@vger.kernel.org;
> oliver.sang@intel.com
> Subject: Re: [linux-next:master] [selftests] a3f88d89f6: kernel-selftests-
> bpf.net.test_bridge_neigh_suppress.sh.arping.fail
>
> hi, Danielle,
>
> On Thu, Jun 11, 2026 at 11:44:39AM +0000, Danielle Ratson wrote:
> > Hi Oliver,
> >
> > Thank you for the report.
> >
> > The failures appear to be caused by an arping tool version mismatch.
> > The test was written assuming iputils arping semantics, but not all
> distributions ship that version. Different arping implementations have
> incompatible behavior for the flags used throughout
> test_bridge_neigh_suppress.sh.
> >
> > Looking at the added log, the 56 failures are not limited to the
> neigh_suppress_arp_probe section.
> > The other arping-based test cases in the file are also affected, which is
> consistent with a tool version issue rather than a kernel regression.
> >
> > To confirm the root cause on your end, please share the results for running
> the below:
> > $ arping -V
> > $ ./test_bridge_neigh_suppress.sh -t neigh_suppress_arp -v
>
> sorry for late.
>
> our tests run in a auto framework, I had to add some code to print above
> information, but so far, it just generates below output.
> before we try further, want to seek your advice if these information are
> enough?
>
> KERNEL SELFTESTS: linux_headers_dir is /usr/src/linux-headers-x86_64-rhel-
> 9.4-bpf-a3f88d89f698743a8cd91fb43f997e2d292a168d
> ### arping -V
> arping: option requires an argument -- 'V'
> ARPing 2.25, by Thomas Habets <thomas@habets.se>
> usage: arping [ -0aAbdDeFpPqrRuUvzZ ] [ -w <sec> ] [ -W <sec> ] [ -S <host/ip>
> ]
> [ -T <host/ip ] [ -s <MAC> ] [ -t <MAC> ] [ -c <count> ]
> [ -C <count> ] [ -i <interface> ] [ -m <type> ] [ -g <group> ]
> [ -V <vlan> ] [ -Q <priority> ] <host/ip/MAC | -B> For complete usage
> info, use --help or check the manpage.
> ### ./test_bridge_neigh_suppress.sh -t neigh_suppress_arp -v
> <-------- seems there is no output here
> Per-port ARP suppression - VLAN 10 <-------- seems already start the
> tests
> ----------------------------------
> COMMAND: tc -n sw1-U1mYwE qdisc replace dev vx0 clsact
>
>
> >
> > Thanks,
> > Danielle
> >
> > > -----Original Message-----
> > > From: kernel test robot <oliver.sang@intel.com>
> > > Sent: Thursday, 11 June 2026 10:23
> > > To: Danielle Ratson <danieller@nvidia.com>
> > > Cc: oe-lkp@lists.linux.dev; lkp@intel.com; Jakub Kicinski
> > > <kuba@kernel.org>; Nikolay Aleksandrov <razor@blackwall.org>;
> > > netdev@vger.kernel.org; oliver.sang@intel.com
> > > Subject: [linux-next:master] [selftests] a3f88d89f6:
> > > kernel-selftests- bpf.net.test_bridge_neigh_suppress.sh.arping.fail
> > >
> > >
> > > hi, Danielle Ratson,
> > >
> > > for new added tests, we still found some failures in our tests, not
> > > sure if any dependencies we missed? thanks
> > >
> > >
> > > Hello,
> > >
> > > kernel test robot noticed "kernel-selftests-
> > > bpf.net.test_bridge_neigh_suppress.sh.arping.fail" on:
> > >
> > > commit: a3f88d89f698743a8cd91fb43f997e2d292a168d ("selftests: net:
> > > Add tests for ARP probe and DAD NS handling")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
> > > master
> > >
> > > in testcase: kernel-selftests-bpf
> > > version:
> > > with following parameters:
> > >
> > > group: net
> > >
> > >
> > > config: x86_64-rhel-9.4-bpf
> > > compiler: gcc-14
> > > test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake)
> > > with 32G memory
> > >
> > > (please refer to attached dmesg/kmsg for entire log/backtrace)
> > >
> > >
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > version of the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > > | Closes:
> > > | https://lore.kernel.org/oe-lkp/202606110955.8f29025d-lkp@intel.com
> > >
> > >
> > > # timeout set to 3600
> > > # selftests: net: test_bridge_neigh_suppress.sh #
> > >
> > > [...]
> > >
> > > #
> > > # Per-port ARP probe suppression
> > > # ------------------------------
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: "neigh_suppress" is on [ OK ]
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: FDB and neighbor entry installation [ OK ]
> > > # TEST: arping [FAIL]
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: neighbor removal [ OK ]
> > > # TEST: ARP probe suppression [FAIL]
> > > # TEST: "neigh_suppress" is off [ OK ]
> > > # TEST: ARP probe suppression [FAIL]
> > > #
> > > # Per-port DAD NS suppression
> > > # ---------------------------
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: "neigh_suppress" is on [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: FDB and neighbor entry installation [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: DAD NS proxy NA reply [ OK ]
> > > # TEST: neighbor removal [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > # TEST: "neigh_suppress" is off [ OK ]
> > > # TEST: DAD NS suppression [ OK ]
> > > #
> > > # Tests passed: 124
> > > # Tests failed: 56
> > > not ok 110 selftests: net: test_bridge_neigh_suppress.sh # exit=1
> > >
> > >
> > >
> > > The kernel config and materials to reproduce are available at:
> > > https://download.01.org/0day-
> > > ci/archive/20260611/202606110955.8f29025d-lkp@intel.com
> > >
> > >
> > >
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://github.com/intel/lkp-tests/wiki
> >
^ permalink raw reply
* Re: [TEST] vlan-bridge-binding-sh flaky
From: Ido Schimmel @ 2026-06-17 7:25 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, Petr Machata
In-Reply-To: <20260616092733.3a31be4d@kernel.org>
On Tue, Jun 16, 2026 at 09:27:33AM -0700, Jakub Kicinski wrote:
> Hi Ido!
>
> tools/testing/selftests/net/vlan_bridge_binding.sh got flaky recently.
>
> https://netdev.bots.linux.dev/contest.html?test=vlan-bridge-binding-sh
>
> Is it due to Eric's change or something else? Used to be pretty solid.
> First lake a week ago and 8 more since, before that for 3 weeks there
> were 0 flakes.
The failure reason is the same across all the test runs: Observing an UP
operational state instead of DOWN. I believe that's because link watch
can delay carrier loss events by up to 1 second and that's the timeout
the test is using.
I increased the timeout to 2 seconds and didn't observe a failure in
over 100 iterations. Previously it failed after 48 iterations.
I will send a patch.
^ permalink raw reply
* [PATCH net v2] ice: Fix use-after-scope in ice_sched_add_nodes_to_layer()
From: NeKon69 @ 2026-06-17 7:21 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
piotr.kwapulinski, intel-wired-lan, netdev, linux-kernel, NeKon69
Commit 7fb09a737536 ("ice: Modify recursive way of adding nodes")
changed ice_sched_add_nodes_to_layer() from recursive control flow to an
iterative loop.
Inside the loop, first_teid_ptr may be set to the address of a
block-local variable:
u32 temp;
...
if (num_added)
first_teid_ptr = &temp;
On the next loop iteration, first_teid_ptr may be passed to
ice_sched_add_nodes_to_hw_layer(), after temp from the previous
iteration has gone out of scope.
Instead of keeping temporary storage for later calls, allow
first_node_teid to be NULL when the caller does not need the TEID.
This was found by Clang with LifetimeSafety enabled while testing C
language support on a Linux allmodconfig build.
Fixes: 7fb09a737536 ("ice: Modify recursive way of adding nodes")
Link: https://github.com/llvm/llvm-project/pull/203270
Signed-off-by: NeKon69 <nobodqwe@gmail.com>
---
v2:
- Allow first_node_teid to be NULL when callers do not need the TEID.
- Pass NULL after the first TEID has already been returned instead of using
temporary stack storage.
- Update kernel-doc for helpers accepting NULL.
- Link to v1: https://lore.kernel.org/netdev/20260613101440.80190-1-nobodqwe@gmail.com/
- Compile-tested with:
make drivers/net/ethernet/intel/ice/ice_sched.o
drivers/net/ethernet/intel/ice/ice_sched.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_sched.c b/drivers/net/ethernet/intel/ice/ice_sched.c
index fff0c1afdb41..89e191c839b1 100644
--- a/drivers/net/ethernet/intel/ice/ice_sched.c
+++ b/drivers/net/ethernet/intel/ice/ice_sched.c
@@ -895,7 +895,8 @@ void ice_sched_cleanup_all(struct ice_hw *hw)
* @layer: layer number to add nodes
* @num_nodes: number of nodes
* @num_nodes_added: pointer to num nodes added
- * @first_node_teid: if new nodes are added then return the TEID of first node
+ * @first_node_teid: if new nodes are added then return the TEID of first node,
+ * may be NULL
* @prealloc_nodes: preallocated nodes struct for software DB
*
* This function add nodes to HW as well as to SW DB for a given layer
@@ -1000,7 +1001,7 @@ ice_sched_add_elems(struct ice_port_info *pi, struct ice_sched_node *tc_node,
if (!pi->sib_head[tc_node->tc_num][layer])
pi->sib_head[tc_node->tc_num][layer] = new_node;
- if (i == 0)
+ if (first_node_teid && i == 0)
*first_node_teid = teid;
}
@@ -1015,7 +1016,7 @@ ice_sched_add_elems(struct ice_port_info *pi, struct ice_sched_node *tc_node,
* @parent: pointer to parent node
* @layer: layer number to add nodes
* @num_nodes: number of nodes to be added
- * @first_node_teid: pointer to the first node TEID
+ * @first_node_teid: pointer to the first node TEID, may be NULL
* @num_nodes_added: pointer to number of nodes added
*
* Add nodes into specific HW layer.
@@ -1078,7 +1079,6 @@ ice_sched_add_nodes_to_layer(struct ice_port_info *pi,
*num_nodes_added = 0;
while (*num_nodes_added < num_nodes) {
u16 max_child_nodes, num_added = 0;
- u32 temp;
status = ice_sched_add_nodes_to_hw_layer(pi, tc_node, parent,
layer, new_num_nodes,
@@ -1109,13 +1109,11 @@ ice_sched_add_nodes_to_layer(struct ice_port_info *pi,
* try the next available sibling.
*/
parent = ice_sched_find_next_vsi_node(parent);
- /* Don't modify the first node TEID memory if the
- * first node was added already in the above call.
- * Instead send some temp memory for all other
- * recursive calls.
+ /* Don't modify the first node TEID memory if the first node
+ * was added already in the above call.
*/
if (num_added)
- first_teid_ptr = &temp;
+ first_teid_ptr = NULL;
new_num_nodes = num_nodes - *num_nodes_added;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] net: airoha: Fix off-by-one error in HTB rate-limit channel removal
From: Lorenzo Bianconi @ 2026-06-17 7:13 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166483303.2209640.10761097847073356089@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
> In airoha_tc_remove_htb_queue(), the rate-limit was being cleared
> using (queue + 1) instead of queue, causing:
> - The original channel rate-limit configuration to remain active
> - The next channel to be incorrectly disabled
> - Potential out-of-bounds access when queue == 3 (channel 4)
>
> The alloc path (airoha_tc_htb_alloc_leaf_queue) correctly uses
> channel (0..3), but the remove path incorrectly added 1.
>
> Fix by using queue directly to match the alloc and rollback paths.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..02807b3967 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2805,7 +2805,7 @@ static void airoha_tc_remove_htb_queue(struct net_device *dev, int queue)
> struct airoha_gdm_port *port = netdev_priv(dev);
>
> netif_set_real_num_tx_queues(dev, dev->real_num_tx_queues - 1);
> - airoha_qdma_set_tx_rate_limit(dev, queue + 1, 0, 0);
> + airoha_qdma_set_tx_rate_limit(dev, queue, 0, 0);
> clear_bit(queue, port->qos_sq_bmap);
> }
Please hold on with this patch, I am aware of the bug and the fix is already in
my queue [0]. I am just waiting the net-next to be merged into net in order to
avoid merge conflicts.
Regards,
Lorenzo
[0] https://github.com/LorenzoBianconi/net-next/commits/airoha-qos-fixes-for-net/
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-17 7:10 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
> mask parameter, the loop still incorrectly clears queues within the
> same channel beyond queue 7.
>
> Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..a1eda13400 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
> struct airoha_gdm_port *port = netdev_priv(dev);
> int i;
>
> - for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> + for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
> airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
Even if the current codebase supports just AIROHA_NUM_QOS_CHANNEL (4), the hw
exposes 32 hw QoS channels (AIROHA_NUM_TX_RING). Here we are just clearing the
configuration, so I guess the current implementation is correct.
Regards,
Lorenzo
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
From: Lorenzo Bianconi @ 2026-06-17 6:58 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178167550101.2217645.14579307712717502425@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
> In mtk_ppe_init(), when accounting is enabled, the error paths for
> dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL
> directly, bypassing the err_free_l2_flows label that destroys the
> rhashtable initialized earlier.
>
> While this leak only occurs during probe (not runtime) and the leaked
> memory is minimal (an empty rhash table), fixing it ensures proper
> error path cleanup consistency.
>
> Fix by changing the two return NULL statements to goto err_free_l2_flows.
>
> Fixes: 603ea5e7ffa7 ("net: ethernet: mtk_eth_soc: fix memory leak in error path")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/mediatek/mtk_ppe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
> index 18279e2a70..8451dc3fd0 100644
> --- a/drivers/net/ethernet/mediatek/mtk_ppe.c
> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
> @@ -918,7 +918,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> mib = dmam_alloc_coherent(ppe->dev, MTK_PPE_ENTRIES * sizeof(*mib),
> &ppe->mib_phys, GFP_KERNEL);
> if (!mib)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->mib_table = mib;
>
> @@ -926,7 +926,7 @@ struct mtk_ppe *mtk_ppe_init(struct mtk_eth *eth, void __iomem *base, int index)
> GFP_KERNEL);
>
> if (!acct)
> - return NULL;
> + goto err_free_l2_flows;
>
> ppe->acct_table = acct;
> }
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox