* Re: [Intel-wired-lan] [PATCH iwl-next] ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update
From: Simon Horman @ 2026-04-03 13:39 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: Simon Horman, intel-wired-lan, netdev, anthony.l.nguyen
In-Reply-To: <20260327073046.134085-6-aleksandr.loktionov@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update
During an NVM update the PHY reset clears the Technology Ability Field
(IEEE 802.3 clause 37 register 7.10) back to hardware defaults. When
the driver subsequently calls only hw->mac.ops.fc_enable() the SRRCTL
register is recalculated from the stale autonegotiated capability bits,
which the MDD (Malicious Driver Detect) logic treats as an invalid
change and halts traffic on the PF.
Fix by calling ixgbe_setup_fc() immediately before fc_enable() in
ixgbe_watchdog_update_link() so that flow-control autoneg and the
PHY registers are re-programmed in the correct order after any reset.
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 0bc806aaed90..96e912371d9a 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -8029,6 +8029,12 @@ static void ixgbe_watchdog_update_link(struct ixgbe_adapter *adapter)
> pfc_en |= !!(adapter->ixgbe_ieee_pfc->pfc_en);
>
> if (link_up && !((adapter->flags & IXGBE_FLAG_DCB_ENABLED) && pfc_en)) {
> + if (hw->mac.ops.setup_fc) {
> + int err = hw->mac.ops.setup_fc(hw);
> +
> + if (err)
> + e_warn(drv, "setup_fc failed: %d\n", err);
> + }
What happens if setup_fc() fails here? The patch adds this call to fix
MDD issues caused by stale PHY autoneg state after NVM updates.
However, if setup_fc() returns an error, the code only logs a warning
and continues:
if (hw->mac.ops.setup_fc) {
int err = hw->mac.ops.setup_fc(hw);
if (err)
e_warn(drv, "setup_fc failed: %d\n", err);
}
hw->mac.ops.fc_enable(hw);
Since fc_enable() relies on hw->fc.current_mode being properly set by
the autoneg process initiated by setup_fc(), calling it after a
setup_fc failure means it operates on the same stale state the patch
was meant to fix.
Could this leave a residual bug where MDD can still trigger and halt
traffic if setup_fc fails?
> hw->mac.ops.fc_enable(hw);
> ixgbe_set_rx_drop_en(adapter);
> }
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: call ixgbe_setup_fc() before fc_enable() after NVM update
From: Simon Horman @ 2026-04-03 13:38 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-6-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:30:40AM +0100, Aleksandr Loktionov wrote:
> From: Radoslaw Tyl <radoslawx.tyl@intel.com>
>
> During an NVM update the PHY reset clears the Technology Ability Field
> (IEEE 802.3 clause 37 register 7.10) back to hardware defaults. When
> the driver subsequently calls only hw->mac.ops.fc_enable() the SRRCTL
> register is recalculated from the stale autonegotiated capability bits,
> which the MDD (Malicious Driver Detect) logic treats as an invalid
> change and halts traffic on the PF.
>
> Fix by calling ixgbe_setup_fc() immediately before fc_enable() in
> ixgbe_watchdog_update_link() so that flow-control autoneg and the
> PHY registers are re-programmed in the correct order after any reset.
>
> Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
This feels like a fix that should have a Fixes tag and be routed
via iwl-net. And some explanation of what effect this has on the user.
Otherwise, please reword the commit message to make it clear this
is not a bug fix.
...
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Kory Maincent @ 2026-04-03 13:38 UTC (permalink / raw)
To: Carlo Szelinsky
Cc: Andrew Lunn, Oleksij Rempel, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <20260403133111.3304497-1-github@szelinsky.de>
On Fri, 3 Apr 2026 15:31:11 +0200
Carlo Szelinsky <github@szelinsky.de> wrote:
> Hi Andrew,
>
> Thx for helping me!
> I thought of keeping the eager path so we still catch broken DT bindings
> early at boot instead of silently failing later on first ethtool access.
> But you're right, dropping it would simplify things quite a bit. Do you
> think that trade-off is worth it? I will follow your lead.
On my side I thinks that's a good idea, and I don't see any issue with that for
now. Oleksij you introduced it here in the first place, is it ok for you?
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next] ixgbe: replace GFP_ATOMIC with GFP_KERNEL in ixgbe_fcoe_ddp_setup()
From: Kohei Enju @ 2026-04-03 13:38 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-7-aleksandr.loktionov@intel.com>
On 03/27 08:30, Aleksandr Loktionov wrote:
> From: Sebastian Basierski <sebastianx.basierski@intel.com>
>
> ixgbe_fcoe_ddp_setup() is always called from process context (FCoE
> offload setup paths) and never from an atomic context. Using
> GFP_ATOMIC is therefore unnecessarily restrictive and wastes memory
> allocator headroom that is reserved for genuine atomic callers.
> Replace the dma_pool_alloc() flag with GFP_KERNEL.
>
> Signed-off-by: Sebastian Basierski <sebastianx.basierski@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> index 011fda9..7fa0971 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> @@ -193,7 +193,7 @@ static int ixgbe_fcoe_ddp_setup(struct net_device *netdev, u16 xid,
> }
>
> /* alloc the udl from per cpu ddp pool */
> - ddp->udl = dma_pool_alloc(ddp_pool->pool, GFP_ATOMIC, &ddp->udp);
> + ddp->udl = dma_pool_alloc(ddp_pool->pool, GFP_KERNEL, &ddp->udp);
Commit fa39ab5184d6 ("scsi: fcoe: Fix I/O path allocation") had introduced
this GFP_ATOMIC flag, since some IO paths called this function with a
spin_lock held. Now, is it safe to roll back this change?
> if (!ddp->udl) {
> e_err(drv, "failed allocated ddp context\n");
> goto out_noddp_unmap;
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH net-next] eth: remove the driver for acenic / tigon1&2
From: Jes Sorensen @ 2026-04-03 13:34 UTC (permalink / raw)
To: Greg KH, Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, chenhuacai,
kernel, tsbogend, James.Bottomley, deller, maddy, mpe, npiggin,
chleroy, hca, gor, agordeev, borntraeger, svens, bhelgaas, dakr,
kwilczynski, ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, ebiggers, ardb, tiwai, tytso, enelsonmoore,
martin.petersen, jirislaby, geert, herbert, vineethr, lirongqing,
kshk, vadim.fedorenko, dong100, wangruikang, hkallweit1, kees,
loongarch, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-pci, rust-for-linux
In-Reply-To: <2026040357-flick-coil-0c5d@gregkh>
On 4/3/26 4:48 AM, Greg KH wrote:
> On Thu, Apr 02, 2026 at 11:30:29AM -0700, Jakub Kicinski wrote:
>> The entire git history for this driver looks like tree-wide
>> and automated cleanups. There's even more coming now with
>> AI, so let's try to delete it instead.
>>
>> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Jes Sorensen <jes@trained-monkey.org>
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Biju Das @ 2026-04-03 13:36 UTC (permalink / raw)
To: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY7P301MB198462DF309670467625AD40D35EA@TY7P301MB1984.JPNP301.PROD.OUTLOOK.COM>
> -----Original Message-----
> From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> Sent: 03 April 2026 14:23
> To: Biju Das <biju.das.jz@bp.renesas.com>; andrew@lunn.ch; hkallweit1@gmail.com; linux@armlinux.org.uk;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-renesas-soc@vger.kernel.org
> Subject: RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
>
> Hi,
>
> >
> > Hi Ovidiu Panait,
> >
> > Thanks for the patch.
> >
> > > -----Original Message-----
> > > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > Sent: 03 April 2026 12:18
> > > Subject: [PATCH net] net: phy: micrel: Fix MMD register access
> > > during
> > SPD in ksz9131_resume()
> > >
> > > During system suspend, phy_suspend() puts the PHY into Software
> > > Power-
> > Down
> > > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to the
> > KSZ9131 datasheet, MMD register
> > > access is restricted during SPD:
> > >
> > > - Only access to the standard registers (0 through 31) is supported.
> > > - Access to MMD address spaces other than MMD address space 1 is
> > > possible if the spd_clock_gate_override bit is set.
> > > - Access to MMD address space 1 is not possible.
> > >
> > > However, ksz9131_resume() calls ksz9131_config_rgmii_delay() before
> > > kszphy_resume() clears BMCR_PDOWN. This means MMD registers are
> > > accessed
> > while the PHY is still in SPD,
> > > contrary to the datasheet.
> >
> > SPD mode: This mode is used to power down the device when it is not in
> > use after power-up.
> > Previous register settings are maintained during and
> > following the removal of SPD.
> >
> > Suspend to Idle case, it is in SPD mode and the MMD register values
> > are retained.
> >
>
> On resume from s2idle, ksz9131_resume() calls ksz9131_config_rgmii_delay() which does MMD accesses,
> while the PHY is in SPD. According to the datasheet, it shouldn't happen. See commit e398822c4751
> ("net: phy: micrel: populate .soft_reset for KSZ9131") which fixes the same issue.
On my board, while s2idle in SPD mode, it does not hang. The datasheet does not explain
the behaviour when it is SPD mode. But it states that it retains all previous register values
when it is out of SPD mode.
>
> > But in Suspend to RAM, PHY loses power and the reset value of Power
> > Down bit 0 (ie normal mode), there is no restriction for accessing MMD
> > registers in this mode.
> >
>
> If the PHY loses power, it loses all the configuration that was done by ksz9131_config_init(). Right
> now, only the RGMII delays are restored, which is a subset of the configurations done by
> ksz9131_config_init().
I agree, Only RZ/G3E reported this issue and with configuring only delays, it worked.
Calling ksz9131_config_init() restores more MMD registers or call phy_init() like this patch.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: add bounds check for debugfs register access
From: Simon Horman @ 2026-04-03 13:36 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Paul Greenwalt
In-Reply-To: <20260327073046.134085-2-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:30:36AM +0100, Aleksandr Loktionov wrote:
> From: Paul Greenwalt <paul.greenwalt@intel.com>
>
> Prevent out-of-bounds MMIO accesses triggered through user-controlled
> register offsets. IXGBE_HFDR (0x15FE8) is the highest valid MMIO
> register in the ixgbe register map; any offset beyond it would address
> unmapped memory.
>
> Add a defense-in-depth check at two levels:
>
> 1. ixgbe_read_reg() -- the noinline register read accessor. A
> WARN_ON_ONCE() guard here catches any future code path (including
> ioctl extensions) that might inadvertently pass an out-of-range
> offset without relying on higher layers to catch it first.
> ixgbe_write_reg() is a static inline called from the TX/RX hot path;
> adding WARN_ON_ONCE there would inline the check at every call site,
> so only the read path gets this guard.
>
> 2. ixgbe_dbg_reg_ops_write() -- the debugfs 'reg_ops' interface is the
> only current path where a raw, user-supplied offset enters the driver.
> Gating it before invoking the register accessors provides a clean,
> user-visible failure (silent ignore with no kernel splat) for
> deliberately malformed debugfs writes.
>
> Add a reg <= IXGBE_HFDR guard to both the read and write paths in
> ixgbe_dbg_reg_ops_write(), and a WARN_ON_ONCE + early-return guard to
> ixgbe_read_reg().
>
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
This feels like a bug fix to me, assuming users can
cause out of range access using the debugfs 'reg_ops' interface,
If so I think it should have a Fixes tag and go via iwl-net.
...
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: clean up adaptive interrupt moderation algorithm
From: Simon Horman @ 2026-04-03 13:31 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-3-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:30:37AM +0100, Aleksandr Loktionov wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Improve the adaptive interrupt throttle (ITR) algorithm in several ways:
>
> - Lower IXGBE_ITR_ADAPTIVE_MAX_USECS from 126 to 84 us (12K interrupts/s
> minimum in bulk mode) to prevent RX starvation in full-blown bulk
> scenarios.
>
> - Add ixgbe_container_is_rx() helper to split the Rx vs Tx logic in
> ixgbe_update_itr(); Rx uses a latency-favouring path for small bursts
> (< 24 packets and < 12112 bytes), targeting 8x throughput growth per
> step.
>
> - Limit the ITR decrease in latency mode to at most 2 us per update so
> ACK workloads do not overdrive the moderation and starve TCP senders.
>
> - Add IXGBE_ITR_ADAPTIVE_MASK_USECS (= IXGBE_ITR_ADAPTIVE_LATENCY - 1
> = 0x7F) to mask out the mode flag bit 7 in ixgbe_set_itr(), replacing
> the open-coded ~IXGBE_ITR_ADAPTIVE_LATENCY.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
This patch is doing 4 things.
Please split it up.
...
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Carlo Szelinsky @ 2026-04-03 13:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: Kory Maincent, Oleksij Rempel, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel, Carlo Szelinsky
In-Reply-To: <61561526-1e8c-4d0c-a0ff-56da25ee6531@lunn.ch>
Hi Andrew,
Thx for helping me!
I thought of keeping the eager path so we still catch broken DT bindings
early at boot instead of silently failing later on first ethtool access.
But you're right, dropping it would simplify things quite a bit. Do you
think that trade-off is worth it? I will follow your lead.
cheers Carlo
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next] ixgbe: remove ixgbe_ping_all_vfs() from watchdog link-up handler
From: Simon Horman @ 2026-04-03 13:25 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: Simon Horman, intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-4-aleksandr.loktionov@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ixgbe: remove ixgbe_ping_all_vfs() from watchdog link-up handler
This patch removes the ixgbe_ping_all_vfs() call from
ixgbe_watchdog_link_is_up() to fix a race condition where VFs receive
CTS (Clear To Send) mailbox messages instead of expected RESET|ACK
responses during initialization.
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 0bc806aaed90..6996547a8084 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -8151,9 +8151,6 @@ static void ixgbe_watchdog_link_is_up(struct ixgbe_adapter *adapter)
>
> /* update the default user priority for VFs */
> ixgbe_update_default_up(adapter);
> -
> - /* ping all the active vfs to let them know link has changed */
> - ixgbe_ping_all_vfs(adapter);
> }
The patch removes ixgbe_ping_all_vfs() from ixgbe_watchdog_link_is_up()
to prevent the race condition during VF initialization. However, the
identical call remains in ixgbe_watchdog_link_is_down().
Doesn't the same race condition apply to link-down events?
When a VF initiates reset and the physical link state changes to down,
the watchdog would trigger:
VF side:
- Sends IXGBE_VF_RESET message
- Waits for RESET|ACK response
PF side:
- ixgbe_vf_reset_msg() processes reset, sets clear_to_send=true
- Link goes down, triggers watchdog
- ixgbe_watchdog_link_is_down() calls ixgbe_ping_all_vfs()
- Sends gratuitous ping with CTS bit
VF receives CTS message instead of expected RESET response, causing the
same initialization failure described in the commit message.
Looking at the unchanged code in ixgbe_watchdog_link_is_down():
e_info(drv, "NIC Link is Down\n");
netif_carrier_off(netdev);
/* ping all the active vfs to let them know link has changed */
ixgbe_ping_all_vfs(adapter);
The commit message states "Link-state changes are already communicated
to VFs through the normal mailbox protocol; the extra ping here is
redundant and races with VF initialization."
Does this reasoning apply equally to the link-down case?
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Ovidiu Panait @ 2026-04-03 13:22 UTC (permalink / raw)
To: Biju Das, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB11332623A3F7FF4601FE8C35C865EA@TYCPR01MB11332.jpnprd01.prod.outlook.com>
Hi,
>
> Hi Ovidiu Panait,
>
> Thanks for the patch.
>
> > -----Original Message-----
> > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > Sent: 03 April 2026 12:18
> > Subject: [PATCH net] net: phy: micrel: Fix MMD register access during
> SPD in ksz9131_resume()
> >
> > During system suspend, phy_suspend() puts the PHY into Software Power-
> Down
> > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to the
> KSZ9131 datasheet, MMD register
> > access is restricted during SPD:
> >
> > - Only access to the standard registers (0 through 31) is supported.
> > - Access to MMD address spaces other than MMD address space 1 is
> > possible if the spd_clock_gate_override bit is set.
> > - Access to MMD address space 1 is not possible.
> >
> > However, ksz9131_resume() calls ksz9131_config_rgmii_delay() before
> > kszphy_resume() clears BMCR_PDOWN. This means MMD registers are accessed
> while the PHY is still in SPD,
> > contrary to the datasheet.
>
> SPD mode: This mode is used to power down the device when it is not in use
> after power-up.
> Previous register settings are maintained during and following
> the removal of SPD.
>
> Suspend to Idle case, it is in SPD mode and the MMD register values are
> retained.
>
On resume from s2idle, ksz9131_resume() calls ksz9131_config_rgmii_delay()
which does MMD accesses, while the PHY is in SPD. According to the datasheet,
it shouldn't happen. See commit e398822c4751 ("net: phy: micrel: populate
.soft_reset for KSZ9131") which fixes the same issue.
> But in Suspend to RAM, PHY loses power and the reset value of Power Down
> bit 0 (ie normal mode),
> there is no restriction for accessing MMD registers in this mode.
>
If the PHY loses power, it loses all the configuration that was done by
ksz9131_config_init(). Right now, only the RGMII delays are restored, which
is a subset of the configurations done by ksz9131_config_init().
Calling phy_init_hw() fixes both of these issues.
Ovidiu
> Am I missing anything here??
>
>
> Cheers,
> Biju
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next] ixgbe: replace GFP_ATOMIC with GFP_KERNEL in ixgbe_fcoe_ddp_setup()
From: Simon Horman @ 2026-04-03 13:21 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: Simon Horman, intel-wired-lan, netdev, anthony.l.nguyen
In-Reply-To: <20260327073046.134085-7-aleksandr.loktionov@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ixgbe: replace GFP_ATOMIC with GFP_KERNEL in ixgbe_fcoe_ddp_setup()
This commit changes the memory allocation flag in ixgbe_fcoe_ddp_setup()
from GFP_ATOMIC to GFP_KERNEL based on the claim that the function is
never called from atomic context.
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> index 011fda9c6193..7fa0971073e5 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> @@ -193,7 +193,7 @@ static int ixgbe_fcoe_ddp_setup(struct net_device *netdev, u16 xid,
> }
>
> /* alloc the udl from per cpu ddp pool */
> - ddp->udl = dma_pool_alloc(ddp_pool->pool, GFP_ATOMIC, &ddp->udp);
> + ddp->udl = dma_pool_alloc(ddp_pool->pool, GFP_KERNEL, &ddp->udp);
^^^^^^^^^^
Doesn't this allocation happen in atomic context? Looking at the function,
get_cpu() is called earlier:
ixgbe_fcoe_ddp_setup() {
...
ddp_pool = per_cpu_ptr(fcoe->ddp_pool, get_cpu());
...
ddp->udl = dma_pool_alloc(ddp_pool->pool, GFP_KERNEL, &ddp->udp);
...
put_cpu();
}
get_cpu() disables preemption, which means GFP_KERNEL allocations (which
can sleep during direct reclaim) would trigger a BUG() when attempted with
preemption disabled.
The commit message claims the function is "never from an atomic context",
but while the callers may be in process context, the function itself creates
atomic context via get_cpu().
> if (!ddp->udl) {
> e_err(drv, "failed allocated ddp context\n");
> goto out_noddp_unmap;
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: fix ITR value overflow in adaptive interrupt throttling
From: Simon Horman @ 2026-04-03 13:18 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-11-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:30:45AM +0100, Aleksandr Loktionov wrote:
> ixgbe_update_itr() packs a mode flag (IXGBE_ITR_ADAPTIVE_LATENCY, bit 7)
> and a usecs delay (bits [6:0]) into an unsigned int, then stores it in
> ring_container->itr which is u8. Values above 0xFF wrap, corrupting both
> the delay and the mode-flag on the next readback.
>
> Separate the mode bits from the usecs sub-field; clamp only the latter to
> [0, IXGBE_ITR_ADAPTIVE_LATENCY - 1] via min_t(unsigned int, ...) so
> overflow cannot bleed into bit 7. Add a WARN_ONCE() when the raw usecs
> value exceeds U8_MAX so out-of-range ITR computations are visible in
> dmesg during development and testing.
>
> Fixes: b4ded8327fea ("ixgbe: Update adaptive ITR algorithm")
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Somehow - perhaps because there is no m/n notation present in the [] in the
subject - Patchwork has treated each patch in this series as it's own
patch-set.
And in the case of this patch, it didn't apply - I assume
because in order to do so an earlier patch in the series
needs to be present.
So CI didn't run on this patch :(
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: use ktime_get_real_ns() in ixgbe_ptp_reset()
From: Simon Horman @ 2026-04-03 13:11 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller,
Marcin Szycik
In-Reply-To: <20260403131035.GA113102@horms.kernel.org>
On Fri, Apr 03, 2026 at 02:10:38PM +0100, Simon Horman wrote:
> On Fri, Mar 27, 2026 at 08:30:39AM +0100, Aleksandr Loktionov wrote:
> > From: Jacob Keller <jacob.e.keller@intel.com>
> >
> > Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
> > ktime_get_real_ns() in ixgbe_ptp_reset(). Using the combined helper
> > avoids the unnecessary intermediate ktime_t variable and makes the
> > intent clearer.
> >
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> FWIIW, this pattern also seems to exist in e1000e, ixgbe and igb (twice).
Of course, with this patch applied it's not present in ixgbe anymore :^)
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: use ktime_get_real_ns() in ixgbe_ptp_reset()
From: Simon Horman @ 2026-04-03 13:10 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller,
Marcin Szycik
In-Reply-To: <20260327073046.134085-5-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:30:39AM +0100, Aleksandr Loktionov wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
> ktime_get_real_ns() in ixgbe_ptp_reset(). Using the combined helper
> avoids the unnecessary intermediate ktime_t variable and makes the
> intent clearer.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
FWIIW, this pattern also seems to exist in e1000e, ixgbe and igb (twice).
^ permalink raw reply
* [PATCH net v1] net: mptcp: fix slab-use-after-free in __inet_lookup_established
From: Jiayuan Chen @ 2026-04-03 13:07 UTC (permalink / raw)
To: mptcp, netdev
Cc: Jiayuan Chen, Matthieu Baerts, Mat Martineau, Geliang Tang,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-kernel
The ehash table lookups are lockless and rely on
SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability
during RCU read-side critical sections. Both tcp_prot and
tcpv6_prot have their slab caches created with this flag
via proto_register().
However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into
tcpv6_prot_override during inet_init() (fs_initcall, level 5),
before inet6_init() (module_init/device_initcall, level 6) has
called proto_register(&tcpv6_prot). At that point,
tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab
remains NULL permanently.
This causes MPTCP v6 subflow child sockets to be allocated via
kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab
cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so
when these sockets are freed without SOCK_RCU_FREE (which is
cleared for child sockets by design), the memory can be
immediately reused. Concurrent ehash lookups under
rcu_read_lock can then access freed memory, triggering a
slab-use-after-free in __inet_lookup_established.
Fix this by splitting the IPv6-specific initialization out of
mptcp_subflow_init() into a new mptcp_subflow_v6_init(), which
is called from mptcpv6_init() after proto_register(&tcpv6_prot)
has completed. This ensures tcpv6_prot_override.slab correctly
inherits the SLAB_TYPESAFE_BY_RCU slab cache.
Fixes: b19bc2945b40 ("mptcp: implement delegated actions")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
net/mptcp/ctrl.c | 6 +++++-
net/mptcp/protocol.h | 1 +
net/mptcp/subflow.c | 15 +++++++++------
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c
index d96130e49942..5887ddcdb875 100644
--- a/net/mptcp/ctrl.c
+++ b/net/mptcp/ctrl.c
@@ -583,7 +583,11 @@ int __init mptcpv6_init(void)
int err;
err = mptcp_proto_v6_init();
+ if (err)
+ return err;
- return err;
+ mptcp_subflow_v6_init();
+
+ return 0;
}
#endif
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 0bd1ee860316..ec15e503da8b 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -875,6 +875,7 @@ static inline void mptcp_subflow_tcp_fallback(struct sock *sk,
void __init mptcp_proto_init(void);
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
int __init mptcp_proto_v6_init(void);
+void __init mptcp_subflow_v6_init(void);
#endif
struct sock *mptcp_sk_clone_init(const struct sock *sk,
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 6716970693e9..4ff5863aa9fd 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -2165,7 +2165,15 @@ void __init mptcp_subflow_init(void)
tcp_prot_override.psock_update_sk_prot = NULL;
#endif
+ mptcp_diag_subflow_init(&subflow_ulp_ops);
+
+ if (tcp_register_ulp(&subflow_ulp_ops) != 0)
+ panic("MPTCP: failed to register subflows to ULP\n");
+}
+
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
+void __init mptcp_subflow_v6_init(void)
+{
/* In struct mptcp_subflow_request_sock, we assume the TCP request sock
* structures for v4 and v6 have the same size. It should not changed in
* the future but better to make sure to be warned if it is no longer
@@ -2204,10 +2212,5 @@ void __init mptcp_subflow_init(void)
/* Disable sockmap processing for subflows */
tcpv6_prot_override.psock_update_sk_prot = NULL;
#endif
-#endif
-
- mptcp_diag_subflow_init(&subflow_ulp_ops);
-
- if (tcp_register_ulp(&subflow_ulp_ops) != 0)
- panic("MPTCP: failed to register subflows to ULP\n");
}
+#endif
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] ice: stop DCBNL requests during driver unload
From: Simon Horman @ 2026-04-03 13:06 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Dave Ertman
In-Reply-To: <20260327072332.130320-8-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:23:31AM +0100, Aleksandr Loktionov wrote:
> From: Dave Ertman <david.m.ertman@intel.com>
>
> With a chatty lldpad, DCB configuration requests can arrive through
> the DCBNL API while the driver is tearing down PF resources, leading
> to use-after-free and NULL dereference crashes.
>
> Set ICE_SHUTTING_DOWN in pf->state at the start of ice_remove() and
> check this bit at the beginning of every DCBNL callback that accesses
> resources freed during the remove path.
>
> Fixes: b94b013eb626 ("ice: Implement DCBNL support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
> @@ -308,6 +326,8 @@ ice_dcbnl_get_pfc_cfg(struct net_device *netdev, int prio, u8 *setting)
> struct ice_pf *pf = ice_netdev_to_pf(netdev);
> struct ice_port_info *pi = pf->hw.port_info;
>
> + if (test_bit(ICE_SHUTTING_DOWN, pf->state))
> + return;
> if ((pf->dcbx_cap & DCB_CAP_DCBX_LLD_MANAGED) ||
> !(pf->dcbx_cap & DCB_CAP_DCBX_VER_CEE))
> return;
I think this problem predates this patch. But AI review warns
that callers pass an setting without initialising the data it points to,
and expect it to be initialised on return. But that doesn't happen
if the function exits early.
It suggests that callers should initialise *setting, and the AI generated
review states this is the case for other callbacks. (I did not check this
claim.)
It seems to me this is not strictly an ICE problem, although a quick
scan showed up a mix of driver that ensure that the setting parameter
is always initialised before return, and those that don't.
I think this problem is orthogonal to this patch, but seems to want
fixing.
...
^ permalink raw reply
* RE: commit 0c4f1c02d27a880b cause a deadlock issue
From: Korenblit, Miriam Rachel @ 2026-04-03 13:00 UTC (permalink / raw)
To: Greg KH
Cc: He, Guocai (CN), Thorsten Leemhuis, Berg, Johannes, Friend,
Linux kernel regressions list
In-Reply-To: <2026040349-chowtime-freeload-5ca4@gregkh>
> -----Original Message-----
> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Friday, April 3, 2026 3:49 PM
> To: Korenblit, Miriam Rachel <miriam.rachel.korenblit@intel.com>
> Cc: He, Guocai (CN) <Guocai.He.CN@windriver.com>; Thorsten Leemhuis
> <regressions@leemhuis.info>; Berg, Johannes <johannes.berg@intel.com>;
> Friend <netdev@vger.kernel.org>; Linux kernel regressions list
> <regressions@lists.linux.dev>
> Subject: Re: commit 0c4f1c02d27a880b cause a deadlock issue
>
> On Fri, Apr 03, 2026 at 12:44:48PM +0000, Korenblit, Miriam Rachel wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH <gregkh@linuxfoundation.org>
> > > Sent: Friday, April 3, 2026 2:27 PM
> > > To: He, Guocai (CN) <Guocai.He.CN@windriver.com>
> > > Cc: Thorsten Leemhuis <regressions@leemhuis.info>; Korenblit, Miriam
> > > Rachel <miriam.rachel.korenblit@intel.com>; Berg, Johannes
> > > <johannes.berg@intel.com>; Friend <netdev@vger.kernel.org>; Linux
> > > kernel regressions list <regressions@lists.linux.dev>
> > > Subject: Re: commit 0c4f1c02d27a880b cause a deadlock issue
> > >
> > > On Fri, Apr 03, 2026 at 11:08:46AM +0000, He, Guocai (CN) wrote:
> > > > No, The mainline have no this issue.
> > > > The changes of 0c4f1c02d27a880b is not in mainline.
> > >
> > > That does not make sense, that commit is really commit e1696c8bd005
> > > ("wifi: cfg80211: stop NAN and P2P in cfg80211_leave") which is in
> > > all of the following releases:
> > > 5.10.252 5.15.202 6.1.165 6.6.128 6.12.75 6.18.14 6.19.4 7.0-rc1
> > >
> > > confused,
> >
> > The change is indeed in mainline, but the locking situation in
> > mainline is totally different (that mutex does not even exist there)
> > Therefore, the issue is not supposed to happen in mainline.
>
> Ok, does that commit now need to be reverted from some of the stable branches?
> If so, which ones?
From every version which is < 6.7.
Miri
^ permalink raw reply
* Re: [PATCH net] ice: use READ_ONCE() to access cached PHC time
From: Simon Horman @ 2026-04-03 12:55 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Sergey Temerkhanov
In-Reply-To: <20260327072332.130320-9-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:23:32AM +0100, Aleksandr Loktionov wrote:
> From: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
>
> ptp.cached_phc_time is a 64-bit value updated by a periodic work item
> on one CPU and read locklessly on another. On 32-bit or non-atomic
> architectures this can result in a torn read. Use READ_ONCE() to
> enforce a single atomic load.
>
> Fixes: 77a781155a65 ("ice: enable receive hardware timestamping")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: increase SWFW semaphore timeout for X550 FW updates
From: Simon Horman @ 2026-04-03 12:49 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-1-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:30:35AM +0100, Aleksandr Loktionov wrote:
> From: Soumen Karmakar <soumen.karmakar@intel.com>
>
> According to FW documentation, the most time-consuming part of continuous
> FW activity is Shadow RAM (SR) dump which takes up to 3.2 seconds. For
> X550 devices, the module-update FW command can take over 4.5 s. Increase
> the max Software/Firmware (SW/FW) semaphore wait time from the default
> 200 ms to 5 s for X550 to avoid spurious semaphore timeout failures
Should 200ms be 1s (200 x 5us) ?
> during FW update operations.
>
> Signed-off-by: Soumen Karmakar <soumen.karmakar@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
> index e67e2fe..85047ef 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
> @@ -577,6 +577,9 @@ int ixgbe_acquire_swfw_sync_X540(struct ixgbe_hw *hw, u32 mask)
>
> swmask |= swi2c_mask;
> fwmask |= swi2c_mask << 2;
> + if (hw->mac.type == ixgbe_mac_X550)
> + timeout = 1000;
I think it would be nice to centralise the initialisation of timeout,
to either it's default or device-specific value, here.
And to provide a comment indicating what the values mean in terms
of maximum delay in s or ms.
> +
> for (i = 0; i < timeout; i++) {
> /* SW NVM semaphore bit is used for access to all
> * SW_FW_SYNC bits (not just NVM)
> --
> 2.52.0
>
^ permalink raw reply
* Re: commit 0c4f1c02d27a880b cause a deadlock issue
From: Greg KH @ 2026-04-03 12:49 UTC (permalink / raw)
To: Korenblit, Miriam Rachel
Cc: He, Guocai (CN), Thorsten Leemhuis, Berg, Johannes, Friend,
Linux kernel regressions list
In-Reply-To: <DM3PPF63A6024A9C09C1B13E5DF46C0B72AA35EA@DM3PPF63A6024A9.namprd11.prod.outlook.com>
On Fri, Apr 03, 2026 at 12:44:48PM +0000, Korenblit, Miriam Rachel wrote:
>
>
> > -----Original Message-----
> > From: Greg KH <gregkh@linuxfoundation.org>
> > Sent: Friday, April 3, 2026 2:27 PM
> > To: He, Guocai (CN) <Guocai.He.CN@windriver.com>
> > Cc: Thorsten Leemhuis <regressions@leemhuis.info>; Korenblit, Miriam Rachel
> > <miriam.rachel.korenblit@intel.com>; Berg, Johannes
> > <johannes.berg@intel.com>; Friend <netdev@vger.kernel.org>; Linux kernel
> > regressions list <regressions@lists.linux.dev>
> > Subject: Re: commit 0c4f1c02d27a880b cause a deadlock issue
> >
> > On Fri, Apr 03, 2026 at 11:08:46AM +0000, He, Guocai (CN) wrote:
> > > No, The mainline have no this issue.
> > > The changes of 0c4f1c02d27a880b is not in mainline.
> >
> > That does not make sense, that commit is really commit e1696c8bd005
> > ("wifi: cfg80211: stop NAN and P2P in cfg80211_leave") which is in all of the
> > following releases:
> > 5.10.252 5.15.202 6.1.165 6.6.128 6.12.75 6.18.14 6.19.4 7.0-rc1
> >
> > confused,
>
> The change is indeed in mainline, but the locking situation in mainline is totally different
> (that mutex does not even exist there)
> Therefore, the issue is not supposed to happen in mainline.
Ok, does that commit now need to be reverted from some of the stable
branches? If so, which ones?
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Biju Das @ 2026-04-03 12:47 UTC (permalink / raw)
To: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Ovidiu Panait
In-Reply-To: <20260403111738.37749-1-ovidiu.panait.rb@renesas.com>
Hi Ovidiu Panait,
Thanks for the patch.
> -----Original Message-----
> From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> Sent: 03 April 2026 12:18
> Subject: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
>
> During system suspend, phy_suspend() puts the PHY into Software Power-Down
> (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to the KSZ9131 datasheet, MMD register
> access is restricted during SPD:
>
> - Only access to the standard registers (0 through 31) is supported.
> - Access to MMD address spaces other than MMD address space 1 is
> possible if the spd_clock_gate_override bit is set.
> - Access to MMD address space 1 is not possible.
>
> However, ksz9131_resume() calls ksz9131_config_rgmii_delay() before
> kszphy_resume() clears BMCR_PDOWN. This means MMD registers are accessed while the PHY is still in SPD,
> contrary to the datasheet.
SPD mode: This mode is used to power down the device when it is not in use after power-up.
Previous register settings are maintained during and following the removal of SPD.
Suspend to Idle case, it is in SPD mode and the MMD register values are retained.
But in Suspend to RAM, PHY loses power and the reset value of Power Down bit 0 (ie normal mode),
there is no restriction for accessing MMD registers in this mode.
Am I missing anything here??
Cheers,
Biju
^ permalink raw reply
* RE: commit 0c4f1c02d27a880b cause a deadlock issue
From: Korenblit, Miriam Rachel @ 2026-04-03 12:44 UTC (permalink / raw)
To: Greg KH, He, Guocai (CN)
Cc: Thorsten Leemhuis, Berg, Johannes, Friend,
Linux kernel regressions list
In-Reply-To: <2026040331-evasion-walk-f572@gregkh>
> -----Original Message-----
> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Friday, April 3, 2026 2:27 PM
> To: He, Guocai (CN) <Guocai.He.CN@windriver.com>
> Cc: Thorsten Leemhuis <regressions@leemhuis.info>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; Berg, Johannes
> <johannes.berg@intel.com>; Friend <netdev@vger.kernel.org>; Linux kernel
> regressions list <regressions@lists.linux.dev>
> Subject: Re: commit 0c4f1c02d27a880b cause a deadlock issue
>
> On Fri, Apr 03, 2026 at 11:08:46AM +0000, He, Guocai (CN) wrote:
> > No, The mainline have no this issue.
> > The changes of 0c4f1c02d27a880b is not in mainline.
>
> That does not make sense, that commit is really commit e1696c8bd005
> ("wifi: cfg80211: stop NAN and P2P in cfg80211_leave") which is in all of the
> following releases:
> 5.10.252 5.15.202 6.1.165 6.6.128 6.12.75 6.18.14 6.19.4 7.0-rc1
>
> confused,
The change is indeed in mainline, but the locking situation in mainline is totally different
(that mutex does not even exist there)
Therefore, the issue is not supposed to happen in mainline.
>
> greg k-h
^ permalink raw reply
* Re: [PATCH iwl-next] ice: call netif_keep_dst() once when entering switchdev mode
From: Simon Horman @ 2026-04-03 12:41 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Marcin Szycik
In-Reply-To: <20260327072236.129802-5-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:22:36AM +0100, Aleksandr Loktionov wrote:
> From: Marcin Szycik <marcin.szycik@intel.com>
>
> netif_keep_dst() only needs to be called once for the uplink VSI, not
> once for each port representor. Move it from ice_eswitch_setup_repr()
> to ice_eswitch_enable_switchdev().
>
> Fixes: defd52455aee ("ice: do Tx through PF netdev in slow-path")
This problem seems to predate the cited commit.
> Signed-off-by: Marcin Szycik <marcin.szycik@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* [PATCH net-next] net: hsr: emit notification for PRP slave2 changed hw addr on port deletion
From: Fernando Fernandez Mancera @ 2026-04-03 12:39 UTC (permalink / raw)
To: netdev
Cc: acsjakub, liuhangbin, kees, horms, pabeni, kuba, edumazet, davem,
fmaurer, Fernando Fernandez Mancera, Luka Gejak
On PRP protocol, when deleting the port the MAC address change
notification was missing. In addition to that, make sure to only perform
the MAC address change on slave2 deletion and PRP protocol as the
operation isn't necessary for HSR nor slave1.
Note that the eth_hw_addr_set() is correct on PRP context as the slaves
are either in promiscuous mode or forward offload enabled.
Fixes: b65999e7238e ("net: hsr: sync hw addr of slave2 according to slave1 hw addr on PRP")
Reported-by: Luka Gejak <luka.gejak@linux.dev>
Closes: https://lore.kernel.org/netdev/DHFCZEM93FTT.1RWFBIE32K7OT@linux.dev/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
Note: routed through net-next tree as the next net tree as rc6 batch is
already out and I do not think this is worth to be included in a last
call batch. Anyway, if maintainer thinks it is, feel free to apply it to
net tree.
---
net/hsr/hsr_slave.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c
index 44f83c8c56a7..d9af9e65f72f 100644
--- a/net/hsr/hsr_slave.c
+++ b/net/hsr/hsr_slave.c
@@ -243,7 +243,11 @@ void hsr_del_port(struct hsr_port *port)
if (!port->hsr->fwd_offloaded)
dev_set_promiscuity(port->dev, -1);
netdev_upper_dev_unlink(port->dev, master->dev);
- eth_hw_addr_set(port->dev, port->original_macaddress);
+ if (hsr->prot_version == PRP_V1 &&
+ port->type == HSR_PT_SLAVE_B) {
+ eth_hw_addr_set(port->dev, port->original_macaddress);
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, port->dev);
+ }
}
kfree_rcu(port, rcu);
--
2.53.0
^ permalink raw reply related
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