* [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Ovidiu Panait @ 2026-04-09 9:56 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni,
biju.das.jz
Cc: netdev, linux-kernel, linux-renesas-soc, Ovidiu Panait
In-Reply-To: <20260409095633.70973-1-ovidiu.panait.rb@renesas.com>
ksz9131_resume() was added to restore RGMII delays on resume for platforms
where the PHY loses power during suspend to RAM. However, for s2idle, the
PHY stays in Software Power-Down (SPD) during resume. In that case,
ksz9131_config_rgmii_delay() accesses MMD registers before kszphy_resume()
clears BMCR_PDOWN. The KSZ9131 datasheet states that during SPD, access to
the MMD registers is restricted:
- 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.
Additionally, only RGMII delays were restored, while other settings
from ksz9131_config_init() were not.
Now that the preceding commit ("net: phylink: call phy_init_hw() in
phylink resume path") performs a phy_init_hw() during phylink resume,
ksz9131_resume() is no longer needed.
Remove it and use kszphy_resume() directly.
Fixes: f25a7eaa897f ("net: phy: micrel: Add ksz9131_resume()")
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
---
drivers/net/phy/micrel.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 2aa1dedd21b8..f2513109865a 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -6014,14 +6014,6 @@ static int lan8841_suspend(struct phy_device *phydev)
return kszphy_generic_suspend(phydev);
}
-static int ksz9131_resume(struct phy_device *phydev)
-{
- if (phydev->suspended && phy_interface_is_rgmii(phydev))
- ksz9131_config_rgmii_delay(phydev);
-
- return kszphy_resume(phydev);
-}
-
#define LAN8842_PTP_GPIO_NUM 16
static int lan8842_ptp_probe_once(struct phy_device *phydev)
@@ -6929,7 +6921,7 @@ static struct phy_driver ksphy_driver[] = {
.get_strings = kszphy_get_strings,
.get_stats = kszphy_get_stats,
.suspend = kszphy_suspend,
- .resume = ksz9131_resume,
+ .resume = kszphy_resume,
.cable_test_start = ksz9x31_cable_test_start,
.cable_test_get_status = ksz9x31_cable_test_get_status,
.get_features = ksz9477_get_features,
--
2.34.1
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH iwl-net v2] iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2
From: Romanowski, Rafal @ 2026-04-09 10:02 UTC (permalink / raw)
To: Keller, Jacob E, Oros, Petr, netdev@vger.kernel.org
Cc: Paul Menzel, Kitszel, Przemyslaw, Eric Dumazet,
linux-kernel@vger.kernel.org, Loktionov, Aleksandr, Andrew Lunn,
Nguyen, Anthony L, Mateusz Polchlopek, Jakub Kicinski,
Paolo Abeni, David S. Miller, intel-wired-lan@lists.osuosl.org
In-Reply-To: <734bbc85-2209-4b6c-913e-e3637532e315@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Jacob
> Keller
> Sent: Tuesday, March 24, 2026 12:07 AM
> To: Oros, Petr <poros@redhat.com>; netdev@vger.kernel.org
> Cc: Paul Menzel <pmenzel@molgen.mpg.de>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Eric Dumazet <edumazet@google.com>; linux-
> kernel@vger.kernel.org; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>;
> Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Mateusz Polchlopek
> <mateusz.polchlopek@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; intel-
> wired-lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] iavf: fix wrong VLAN mask for
> legacy Rx descriptors L2TAG2
>
> On 3/23/2026 3:15 AM, Petr Oros wrote:
> > The reproducer requires legacy Rx descriptors. On modern ice + iavf
> > with full PTP support, flex descriptors are always negotiated and the
> > buggy legacy path is never reached. Flex descriptors require all of:
> > - CONFIG_PTP_1588_CLOCK enabled
> > - VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC granted by PF
> > - PTP capabilities negotiated (VIRTCHNL_VF_CAP_PTP)
> > - VIRTCHNL_1588_PTP_CAP_RX_TSTAMP supported
> > - VIRTCHNL_RXDID_2_FLEX_SQ_NIC present in DDP profile
> >
> > If any condition is not met, iavf_select_rx_desc_format() falls back
> > to legacy descriptors (RXDID=1) and the wrong L2TAG2 mask is hit.
> >
>
> > Fixes: 2dc8e7c36d80 ("iavf: refactor iavf_clean_rx_irq to support
> > legacy and flex descriptors")
>
> Sure enough, this commit changed the legacy version to:
> +/* Stripped S-TAG VLAN from the receive packet */
> +#define IAVF_RXD_LEGACY_L2TAG2_M GENMASK_ULL(63, 32)
>
> I guess since we basically always negotiated flexible descriptors after this that we
> never caught it.
>
> Thanks for the fix.
>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
>
> Regards,
> Jake
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH RFC iwl-next 1/4] iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
From: Romanowski, Rafal @ 2026-04-09 10:10 UTC (permalink / raw)
To: Loktionov, Aleksandr, Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Eric Dumazet, linux-kernel@vger.kernel.org,
Andrew Lunn, Nguyen, Anthony L, intel-wired-lan@lists.osuosl.org,
Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <IA3PR11MB89861519B35EE57D5D03969DE540A@IA3PR11MB8986.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Loktionov, Aleksandr
> Sent: Monday, March 16, 2026 12:35 PM
> To: Oros, Petr <poros@redhat.com>; netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: Re: [Intel-wired-lan] [PATCH RFC iwl-next 1/4] iavf: rename
> IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Petr Oros
> > Sent: Monday, March 2, 2026 12:40 PM
> > To: netdev@vger.kernel.org
> > Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> > <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> > <andrew+netdev@lunn.ch>; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; intel-wired-lan@lists.osuosl.org;
> > Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski
> > <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller
> > <davem@davemloft.net>
> > Subject: [Intel-wired-lan] [PATCH RFC iwl-next 1/4] iavf: rename
> > IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
> >
> > Rename the IAVF_VLAN_IS_NEW state to IAVF_VLAN_ADDING to better
> > describe what the state represents: an ADD request has been sent to
> > the PF and is waiting for a response.
> >
> > This is a pure rename with no behavioral change, preparing for a
> > cleanup of the VLAN filter state machine.
> >
> > Signed-off-by: Petr Oros <poros@redhat.com>
> > ---
> > drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
> > drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 8 ++++----
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> > b/drivers/net/ethernet/intel/iavf/iavf.h
> > index a87e0c6d4017ad..8e6db72828ae14 100644
> > --- a/drivers/net/ethernet/intel/iavf/iavf.h
> > +++ b/drivers/net/ethernet/intel/iavf/iavf.h
> > @@ -158,7 +158,7 @@ struct iavf_vlan { enum iavf_vlan_state_t {
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next 2/4] iavf: stop removing VLAN filters from PF on interface down
From: Romanowski, Rafal @ 2026-04-09 10:10 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Eric Dumazet, linux-kernel@vger.kernel.org,
Andrew Lunn, Nguyen, Anthony L, intel-wired-lan@lists.osuosl.org,
Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <20260316104209.1285962-3-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr
> Oros
> Sent: Monday, March 16, 2026 11:42 AM
> To: netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH iwl-next 2/4] iavf: stop removing VLAN filters
> from PF on interface down
>
> When a VF goes down, the driver currently sends DEL_VLAN to the PF for every
> VLAN filter (ACTIVE -> DISABLE -> send DEL -> INACTIVE), then re-adds them all
> on UP (INACTIVE -> ADD -> send ADD -> ADDING -> ACTIVE). This round-trip is
> unnecessary because:
>
> 1. The PF disables the VF's queues via VIRTCHNL_OP_DISABLE_QUEUES,
> which already prevents all RX/TX traffic regardless of VLAN filter
> state.
>
> 2. The VLAN filters remaining in PF HW while the VF is down is
> harmless - packets matching those filters have nowhere to go with
> queues disabled.
>
> 3. The DEL+ADD cycle during down/up creates race windows where the
> VLAN filter list is incomplete. With spoofcheck enabled, the PF
> enables TX VLAN filtering on the first non-zero VLAN add, blocking
> traffic for any VLANs not yet re-added.
>
> Remove the entire DISABLE/INACTIVE state machinery:
> - Remove IAVF_VLAN_DISABLE and IAVF_VLAN_INACTIVE enum values
> - Remove iavf_restore_filters() and its call from iavf_open()
> - Remove VLAN filter handling from iavf_clear_mac_vlan_filters(),
> rename it to iavf_clear_mac_filters()
> - Remove DEL_VLAN_FILTER scheduling from iavf_down()
> - Remove all DISABLE/INACTIVE handling from iavf_del_vlans()
>
> VLAN filters now stay ACTIVE across down/up cycles. Only explicit user removal
> (ndo_vlan_rx_kill_vid) or PF/VF reset triggers VLAN filter deletion/re-addition.
>
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf.h | 6 +--
> drivers/net/ethernet/intel/iavf/iavf_main.c | 39 ++-----------------
> .../net/ethernet/intel/iavf/iavf_virtchnl.c | 33 +++-------------
> 3 files changed, 12 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> b/drivers/net/ethernet/intel/iavf/iavf.h
> index 8e6db72828ae14..1ad00690622c8e 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf.h
> @@ -159,10 +159,8 @@ enum iavf_vlan_state_t {
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* Re: [TEST] nft_tproxy_udp.sh flaky after Fedora 44 upgrade
From: Florian Westphal @ 2026-04-09 10:11 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev@vger.kernel.org
In-Reply-To: <20260408152432.24b8ad0d@kernel.org>
Jakub Kicinski <kuba@kernel.org> wrote:
> When you have a sec -- we upgraded the NIPA systems to Fedora 44
> over the weekend, and nft_tproxy_udp.sh has gotten quite flaky:
> https://netdev.bots.linux.dev/contest.html?test=nft-tproxy-udp-sh
>
> One thing that we hit immediately is this, in case tproxy test
> uses socat:
>
> commit e65d8b6f3092398efd7c74e722cb7a516d9a0d6d
> Date: Sat Apr 4 16:01:03 2026 -0700
>
> selftests: drv-net: adjust to socat changes
>
> socat v1.8.1.0 now defaults to shut-null, it sends an extra
> 0-length UDP packet when sender disconnects. This breaks
> our tests which expect the exact packet sequence.
>
> Add shut-none which was the old default where necessary.
Thanks for the pointer, I will try to get to this later today.
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next 3/4] iavf: wait for PF confirmation before removing VLAN filters
From: Romanowski, Rafal @ 2026-04-09 10:11 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Eric Dumazet, linux-kernel@vger.kernel.org,
Andrew Lunn, Nguyen, Anthony L, intel-wired-lan@lists.osuosl.org,
Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <20260316104209.1285962-4-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr
> Oros
> Sent: Monday, March 16, 2026 11:42 AM
> To: netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH iwl-next 3/4] iavf: wait for PF confirmation
> before removing VLAN filters
>
> The VLAN filter DELETE path was asymmetric with the ADD path: ADD waits for
> PF confirmation (ADD -> ADDING -> ACTIVE), but DELETE immediately frees the
> filter struct after sending the DEL message without waiting for the PF response.
>
> This is problematic because:
> - If the PF rejects the DEL, the filter remains in HW but the driver
> has already freed the tracking structure, losing sync.
> - Race conditions between DEL pending and other operations
> (add, reset) cannot be properly resolved if the filter struct
> is already gone.
>
> Add IAVF_VLAN_REMOVING state to make the DELETE path symmetric:
>
> REMOVE -> REMOVING (send DEL) -> PF confirms -> kfree
> -> PF rejects -> ACTIVE
>
> In iavf_del_vlans(), transition filters from REMOVE to REMOVING instead of
> immediately freeing them. The new DEL completion handler in
> iavf_virtchnl_completion() frees filters on success or reverts them to ACTIVE on
> error.
>
> Update iavf_add_vlan() to handle the REMOVING state: if a DEL is pending and
> the user re-adds the same VLAN, queue it for ADD so it gets re-programmed after
> the PF processes the DEL.
>
> The !VLAN_FILTERING_ALLOWED early-exit path still frees filters directly since no
> PF message is sent in that case.
>
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf.h | 1 +
> drivers/net/ethernet/intel/iavf/iavf_main.c | 9 +++--
> .../net/ethernet/intel/iavf/iavf_virtchnl.c | 37 +++++++++++++------
> 3 files changed, 32 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> b/drivers/net/ethernet/intel/iavf/iavf.h
> index 1ad00690622c8e..f9ad814d18b1da 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf.h
> @@ -161,6 +161,7 @@ enum iavf_vlan_state_t {
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* [PATCH net-next] tcp: return a drop_reason from tcp_add_backlog()
From: Eric Dumazet @ 2026-04-09 10:11 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Neal Cardwell, Kuniyuki Iwashima, netdev,
eric.dumazet, Eric Dumazet
Part of a stack canary removal from tcp_v{4,6}_rcv().
Return a drop_reason instead of a boolean, so that we no longer
have to pass the address of a local variable.
$ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-37 (-37)
Function old new delta
tcp_v6_rcv 3133 3129 -4
tcp_v4_rcv 3206 3202 -4
tcp_add_backlog 1281 1252 -29
Total: Before=25567186, After=25567149, chg -0.00%
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/tcp.h | 3 +--
net/ipv4/tcp_ipv4.c | 21 +++++++++------------
net/ipv6/tcp_ipv6.c | 3 ++-
3 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 6156d1d068e142f696ec9dfff63e3aaebb0171bc..fce4b653c23ec790f561d577fcd6160d3d92e3c0 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1680,8 +1680,7 @@ static inline bool tcp_checksum_complete(struct sk_buff *skb)
__skb_checksum_complete(skb);
}
-bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
- enum skb_drop_reason *reason);
+enum skb_drop_reason tcp_add_backlog(struct sock *sk, struct sk_buff *skb);
static inline int tcp_filter(struct sock *sk, struct sk_buff *skb,
enum skb_drop_reason *reason)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 69ab236072e7142d5ca9d0703d99f02c1e17c738..c9bbbf32364827d341b4c1fd77617031b0739c50 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1900,8 +1900,7 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
}
EXPORT_SYMBOL(tcp_v4_do_rcv);
-bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
- enum skb_drop_reason *reason)
+enum skb_drop_reason tcp_add_backlog(struct sock *sk, struct sk_buff *skb)
{
u32 tail_gso_size, tail_gso_segs;
struct skb_shared_info *shinfo;
@@ -1929,10 +1928,9 @@ bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
if (unlikely(tcp_checksum_complete(skb))) {
bh_unlock_sock(sk);
trace_tcp_bad_csum(skb);
- *reason = SKB_DROP_REASON_TCP_CSUM;
__TCP_INC_STATS(sock_net(sk), TCP_MIB_CSUMERRORS);
__TCP_INC_STATS(sock_net(sk), TCP_MIB_INERRS);
- return true;
+ return SKB_DROP_REASON_TCP_CSUM;
}
/* Attempt coalescing to last skb in backlog, even if we are
@@ -2006,7 +2004,7 @@ bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
__NET_INC_STATS(sock_net(sk),
LINUX_MIB_TCPBACKLOGCOALESCE);
kfree_skb_partial(skb, fragstolen);
- return false;
+ return SKB_NOT_DROPPED_YET;
}
__skb_push(skb, hdrlen);
@@ -2031,15 +2029,13 @@ bool tcp_add_backlog(struct sock *sk, struct sk_buff *skb,
if (unlikely(err)) {
bh_unlock_sock(sk);
if (err == -ENOMEM) {
- *reason = SKB_DROP_REASON_PFMEMALLOC;
__NET_INC_STATS(sock_net(sk), LINUX_MIB_PFMEMALLOCDROP);
- } else {
- *reason = SKB_DROP_REASON_SOCKET_BACKLOG;
- __NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPBACKLOGDROP);
+ return SKB_DROP_REASON_PFMEMALLOC;
}
- return true;
+ __NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPBACKLOGDROP);
+ return SKB_DROP_REASON_SOCKET_BACKLOG;
}
- return false;
+ return SKB_NOT_DROPPED_YET;
}
static void tcp_v4_restore_cb(struct sk_buff *skb)
@@ -2247,7 +2243,8 @@ int tcp_v4_rcv(struct sk_buff *skb)
if (!sock_owned_by_user(sk)) {
ret = tcp_v4_do_rcv(sk, skb);
} else {
- if (tcp_add_backlog(sk, skb, &drop_reason))
+ drop_reason = tcp_add_backlog(sk, skb);
+ if (drop_reason)
goto discard_and_relse;
}
bh_unlock_sock(sk);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 8dc3874e8b9252da60f21ad77a5ca834532e650a..1d37826e8480f203846e963418cfe2085131adfa 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1877,7 +1877,8 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)
if (!sock_owned_by_user(sk)) {
ret = tcp_v6_do_rcv(sk, skb);
} else {
- if (tcp_add_backlog(sk, skb, &drop_reason))
+ drop_reason = tcp_add_backlog(sk, skb);
+ if (drop_reason)
goto discard_and_relse;
}
bh_unlock_sock(sk);
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: [PATCH nf] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Weiming Shi @ 2026-04-09 10:11 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <add2ajF5YGqd4MxZ@strlen.de>
On 26-04-09 11:50, Florian Westphal wrote:
> Weiming Shi <bestswngs@gmail.com> wrote:
> > Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
> > Reported-by: Xiang Mei <xmei5@asu.edu>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> > ---
> > include/net/netfilter/nf_dup_netdev.h | 4 ++++
> > net/netfilter/nf_dup_netdev.c | 18 ++++++++++++++++++
> > net/netfilter/nft_fwd_netdev.c | 7 +++++++
> > 3 files changed, 29 insertions(+)
> >
> > diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
> > index b175d271aec9..17362f76d1d1 100644
> > --- a/include/net/netfilter/nf_dup_netdev.h
> > +++ b/include/net/netfilter/nf_dup_netdev.h
> > @@ -7,6 +7,10 @@
> > void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> > void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> >
> > +bool nf_dup_netdev_has_recursed(void);
> > +void nf_dup_netdev_recursion_inc(void);
> > +void nf_dup_netdev_recursion_dec(void);
> > +
> > struct nft_offload_ctx;
> > struct nft_flow_rule;
> >
> > diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
> > index fab8b9011098..e2fe8bb6fe0d 100644
> > --- a/net/netfilter/nf_dup_netdev.c
> > +++ b/net/netfilter/nf_dup_netdev.c
> > @@ -29,6 +29,24 @@ static u8 *nf_get_nf_dup_skb_recursion(void)
> >
> > #endif
> >
> > +bool nf_dup_netdev_has_recursed(void)
> > +{
> > + return *nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT;
> > +}
> > +EXPORT_SYMBOL_GPL(nf_dup_netdev_has_recursed);
>
> I think thats a bit too heavy-handed.
> nf_get_nf_dup_skb_recursion() fetches from pcpu counter or current->.
>
> Can you move nf_get_nf_dup_skb_recursion to a shared header file
> and make it inline instead of having a function call?
>
Thanks for the review. I will send the patch for version v2 as you suggested.
Weiming Shi
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next 4/4] iavf: harden VLAN filter state machine race handling
From: Romanowski, Rafal @ 2026-04-09 10:12 UTC (permalink / raw)
To: Loktionov, Aleksandr, Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Eric Dumazet, linux-kernel@vger.kernel.org,
Andrew Lunn, Nguyen, Anthony L, intel-wired-lan@lists.osuosl.org,
Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <IA3PR11MB8986FA7536046A7AE5C98D96E540A@IA3PR11MB8986.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Loktionov, Aleksandr
> Sent: Monday, March 16, 2026 12:38 PM
> To: Oros, Petr <poros@redhat.com>; netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next 4/4] iavf: harden VLAN filter state
> machine race handling
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Petr Oros
> > Sent: Monday, March 16, 2026 11:42 AM
> > To: netdev@vger.kernel.org
> > Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> > <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> > <andrew+netdev@lunn.ch>; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; intel-wired-lan@lists.osuosl.org;
> > Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski
> > <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller
> > <davem@davemloft.net>
> > Subject: [Intel-wired-lan] [PATCH iwl-next 4/4] iavf: harden VLAN
> > filter state machine race handling
> >
> > Address remaining race windows in the VLAN filter state machine that
> > were identified during cross-state analysis of ADD and DEL paths.
> >
> > 1. Add VIRTCHNL_OP_ADD_VLAN to the success completion handler.
> >
> > The V1 ADD_VLAN opcode had no success handler -- filters sent via
> > V1
> > stayed in ADDING state permanently. Add a fallthrough case so V1
> > filters also transition ADDING -> ACTIVE on PF confirmation.
> >
> > Critically, add an `if (v_retval) break` guard: the error switch
> > in iavf_virtchnl_completion() does NOT return after handling
> > errors,
> > it falls through to the success switch. Without this guard, a
> > PF-rejected ADD would incorrectly mark ADDING filters as ACTIVE,
> > creating a driver/HW mismatch where the driver believes the filter
> > is installed but the PF never accepted it.
> >
> > For V2, this is harmless: iavf_vlan_add_reject() in the error
> > block already kfree'd all ADDING filters, so the success handler
> > finds nothing to transition.
> >
> > 2. Skip DEL on filters already in REMOVING state.
> >
> > In iavf_del_vlan(), if a filter is in IAVF_VLAN_REMOVING (DEL
> > already sent to PF, waiting for response), do not overwrite to
> > REMOVE and schedule a redundant DEL. The pending DEL's
> > completion handler will either kfree the filter (PF confirms)
> > or revert to ACTIVE (PF rejects).
> >
> > Without this, the sequence DEL(pending) -> user-del -> second DEL
> > could result in PF returning an error for the second DEL (filter
> > already gone), causing the completion handler to incorrectly revert
> > a deleted filter back to ACTIVE.
> >
> > Signed-off-by: Petr Oros <poros@redhat.com>
> > ---
> > drivers/net/ethernet/intel/iavf/iavf_main.c | 5 ++++-
> > drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 4 ++++
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c
> > b/drivers/net/ethernet/intel/iavf/iavf_main.c
> > index 89e5aae20d5573..1ffc0ce3f35602 100644
> > --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> > +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> > @@ -816,11 +816,14 @@ static void iavf_del_vlan(struct iavf_adapter
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* RE: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Biju Das @ 2026-04-09 10:13 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: <20260409095633.70973-3-ovidiu.panait.rb@renesas.com>
Hi Ovidu,
Thanks for the patch.
> -----Original Message-----
> From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> Sent: 09 April 2026 10:57
> Subject: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
>
> ksz9131_resume() was added to restore RGMII delays on resume for platforms where the PHY loses power
> during suspend to RAM. However, for s2idle, the PHY stays in Software Power-Down (SPD) during resume.
> In that case,
> ksz9131_config_rgmii_delay() accesses MMD registers before kszphy_resume() clears BMCR_PDOWN. The
> KSZ9131 datasheet states that during SPD, access to the MMD registers is restricted:
>
> - 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.
>
> Additionally, only RGMII delays were restored, while other settings from ksz9131_config_init() were
> not.
>
> Now that the preceding commit ("net: phylink: call phy_init_hw() in phylink resume path") performs a
> phy_init_hw() during phylink resume,
> ksz9131_resume() is no longer needed.
>
> Remove it and use kszphy_resume() directly.
How to avoid code duplication in this case?
For eg: phy_init_hw() makes the phy out of SPD state
and kszphy_resume() unconditionally makes the phy out of SPD state again.
¬ kszphy_generic_resume
¬ genphy_resume
Cheers,
Biju
>
> Fixes: f25a7eaa897f ("net: phy: micrel: Add ksz9131_resume()")
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> ---
> drivers/net/phy/micrel.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 2aa1dedd21b8..f2513109865a
> 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -6014,14 +6014,6 @@ static int lan8841_suspend(struct phy_device *phydev)
> return kszphy_generic_suspend(phydev); }
>
> -static int ksz9131_resume(struct phy_device *phydev) -{
> - if (phydev->suspended && phy_interface_is_rgmii(phydev))
> - ksz9131_config_rgmii_delay(phydev);
> -
> - return kszphy_resume(phydev);
> -}
> -
> #define LAN8842_PTP_GPIO_NUM 16
>
> static int lan8842_ptp_probe_once(struct phy_device *phydev) @@ -6929,7 +6921,7 @@ static struct
> phy_driver ksphy_driver[] = {
> .get_strings = kszphy_get_strings,
> .get_stats = kszphy_get_stats,
> .suspend = kszphy_suspend,
> - .resume = ksz9131_resume,
> + .resume = kszphy_resume,
> .cable_test_start = ksz9x31_cable_test_start,
> .cable_test_get_status = ksz9x31_cable_test_get_status,
> .get_features = ksz9477_get_features,
> --
> 2.34.1
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Ovidiu Panait @ 2026-04-09 10:13 UTC (permalink / raw)
To: geert
Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, Biju Das, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Niklas Söderlund
In-Reply-To: <CAMuHMdWQiRpCVMuimOMo4Mz2EAG+gbnKyXY7oSXh7mL_fkdGSQ@mail.gmail.com>
Hi Geert,
>
> Hi Ovidiu,
>
> On Fri, 3 Apr 2026 at 13:18, Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> wrote:
> > 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.
> >
> > Additionally, on platforms where the PHY loses power during suspend
> > (e.g. RZ/G3E), all settings from ksz9131_config_init(), not just the
> > RGMII delays, are lost and need to be restored. When the MAC driver
> > sets mac_managed_pm (e.g. stmmac), mdio_bus_phy_resume() is skipped,
> > so phy_init_hw() (which calls config_init to restore all PHY settings)
> > is never invoked during resume.
> >
> > Fix this by replacing the RGMII delay restoration with a call to
> > phy_init_hw(), which takes the PHY out of SPD and performs full
> > reinitialization.
> >
> > Fixes: f25a7eaa897f ("net: phy: micrel: Add ksz9131_resume()")
> > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
>
> Thanks for your patch!
>
> > --- a/drivers/net/phy/micrel.c
> > +++ b/drivers/net/phy/micrel.c
> > @@ -6016,8 +6016,13 @@ static int lan8841_suspend(struct phy_device
> *phydev)
> >
> > static int ksz9131_resume(struct phy_device *phydev)
> > {
> > - if (phydev->suspended && phy_interface_is_rgmii(phydev))
> > - ksz9131_config_rgmii_delay(phydev);
> > + int ret;
> > +
> > + if (phydev->suspended) {
> > + ret = phy_init_hw(phydev);
> > + if (ret)
> > + return ret;
> > + }
> >
> > return kszphy_resume(phydev);
> > }
>
> This function is now no longer KSZ9131-specific.
> I am wondering if this should be done for other Micrel PHYs, too,
> e.g. by moving the phy_init_hw() call into kszphy_resume()?
>
> Ethernet after resume has always been flaky on Salvator-X with KSZ9031
> and R-Car M3-W ES1.0 (this seems to be specific to R-Car M3-W, as
> boards with R-Car H3 or M3-N do not seem to suffer from this; don't
> ask me why).
>
> I have just tried:
>
> - .resume = kszphy_resume,
> + .resume = ksz9131_resume,
>
> in the KSZ9031 entry, and ... surprise! Ethernet on R-Car M3-W now
> works much better after resume!
>
I checked the dts for the Salvator-X board and it seems that it uses
the RAVB MAC. The driver for RAVB sets the mac_managed_pm flag, which
means that the MAC driver is handling the suspend/resume of the PHY.
In this case, as Russell pointed out in [1], the MAC driver should be
the one issuing phy_init_hw() before calling phy_resume(). I sent a
fix for the phylink resume path ([2]), to align it with the MDIO bus
resume path, but the RAVB driver doesn't seem to be using phylink,
it calls phy_start() directly.
Based on this, I think the fix should be to add a phy_init_hw() call
in the RAVB driver, on the resume path, rather than in the PHY driver.
[1] https://lore.kernel.org/all/ac_Udvtrj0Bl-6wl@shell.armlinux.org.uk/
[2] https://lore.kernel.org/all/20260409095633.70973-2-ovidiu.panait.rb@renesas.com/
Thanks,
Ovidiu
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] r8152: Add support for the RTL8157 hardware
From: Paolo Abeni @ 2026-04-09 10:16 UTC (permalink / raw)
To: Birger Koblitz, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260404-rtl8157_next-v7-2-039121318f23@birger-koblitz.de>
On 4/4/26 9:57 AM, Birger Koblitz wrote:
> @@ -6534,8 +6842,11 @@ static void rtl8156_up(struct r8152 *tp)
> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
> PLA_MCU_SPDWN_EN);
>
> - ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
> - RG_PWRDN_EN | ALL_SPEED_OFF);
> + ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
AI review notes that the above leads to 2 consecutive:
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
with slightly different formatting, likely C&P error?!?
I think this is better handled with a follow-up, if needed, as I don't
see any possible issue out of it.
Other AI comments look not relevant.
/P
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next 1/4] iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
From: Romanowski, Rafal @ 2026-04-09 10:16 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Eric Dumazet, linux-kernel@vger.kernel.org,
Andrew Lunn, Nguyen, Anthony L, intel-wired-lan@lists.osuosl.org,
Keller, Jacob E, Jakub Kicinski, Paolo Abeni, David S. Miller
In-Reply-To: <20260316104209.1285962-2-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr
> Oros
> Sent: Monday, March 16, 2026 11:42 AM
> To: netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet
> <edumazet@google.com>; linux-kernel@vger.kernel.org; Andrew Lunn
> <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH iwl-next 1/4] iavf: rename IAVF_VLAN_IS_NEW
> to IAVF_VLAN_ADDING
>
> Rename the IAVF_VLAN_IS_NEW state to IAVF_VLAN_ADDING to better describe
> what the state represents: an ADD request has been sent to the PF and is waiting
> for a response.
>
> This is a pure rename with no behavioral change, preparing for a cleanup of the
> VLAN filter state machine.
>
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> b/drivers/net/ethernet/intel/iavf/iavf.h
> index a87e0c6d4017ad..8e6db72828ae14 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf.h
> @@ -158,7 +158,7 @@ struct iavf_vlan {
> enum iavf_vlan_state_t {
> IAVF_VLAN_INVALID,
> IAVF_VLAN_ADD, /* filter needs to be added */
> - IAVF_VLAN_IS_NEW, /* filter is new, wait for PF answer */
> + IAVF_VLAN_ADDING, /* ADD sent to PF, waiting for response */
> IAVF_VLAN_ACTIVE, /* filter is accepted by PF */
> IAVF_VLAN_DISABLE, /* filter needs to be deleted by PF, then marked
> INACTIVE */
> IAVF_VLAN_INACTIVE, /* filter is inactive, we are in IFF_DOWN */
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> index 88156082a41da6..5114934fe81fa6 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> @@ -746,7 +746,7 @@ static void iavf_vlan_add_reject(struct iavf_adapter
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* Re: [PATCH] nfc: nci: fix OOB heap read in nci_core_init_rsp_packet_v2()
From: Simon Horman @ 2026-04-09 10:17 UTC (permalink / raw)
To: Lekë Hapçiu
Cc: netdev, gregkh, linux-nfc, davem, kuba, Lekë Hapçiu
In-Reply-To: <20260404180049.1304711-1-snowwlake@icloud.com>
On Sat, Apr 04, 2026 at 08:00:49PM +0200, Lekë Hapçiu wrote:
> From: Lekë Hapçiu <framemain@outlook.com>
>
> nci_core_init_rsp_packet_v2() walks the chip-supplied
> supported_rf_interfaces[] flexible array using a plain pointer
> with no bounds check. Each iteration advances supported_rf_interface
> by (1 + 1 + rf_extension_cnt) bytes, where rf_extension_cnt comes
> directly from the chip. A hostile NCI v2 chip can set
> rf_extension_cnt=255 per entry and num_supported_rf_interfaces=4,
> driving the pointer up to ~1028 bytes past the end of the skb into
> adjacent kernel heap.
>
> Add two guards per loop iteration:
> - check that at least 2 bytes remain before reading the interface
> byte and extension count byte;
> - check that sufficient bytes remain for the declared extension
> block before advancing over it.
>
> Also add an upfront sizeof(*rsp) check so that accessing the fixed
> header fields (nfcc_features, max_logical_connections, ...) is safe
> before the loop is reached.
>
> Fixes: bcd684aace34 ("net/nfc/nci: Support NCI 2.x initial sequence")
> Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
I believe that my review of "[PATCH] nfc: nci: fix OOB heap read in
nci_core_init_rsp_packet_v1()" is relevant here.
- https://lore.kernel.org/all/20260408190505.GK469338@kernel.org/
I would appreciate it if you could create a v2 patchset, including
an updated version of this patch and that one.
Thanks!
--
pw-bot: changes-requested
^ permalink raw reply
* [PATCH iwl-net v5] ice: fix missing dpll notifications for SW pins
From: Petr Oros @ 2026-04-09 10:25 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Arkadiusz Kubalewski, intel-wired-lan, linux-kernel
The SMA/U.FL pin redesign (commit 2dd5d03c77e2 ("ice: redesign dpll
sma/u.fl pins control")) introduced software-controlled pins that wrap
backing CGU input/output pins, but never updated the notification and
data paths to propagate pin events to these SW wrappers.
The periodic work sends dpll_pin_change_ntf() only for direct CGU input
pins. SW pins that wrap these inputs never receive change or phase
offset notifications, so userspace consumers such as synce4l monitoring
SMA pins via dpll netlink never learn about state transitions or phase
offset updates. Similarly, ice_dpll_phase_offset_get() reads the SW
pin's own phase_offset field which is never updated; the PPS monitor
writes to the backing CGU input's field instead.
On top of that, when SMA or U.FL pin state changes via PCA9575 GPIO
write, the paired pin's state also changes because they share physical
signal paths, but no notification is sent for the peer pin.
Fix by introducing ice_dpll_pin_ntf(), a wrapper around
dpll_pin_change_ntf() that also notifies any registered SMA/U.FL pin
whose backing CGU input matches. Replace all direct
dpll_pin_change_ntf() calls in the periodic notification paths with
this wrapper. Fix ice_dpll_phase_offset_get() to return the backing
CGU input's phase_offset for input-direction SW pins. Add
ice_dpll_sw_pin_notify_peer() to send a notification for the paired
SW pin after PCA9575 writes in ice_dpll_sma_direction_set() and
ice_dpll_ufl_pin_state_set().
Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
Signed-off-by: Petr Oros <poros@redhat.com>
---
v5:
- add ice_dpll_sw_pin_notify_peer() for SMA/U.FL peer notification
when PCA9575 routing changes affect the paired pin (reported by
Intel test: SMA state change did not log U.FL status change in
subscribe monitor)
v4: https://lore.kernel.org/all/20260319205256.998876-1-poros@redhat.com/
v3: https://lore.kernel.org/all/20260220140700.2910174-1-poros@redhat.com/
v2: https://lore.kernel.org/all/20260219131500.2271897-1-poros@redhat.com/
v1: https://lore.kernel.org/all/20260218211414.1411163-1-poros@redhat.com/
---
drivers/net/ethernet/intel/ice/ice_dpll.c | 74 +++++++++++++++++++----
1 file changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
index 3f8cd5b8298b57..d817f17dcf1951 100644
--- a/drivers/net/ethernet/intel/ice/ice_dpll.c
+++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
@@ -1154,6 +1154,30 @@ ice_dpll_input_state_get(const struct dpll_pin *pin, void *pin_priv,
extack, ICE_DPLL_PIN_TYPE_INPUT);
}
+/**
+ * ice_dpll_sw_pin_notify_peer - notify the paired SW pin after a state change
+ * @d: pointer to dplls struct
+ * @changed: the SW pin that was explicitly changed (already notified by dpll core)
+ *
+ * SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and
+ * SMA2/U.FL2). When one pin's routing changes via the PCA9575 GPIO
+ * expander, the paired pin's state may also change. Send a change
+ * notification for the peer pin so userspace consumers monitoring the
+ * peer via dpll netlink learn about the update.
+ *
+ * Context: Can be called under pf->dplls.lock, dpll_pin_change_ntf() is safe.
+ */
+static void ice_dpll_sw_pin_notify_peer(struct ice_dplls *d,
+ struct ice_dpll_pin *changed)
+{
+ struct ice_dpll_pin *peer;
+
+ peer = (changed >= d->sma && changed < d->sma + ICE_DPLL_PIN_SW_NUM) ?
+ &d->ufl[changed->idx] : &d->sma[changed->idx];
+ if (peer->pin)
+ dpll_pin_change_ntf(peer->pin);
+}
+
/**
* ice_dpll_sma_direction_set - set direction of SMA pin
* @p: pointer to a pin
@@ -1233,6 +1257,8 @@ static int ice_dpll_sma_direction_set(struct ice_dpll_pin *p,
ret = ice_dpll_pin_state_update(p->pf, target,
type, extack);
}
+ if (!ret)
+ ice_dpll_sw_pin_notify_peer(d, p);
return ret;
}
@@ -1334,6 +1360,7 @@ ice_dpll_ufl_pin_state_set(const struct dpll_pin *pin, void *pin_priv,
extack);
if (ret)
goto unlock;
+ ice_dpll_sw_pin_notify_peer(&pf->dplls, p);
if (enable)
ret = ice_dpll_pin_enable(hw, target, d->dpll_idx, type, extack);
@@ -1963,7 +1990,10 @@ ice_dpll_phase_offset_get(const struct dpll_pin *pin, void *pin_priv,
d->active_input == p->input->pin))
*phase_offset = d->phase_offset * ICE_DPLL_PHASE_OFFSET_FACTOR;
else if (d->phase_offset_monitor_period)
- *phase_offset = p->phase_offset * ICE_DPLL_PHASE_OFFSET_FACTOR;
+ *phase_offset = (p->input &&
+ p->direction == DPLL_PIN_DIRECTION_INPUT ?
+ p->input->phase_offset :
+ p->phase_offset) * ICE_DPLL_PHASE_OFFSET_FACTOR;
else
*phase_offset = 0;
mutex_unlock(&pf->dplls.lock);
@@ -2657,6 +2687,27 @@ static u64 ice_generate_clock_id(struct ice_pf *pf)
return pci_get_dsn(pf->pdev);
}
+/**
+ * ice_dpll_pin_ntf - notify pin change including any SW pin wrappers
+ * @dplls: pointer to dplls struct
+ * @pin: the dpll_pin that changed
+ *
+ * Send a change notification for @pin and for any registered SMA/U.FL pin
+ * whose backing CGU input matches @pin.
+ */
+static void ice_dpll_pin_ntf(struct ice_dplls *dplls, struct dpll_pin *pin)
+{
+ dpll_pin_change_ntf(pin);
+ for (int i = 0; i < ICE_DPLL_PIN_SW_NUM; i++) {
+ if (dplls->sma[i].pin && dplls->sma[i].input &&
+ dplls->sma[i].input->pin == pin)
+ dpll_pin_change_ntf(dplls->sma[i].pin);
+ if (dplls->ufl[i].pin && dplls->ufl[i].input &&
+ dplls->ufl[i].input->pin == pin)
+ dpll_pin_change_ntf(dplls->ufl[i].pin);
+ }
+}
+
/**
* ice_dpll_notify_changes - notify dpll subsystem about changes
* @d: pointer do dpll
@@ -2665,6 +2716,7 @@ static u64 ice_generate_clock_id(struct ice_pf *pf)
*/
static void ice_dpll_notify_changes(struct ice_dpll *d)
{
+ struct ice_dplls *dplls = &d->pf->dplls;
bool pin_notified = false;
if (d->prev_dpll_state != d->dpll_state) {
@@ -2673,17 +2725,17 @@ static void ice_dpll_notify_changes(struct ice_dpll *d)
}
if (d->prev_input != d->active_input) {
if (d->prev_input)
- dpll_pin_change_ntf(d->prev_input);
+ ice_dpll_pin_ntf(dplls, d->prev_input);
d->prev_input = d->active_input;
if (d->active_input) {
- dpll_pin_change_ntf(d->active_input);
+ ice_dpll_pin_ntf(dplls, d->active_input);
pin_notified = true;
}
}
if (d->prev_phase_offset != d->phase_offset) {
d->prev_phase_offset = d->phase_offset;
if (!pin_notified && d->active_input)
- dpll_pin_change_ntf(d->active_input);
+ ice_dpll_pin_ntf(dplls, d->active_input);
}
}
@@ -2712,6 +2764,7 @@ static bool ice_dpll_is_pps_phase_monitor(struct ice_pf *pf)
/**
* ice_dpll_pins_notify_mask - notify dpll subsystem about bulk pin changes
+ * @dplls: pointer to dplls struct
* @pins: array of ice_dpll_pin pointers registered within dpll subsystem
* @pin_num: number of pins
* @phase_offset_ntf_mask: bitmask of pin indexes to notify
@@ -2721,15 +2774,14 @@ static bool ice_dpll_is_pps_phase_monitor(struct ice_pf *pf)
*
* Context: Must be called while pf->dplls.lock is released.
*/
-static void ice_dpll_pins_notify_mask(struct ice_dpll_pin *pins,
+static void ice_dpll_pins_notify_mask(struct ice_dplls *dplls,
+ struct ice_dpll_pin *pins,
u8 pin_num,
u32 phase_offset_ntf_mask)
{
- int i = 0;
-
- for (i = 0; i < pin_num; i++)
- if (phase_offset_ntf_mask & (1 << i))
- dpll_pin_change_ntf(pins[i].pin);
+ for (int i = 0; i < pin_num; i++)
+ if (phase_offset_ntf_mask & BIT(i))
+ ice_dpll_pin_ntf(dplls, pins[i].pin);
}
/**
@@ -2905,7 +2957,7 @@ static void ice_dpll_periodic_work(struct kthread_work *work)
ice_dpll_notify_changes(de);
ice_dpll_notify_changes(dp);
if (phase_offset_ntf)
- ice_dpll_pins_notify_mask(d->inputs, d->num_inputs,
+ ice_dpll_pins_notify_mask(d, d->inputs, d->num_inputs,
phase_offset_ntf);
resched:
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Russell King (Oracle) @ 2026-04-09 10:29 UTC (permalink / raw)
To: Biju Das
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY3PR01MB11346A0F047F1F7296B8F4FCA86582@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On Thu, Apr 09, 2026 at 10:13:10AM +0000, Biju Das wrote:
> Hi Ovidu,
>
> Thanks for the patch.
>
> > -----Original Message-----
> > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > Sent: 09 April 2026 10:57
> > Subject: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
> >
> > ksz9131_resume() was added to restore RGMII delays on resume for platforms where the PHY loses power
> > during suspend to RAM. However, for s2idle, the PHY stays in Software Power-Down (SPD) during resume.
> > In that case,
> > ksz9131_config_rgmii_delay() accesses MMD registers before kszphy_resume() clears BMCR_PDOWN. The
> > KSZ9131 datasheet states that during SPD, access to the MMD registers is restricted:
> >
> > - 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.
> >
> > Additionally, only RGMII delays were restored, while other settings from ksz9131_config_init() were
> > not.
> >
> > Now that the preceding commit ("net: phylink: call phy_init_hw() in phylink resume path") performs a
> > phy_init_hw() during phylink resume,
> > ksz9131_resume() is no longer needed.
> >
> > Remove it and use kszphy_resume() directly.
>
> How to avoid code duplication in this case?
>
> For eg: phy_init_hw() makes the phy out of SPD state
>
> and kszphy_resume() unconditionally makes the phy out of SPD state again.
> ¬ kszphy_generic_resume
> ¬ genphy_resume
My question would be... if we mandate that phy_init_hw() must be called
before phy_resume() by MAC drivers, then how much of kszphy_resume()
becomes redundant?
Given that populating drv->soft_reset() with genphy_soft_reset() means
the PDOWN bit will be cleared, genphy_resume() becomes redundant.
phy_init_hw() will also call drv->config_intr(), so that doesn't need
to be done either.
It will also call drv->config_init(), which will call
kszphy_config_reset().
So most of kszphy_resume() becomes unnecessary. I think the only thing
that remains would be the call to kszphy_enable_clk() - and is it fine
to call that after phy_init_hw() ?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v7 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: patchwork-bot+netdevbpf @ 2026-04-09 10:30 UTC (permalink / raw)
To: Birger Koblitz
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-usb, netdev,
linux-kernel, hsu.chih.kai
In-Reply-To: <20260404-rtl8157_next-v7-0-039121318f23@birger-koblitz.de>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 04 Apr 2026 09:57:41 +0200 you wrote:
> Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
> chip in the RTL815x family of chips.
>
> The RTL8157 uses a different frame descriptor format, and different
> SRAM/ADV access methods, plus offers 5GBit/s Ethernet, so support for these
> features is added in addition to chip initialization and configuration.
>
> [...]
Here is the summary with links:
- [net-next,v7,1/2] r8152: Add support for 5Gbit Link Speeds and EEE
https://git.kernel.org/netdev/net-next/c/ebe5fd2ed20a
- [net-next,v7,2/2] r8152: Add support for the RTL8157 hardware
https://git.kernel.org/netdev/net-next/c/fd3c7d080df5
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2 1/2] net: phylink: call phy_init_hw() in phylink resume path
From: Russell King (Oracle) @ 2026-04-09 10:42 UTC (permalink / raw)
To: Ovidiu Panait
Cc: andrew, hkallweit1, davem, edumazet, kuba, pabeni, biju.das.jz,
netdev, linux-kernel, linux-renesas-soc
In-Reply-To: <20260409095633.70973-2-ovidiu.panait.rb@renesas.com>
On Thu, Apr 09, 2026 at 09:56:32AM +0000, Ovidiu Panait wrote:
> When mac_managed_pm flag is set, mdio_bus_phy_resume() is skipped,
> so phy_init_hw(), which performs soft_reset and config_init, is not
> called during resume.
>
> This is inconsistent with the non-mac_managed_pm path, where
> mdio_bus_phy_resume() calls phy_init_hw() before phy_resume()
> on every resume.
>
> Add phy_init_hw() calls in both phylink_prepare_resume() and
> phylink_resume(), to ensure that the PHY state is the same as
> when the PHY is resumed via the MDIO bus.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> ---
> drivers/net/phy/phylink.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 087ac63f9193..c302126009f6 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -2669,8 +2669,10 @@ void phylink_prepare_resume(struct phylink *pl)
> * then resume the PHY. Note that 802.3 allows PHYs 500ms before
> * the clock meets requirements. We do not implement this delay.
> */
> - if (pl->config->mac_requires_rxc && phydev && phydev->suspended)
> + if (pl->config->mac_requires_rxc && phydev && phydev->suspended) {
> + phy_init_hw(phydev);
> phy_resume(phydev);
I'm going to make an alternative suggestion - should we combine
phy_init_hw() and phy_resume() to ensure that all MAC drivers that
call phy_resume() correctly initialise the PHY first?
Looking at the callers of phy_resume():
- drivers/net/ethernet/nxp/lpc_eth.c - calls phy_resume() from
lpc_eth_open() but no call to phy_init_hw(). Not used in
suspend/resume paths, so presumably uses the built-in phylib
handling that does call phy_init_hw() before phy_resume().
- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c - suspends
and then immediately resumes the PHY before enabling loopback. Seems
like a PHY workaround that should've been handled in the PHY driver.
Suspends the PHY when loopback is disabled (which looks buggy.)
- drivers/net/ethernet/hisilicon/hns/hns_ethtool.c - resumes the PHY
when enabling loopback and suspends the PHY when loopback is
disabled. (what if the netdev is already up? Also looks buggy to me.)
- drivers/net/ethernet/broadcom/genet/bcmgenet.c - bcmgenet_resume()
calls phy_init_hw() before a conditional call to phy_resume(). I
don't see a matching call to phy_suspend(). If the bcmgenet device
may wakeup the system, then wouldn't the PHY configuration be
preserved over suspend/resume making the call to phy_init_hw() also
unnecessary if device_may_wakeup(d) returns true?
- drivers/net/ethernet/broadcom/bcmsysport.c - no call to phy_init_hw()
before phy_resume().
- drivers/net/ethernet/realtek/r8169_main.c - calls phy_init_hw()
immediately before phy_resume().
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v2] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Weiming Shi @ 2026-04-09 10:49 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Phil Sutter, Simon Horman, netfilter-devel, coreteam, netdev,
Xiang Mei, Weiming Shi
nft_fwd_neigh can be used in egress chains (NF_NETDEV_EGRESS). When the
forwarding rule targets the same device or two devices forward to each
other, neigh_xmit() triggers dev_queue_xmit() which re-enters
nf_hook_egress(), causing infinite recursion and stack overflow.
Move the nf_get_nf_dup_skb_recursion() accessor and NF_RECURSION_LIMIT
to the shared header nf_dup_netdev.h as a static inline, so that
nft_fwd_netdev can use the recursion counter directly without exported
function call overhead. Guard neigh_xmit() with the same recursion
limit already used in nf_do_netdev_egress().
Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
include/net/netfilter/nf_dup_netdev.h | 13 +++++++++++++
net/netfilter/nf_dup_netdev.c | 16 ----------------
net/netfilter/nft_fwd_netdev.c | 7 +++++++
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
index b175d271aec9..609bcf422a9b 100644
--- a/include/net/netfilter/nf_dup_netdev.h
+++ b/include/net/netfilter/nf_dup_netdev.h
@@ -3,10 +3,23 @@
#define _NF_DUP_NETDEV_H_
#include <net/netfilter/nf_tables.h>
+#include <linux/netdevice.h>
+#include <linux/sched.h>
void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
+#define NF_RECURSION_LIMIT 2
+
+static inline u8 *nf_get_nf_dup_skb_recursion(void)
+{
+#ifndef CONFIG_PREEMPT_RT
+ return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
+#else
+ return ¤t->net_xmit.nf_dup_skb_recursion;
+#endif
+}
+
struct nft_offload_ctx;
struct nft_flow_rule;
diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
index fab8b9011098..a958a1b0c5be 100644
--- a/net/netfilter/nf_dup_netdev.c
+++ b/net/netfilter/nf_dup_netdev.c
@@ -13,22 +13,6 @@
#include <net/netfilter/nf_tables_offload.h>
#include <net/netfilter/nf_dup_netdev.h>
-#define NF_RECURSION_LIMIT 2
-
-#ifndef CONFIG_PREEMPT_RT
-static u8 *nf_get_nf_dup_skb_recursion(void)
-{
- return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
-}
-#else
-
-static u8 *nf_get_nf_dup_skb_recursion(void)
-{
- return ¤t->net_xmit.nf_dup_skb_recursion;
-}
-
-#endif
-
static void nf_do_netdev_egress(struct sk_buff *skb, struct net_device *dev,
enum nf_dev_hooks hook)
{
diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
index 152a9fb4d23a..492bb599a499 100644
--- a/net/netfilter/nft_fwd_netdev.c
+++ b/net/netfilter/nft_fwd_netdev.c
@@ -141,13 +141,20 @@ static void nft_fwd_neigh_eval(const struct nft_expr *expr,
goto out;
}
+ if (*nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT) {
+ verdict = NF_DROP;
+ goto out;
+ }
+
dev = dev_get_by_index_rcu(nft_net(pkt), oif);
if (dev == NULL)
return;
skb->dev = dev;
skb_clear_tstamp(skb);
+ (*nf_get_nf_dup_skb_recursion())++;
neigh_xmit(neigh_table, dev, addr, skb);
+ (*nf_get_nf_dup_skb_recursion())--;
out:
regs->verdict.code = verdict;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] gre: Count GRE packet drops
From: Gal Pressman @ 2026-04-09 10:52 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, netdev
Cc: David Ahern, Simon Horman, Dragos Tatulea, Nimrod Oren
In-Reply-To: <20260409090945.1542440-1-gal@nvidia.com>
Addressing Sashiko's comments:
https://sashiko.dev/#/patchset/20260409090945.1542440-1-gal@nvidia.com
On 09/04/2026 12:09, Gal Pressman wrote:
> GRE is silently dropping packets without updating statistics.
>
> In case of drop, increment rx_dropped counter to provide visibility into
> packet loss. For the case where no GRE protocol handler is registered,
> use rx_nohandler.
>
> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
> Reviewed-by: Nimrod Oren <noren@nvidia.com>
> Signed-off-by: Gal Pressman <gal@nvidia.com>
> ---
> net/ipv4/gre_demux.c | 8 ++++++--
> net/ipv4/ip_gre.c | 1 +
> net/ipv6/ip6_gre.c | 1 +
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
> index dafd68f3436a..96fd7dc6d82d 100644
> --- a/net/ipv4/gre_demux.c
> +++ b/net/ipv4/gre_demux.c
> @@ -159,14 +159,18 @@ static int gre_rcv(struct sk_buff *skb)
> rcu_read_lock();
> proto = rcu_dereference(gre_proto[ver]);
> if (!proto || !proto->handler)
> - goto drop_unlock;
> + goto drop_nohandler;
> ret = proto->handler(skb);
> rcu_read_unlock();
> return ret;
>
> -drop_unlock:
> +drop_nohandler:
> rcu_read_unlock();
> + dev_core_stats_rx_nohandler_inc(skb->dev);
> + kfree_skb(skb);
> + return NET_RX_DROP;
> drop:
> + dev_core_stats_rx_dropped_inc(skb->dev);
---
At this point in gre_rcv(), does skb->dev point to the underlying
ingress physical interface (e.g., eth0) rather than a GRE tunnel device?
If so, does incrementing the L2 physical device counters for an L4 protocol
error case pollute the physical interface metrics? Unconfigured
GRE traffic from the network might cause physical device drop counters to
spike, which could be misdiagnosed as hardware issues.
Would it be better to expose these via protocol-specific MIB counters or by
passing a specific drop reason to kfree_skb_reason()?
---
Yes, it points to the underlying device, and that makes sense IMO.
At this point, the packets are still not associated with any tunnel (it
might not even exist).
> kfree_skb(skb);
> return NET_RX_DROP;
> }
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index dafcc0dcd77a..63fc8556b475 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -593,6 +593,7 @@ static int gre_rcv(struct sk_buff *skb)
> out:
> icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0);
> drop:
> + dev_core_stats_rx_dropped_inc(skb->dev);
> kfree_skb(skb);
> return 0;
> }
---
Does this fully account for silent packet drops during decapsulation?
Looking at erspan_rcv() and ipgre_rcv() which are called earlier in this
function, if they fail internally (for example, if __iptunnel_pull_header()
fails), they free the skb and return PACKET_RCVD:
net/ipv4/ip_gre.c:erspan_rcv() {
...
if (__iptunnel_pull_header(skb, len, htons(ETH_P_TEB), false, false)
< 0)
goto drop;
...
drop:
kfree_skb(skb);
return PACKET_RCVD;
}
Since gre_rcv() checks for PACKET_RCVD and returns 0:
if (erspan_rcv(skb, &tpi, hdr_len) == PACKET_RCVD)
return 0;
Does this bypass the newly added dev_core_stats_rx_dropped_inc() call under
the drop label entirely, leaving these packets silently dropped?
---
These are also silent drops, but these should be counted towards the
tunnel device, maybe as a separate patch.
^ permalink raw reply
* RE: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Biju Das @ 2026-04-09 10:52 UTC (permalink / raw)
To: Russell King
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <add_krK3MC1-SSsV@shell.armlinux.org.uk>
Hi Russell King,
Thanks for the feedback.
> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 09 April 2026 11:30
> Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
>
> On Thu, Apr 09, 2026 at 10:13:10AM +0000, Biju Das wrote:
> > Hi Ovidu,
> >
> > Thanks for the patch.
> >
> > > -----Original Message-----
> > > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > Sent: 09 April 2026 10:57
> > > Subject: [PATCH net v2 2/2] net: phy: micrel: remove
> > > ksz9131_resume()
> > >
> > > ksz9131_resume() was added to restore RGMII delays on resume for
> > > platforms where the PHY loses power during suspend to RAM. However, for s2idle, the PHY stays in
> Software Power-Down (SPD) during resume.
> > > In that case,
> > > ksz9131_config_rgmii_delay() accesses MMD registers before
> > > kszphy_resume() clears BMCR_PDOWN. The
> > > KSZ9131 datasheet states that during SPD, access to the MMD registers is restricted:
> > >
> > > - 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.
> > >
> > > Additionally, only RGMII delays were restored, while other settings
> > > from ksz9131_config_init() were not.
> > >
> > > Now that the preceding commit ("net: phylink: call phy_init_hw() in
> > > phylink resume path") performs a
> > > phy_init_hw() during phylink resume,
> > > ksz9131_resume() is no longer needed.
> > >
> > > Remove it and use kszphy_resume() directly.
> >
> > How to avoid code duplication in this case?
> >
> > For eg: phy_init_hw() makes the phy out of SPD state
> >
> > and kszphy_resume() unconditionally makes the phy out of SPD state again.
> > ¬ kszphy_generic_resume
> > ¬ genphy_resume
>
> My question would be... if we mandate that phy_init_hw() must be called before phy_resume() by MAC
> drivers, then how much of kszphy_resume() becomes redundant?
>
> Given that populating drv->soft_reset() with genphy_soft_reset() means the PDOWN bit will be cleared,
> genphy_resume() becomes redundant.
>
> phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
>
> It will also call drv->config_init(), which will call kszphy_config_reset().
>
> So most of kszphy_resume() becomes unnecessary. I think the only thing that remains would be the call
> to kszphy_enable_clk() - and is it fine to call that after phy_init_hw() ?
It just needs kszphy_enable_clk() and phydev->drv->config_intr() to enable PHY interrupts for
suspend-to-RAM to work on RZ/G3E SMARC EVK.
Cheers,
Biju
^ permalink raw reply
* [pull-request] mlx5-next updates 2026-04-09
From: Tariq Toukan @ 2026-04-09 11:04 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Leon Romanovsky, Jason Gunthorpe, Saeed Mahameed, Tariq Toukan,
Mark Bloch, Shay Drori, Parav Pandit, Joe Damato, Simon Horman,
linux-rdma, linux-kernel, netdev, Gal Pressman, Dragos Tatulea
Hi,
The following pull-request contains common mlx5 updates
for your *net-next* tree.
Please pull and let me know of any problem.
Regards,
Tariq
----------------------------------------------------------------
The following changes since commit 4dd2115f43594da5271a1aa34fde6719b4259047:
net/mlx5: Expose MLX5_UMR_ALIGN definition (2026-03-16 16:23:00 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-next
for you to fetch changes up to a1bac8b70ede332a05487081c7512d2947f3a912:
net/mlx5: Add icm_mng_function_id_mode cap bit (2026-04-09 05:26:39 -0400)
----------------------------------------------------------------
Moshe Shemesh (2):
net/mlx5: Rename MLX5_PF page counter type to MLX5_SELF
net/mlx5: Add icm_mng_function_id_mode cap bit
Parav Pandit (1):
mlx5: Remove redundant iseg base
Patrisious Haddad (1):
net/mlx5: Add vhca_id_type bit to alias context
drivers/infiniband/hw/mlx5/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 +--
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c | 3 +--
include/linux/mlx5/driver.h | 3 +--
include/linux/mlx5/mlx5_ifc.h | 15 ++++++++++++---
6 files changed, 18 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Russell King (Oracle) @ 2026-04-09 11:05 UTC (permalink / raw)
To: Biju Das
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY3PR01MB113465B215559404D0FBD04AE86582@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On Thu, Apr 09, 2026 at 10:52:35AM +0000, Biju Das wrote:
> Hi Russell King,
>
> Thanks for the feedback.
>
> > -----Original Message-----
> > From: Russell King <linux@armlinux.org.uk>
> > Sent: 09 April 2026 11:30
> > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
> >
> > phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
> >
> > It will also call drv->config_init(), which will call kszphy_config_reset().
> >
> > So most of kszphy_resume() becomes unnecessary. I think the only thing that remains would be the call
> > to kszphy_enable_clk() - and is it fine to call that after phy_init_hw() ?
>
> It just needs kszphy_enable_clk() and phydev->drv->config_intr() to enable PHY interrupts for
> suspend-to-RAM to work on RZ/G3E SMARC EVK.
I think you mean WoL rather than suspend-to-RAM, although I don't see
anything in micrel.c that hints that WoL is supported, so please explain
why and how the PHY interrupt impacts suspend-to-RAM.
Note that a particular interrupt should not wake the system unless
enable_irq_wake() has been called for that specific interrupt.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Pablo Neira Ayuso @ 2026-04-09 11:05 UTC (permalink / raw)
To: Weiming Shi
Cc: Florian Westphal, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <20260409104911.722698-2-bestswngs@gmail.com>
On Thu, Apr 09, 2026 at 06:49:12PM +0800, Weiming Shi wrote:
> nft_fwd_neigh can be used in egress chains (NF_NETDEV_EGRESS). When the
> forwarding rule targets the same device or two devices forward to each
> other, neigh_xmit() triggers dev_queue_xmit() which re-enters
> nf_hook_egress(), causing infinite recursion and stack overflow.
>
> Move the nf_get_nf_dup_skb_recursion() accessor and NF_RECURSION_LIMIT
> to the shared header nf_dup_netdev.h as a static inline, so that
> nft_fwd_netdev can use the recursion counter directly without exported
> function call overhead. Guard neigh_xmit() with the same recursion
> limit already used in nf_do_netdev_egress().
>
> Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
I would just restrict this "feature", I don't see a point in allowing
this from egress?
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> include/net/netfilter/nf_dup_netdev.h | 13 +++++++++++++
> net/netfilter/nf_dup_netdev.c | 16 ----------------
> net/netfilter/nft_fwd_netdev.c | 7 +++++++
> 3 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
> index b175d271aec9..609bcf422a9b 100644
> --- a/include/net/netfilter/nf_dup_netdev.h
> +++ b/include/net/netfilter/nf_dup_netdev.h
> @@ -3,10 +3,23 @@
> #define _NF_DUP_NETDEV_H_
>
> #include <net/netfilter/nf_tables.h>
> +#include <linux/netdevice.h>
> +#include <linux/sched.h>
>
> void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
>
> +#define NF_RECURSION_LIMIT 2
> +
> +static inline u8 *nf_get_nf_dup_skb_recursion(void)
> +{
> +#ifndef CONFIG_PREEMPT_RT
> + return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
> +#else
> + return ¤t->net_xmit.nf_dup_skb_recursion;
> +#endif
> +}
> +
> struct nft_offload_ctx;
> struct nft_flow_rule;
>
> diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
> index fab8b9011098..a958a1b0c5be 100644
> --- a/net/netfilter/nf_dup_netdev.c
> +++ b/net/netfilter/nf_dup_netdev.c
> @@ -13,22 +13,6 @@
> #include <net/netfilter/nf_tables_offload.h>
> #include <net/netfilter/nf_dup_netdev.h>
>
> -#define NF_RECURSION_LIMIT 2
> -
> -#ifndef CONFIG_PREEMPT_RT
> -static u8 *nf_get_nf_dup_skb_recursion(void)
> -{
> - return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
> -}
> -#else
> -
> -static u8 *nf_get_nf_dup_skb_recursion(void)
> -{
> - return ¤t->net_xmit.nf_dup_skb_recursion;
> -}
> -
> -#endif
> -
> static void nf_do_netdev_egress(struct sk_buff *skb, struct net_device *dev,
> enum nf_dev_hooks hook)
> {
> diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
> index 152a9fb4d23a..492bb599a499 100644
> --- a/net/netfilter/nft_fwd_netdev.c
> +++ b/net/netfilter/nft_fwd_netdev.c
> @@ -141,13 +141,20 @@ static void nft_fwd_neigh_eval(const struct nft_expr *expr,
> goto out;
> }
>
> + if (*nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT) {
> + verdict = NF_DROP;
> + goto out;
> + }
> +
> dev = dev_get_by_index_rcu(nft_net(pkt), oif);
> if (dev == NULL)
> return;
>
> skb->dev = dev;
> skb_clear_tstamp(skb);
> + (*nf_get_nf_dup_skb_recursion())++;
> neigh_xmit(neigh_table, dev, addr, skb);
> + (*nf_get_nf_dup_skb_recursion())--;
> out:
> regs->verdict.code = verdict;
> }
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: possible deadlock in virtio_transport_release (vsock_register_mutex vs sk_lock)
From: Stefano Garzarella @ 2026-04-09 11:07 UTC (permalink / raw)
To: weibo Zhang; +Cc: davem, edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <CADaZ31BntFddQpK8nnLtGccyKA-kw-usOHZwEscA70+dgB2WSw@mail.gmail.com>
On Thu, 9 Apr 2026 at 11:06, weibo Zhang <weibozhang2050@gmail.com> wrote:
>
> Hi,
>
> I am reporting a possible circular locking dependency (AB-BA deadlock) in the
>
> vsock subsystem between vsock_register_mutex and sk_lock-AF_VSOCK, found by
>
> syzkaller-based kernel fuzzing on Linux 6.12.47.
>
> The deadlock is detected by lockdep and involves two lock ordering paths:
>
> Path #1 (bind path): sk_lock → vsock_register_mutex
>
> vsock_bind() → lock_sock(sk) → __vsock_bind() → vsock_find_cid()
>
> → vsock_registered_transport_cid() → mutex_lock(&vsock_register_mutex)
>
> Path #2 (connect + transport reassignment): vsock_register_mutex → sk_lock
>
> vsock_connect() → vsock_assign_transport()
>
> → mutex_lock(&vsock_register_mutex) [line 469, af_vsock.c]
>
> → old transport->release(vsk) [line 502, af_vsock.c]
>
> → virtio_transport_release()
>
> → virtio_transport_close()
>
> → virtio_transport_wait_close()
>
> → lock_sock(sk) [line 1207, virtio_transport_common.c]
>
> The second path is triggered when a socket that already has a transport
>
> assigned (e.g., loopback from a previous CID_LOCAL connect) attempts to
>
> connect to a different CID (e.g., CID_HOST), causing vsock_assign_transport()
>
> to release the old transport while holding vsock_register_mutex.
>
>
> A possible fix would be to drop vsock_register_mutex before calling
>
> transport->release() in vsock_assign_transport(), or to avoid calling
Which is exactly what we did with
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c877e7535260cc7a21484c994e8ce7e8cb6780
This was released with v6.18 and backported on stable branches.
>
> lock_sock() from within the transport release path when called from
>
> vsock_assign_transport().
>
> This can be reproduced on:
>
> HEAD commit: Linux 6.12.47
v6.12.56 should contain the backport of that patch, can you test it
(or a newer version)?
Thanks,
Stefano
^ 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