* RE: [Intel-wired-lan] [PATCH iwl-next] ice: reduce loglevel to debug for 'Can't delete DSCP' message
From: Arland, ArpanaX @ 2026-04-22 12:17 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, Loktionov, Aleksandr
Cc: netdev@vger.kernel.org
In-Reply-To: <20260320050548.422684-1-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Aleksandr Loktionov
> Sent: Friday, March 20, 2026 10:36 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-next] ice: reduce loglevel to debug for 'Can't delete DSCP' message
>
> From: Grzegorz Nitka <grzegorz.nitka@intel.com>
>
> Reduce netdev message "Can't delete DSCP netlink app ..." from error to debug level when in FW (firmware) DCB mode.
> This is not a real error and a kind of expected behavior. The device is fully operational and error message might be wrongly interpreted by the user.
>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dcb_nl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* [PATCH net 0/1] pull request: fixes for ovpn 2026-04-22
From: Antonio Quartulli @ 2026-04-22 12:32 UTC (permalink / raw)
To: netdev
Cc: Antonio Quartulli, Sabrina Dubroca, Ralf Lici, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, David S. Miller, Eric Dumazet
Hello netdev team,
This PR is a new version of the one sent on March 20th.
We are trying to address a remote, yet possible, race condition between
tearing down an ovpn interface and adding new peers via netlink.
After further discussion including Jakub and Sabrina, the following
patch came up.
It should address all raised concerns.
Sorry for taking so long to get back to this.
Please pull or let mw know of any issue!
Thanks a lot,
Antonio
The following changes since commit 478ed6b7d2577439c610f91fa8759a4c878a4264:
net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change() (2026-04-21 15:00:39 +0200)
are available in the Git repository at:
https://github.com/OpenVPN/ovpn-net-next.git tags/ovpn-net-20260422
for you to fetch changes up to eac0dfc41d179d5f78d6d7ee401c63f48ba04b5a:
ovpn: fix race between deleting interface and adding new peer (2026-04-22 14:30:17 +0200)
----------------------------------------------------------------
Included change:
* fix race condition between interface teardown and new peer being
added via netlink
----------------------------------------------------------------
Antonio Quartulli (1):
ovpn: fix race between deleting interface and adding new peer
drivers/net/ovpn/main.c | 12 ++----------
drivers/net/ovpn/peer.c | 8 ++++++++
2 files changed, 10 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer
From: Antonio Quartulli @ 2026-04-22 12:32 UTC (permalink / raw)
To: netdev
Cc: Antonio Quartulli, Sabrina Dubroca, Ralf Lici, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, David S. Miller, Eric Dumazet,
Hyunwoo Kim
In-Reply-To: <20260422123242.530882-1-antonio@openvpn.net>
While deleting an existing ovpn interface, there is a very
narrow window where adding a new peer via netlink may cause
the netdevice to hang and prevent its unregistration.
It may happen during ovpn_dellink(), when all existing peers are
freed and the device is queued for deregistration, but a
CMD_PEER_NEW message comes in adding a new peer that takes again
a reference to the netdev.
At this point there is no way to release the device because we are
under the assumption that all peers were already released.
Fix the race condition by releasing all peers in ndo_uninit(),
when the netdevice has already been removed from the netdev
list. Also ovpn_peer_add() has now an extra check that
forces the function to bail out if the device reg_state is
UNREGISTERING (or later state).
This way any incoming CMD_PEER_NEW racing with the interface
deletion routine will simply stop before adding the peer.
At this point ovpn_dellink() becomes empty and can just be
removed.
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Closes: https://lore.kernel.org/netdev/aaVgJ16edTfQkYbx@v4bel/
Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
Fixes: 80747caef33d ("ovpn: introduce the ovpn_peer object")
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
---
drivers/net/ovpn/main.c | 12 ++----------
drivers/net/ovpn/peer.c | 8 ++++++++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
index 2e0420febda0..0eab305780c7 100644
--- a/drivers/net/ovpn/main.c
+++ b/drivers/net/ovpn/main.c
@@ -92,6 +92,8 @@ static void ovpn_net_uninit(struct net_device *dev)
{
struct ovpn_priv *ovpn = netdev_priv(dev);
+ cancel_delayed_work_sync(&ovpn->keepalive_work);
+ ovpn_peers_free(ovpn, NULL, OVPN_DEL_PEER_REASON_TEARDOWN);
gro_cells_destroy(&ovpn->gro_cells);
}
@@ -208,15 +210,6 @@ static int ovpn_newlink(struct net_device *dev,
return register_netdevice(dev);
}
-static void ovpn_dellink(struct net_device *dev, struct list_head *head)
-{
- struct ovpn_priv *ovpn = netdev_priv(dev);
-
- cancel_delayed_work_sync(&ovpn->keepalive_work);
- ovpn_peers_free(ovpn, NULL, OVPN_DEL_PEER_REASON_TEARDOWN);
- unregister_netdevice_queue(dev, head);
-}
-
static int ovpn_fill_info(struct sk_buff *skb, const struct net_device *dev)
{
struct ovpn_priv *ovpn = netdev_priv(dev);
@@ -235,7 +228,6 @@ static struct rtnl_link_ops ovpn_link_ops = {
.policy = ovpn_policy,
.maxtype = IFLA_OVPN_MAX,
.newlink = ovpn_newlink,
- .dellink = ovpn_dellink,
.fill_info = ovpn_fill_info,
};
diff --git a/drivers/net/ovpn/peer.c b/drivers/net/ovpn/peer.c
index c02dfab51a6e..8ef485a8c851 100644
--- a/drivers/net/ovpn/peer.c
+++ b/drivers/net/ovpn/peer.c
@@ -1034,6 +1034,14 @@ static int ovpn_peer_add_p2p(struct ovpn_priv *ovpn, struct ovpn_peer *peer)
*/
int ovpn_peer_add(struct ovpn_priv *ovpn, struct ovpn_peer *peer)
{
+ /* Prevent adding new peers while destroying the ovpn interface.
+ * Failing to do so would end up holding the device reference
+ * endlessly hostage of the new peer object with no chance of
+ * release..
+ */
+ if (ovpn->dev->reg_state >= NETREG_UNREGISTERING)
+ return -ENODEV;
+
switch (ovpn->mode) {
case OVPN_MODE_MP:
return ovpn_peer_add_mp(ovpn, peer);
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] ice: ptp: fix E825 timer synchronization and locking
From: Grzegorz Nitka @ 2026-04-22 12:31 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, anthony.l.nguyen, przemyslaw.kitszel, Grzegorz Nitka
These two fixes address E825 PTP synchronization issues in
ice_ptp_hw.c.
The first patch serializes PHY timer start against concurrent PTP
command paths by holding the global PTP semaphore while programming
TIMETUS registers and issuing INIT_INCVAL.
The second patch fixes semaphore access for E825 2xNAC configurations by
making ice_ptp_lock() and ice_ptp_unlock() use the primary NAC register
block, matching the rest of the primary-only PTP register access path.
Together, the series closes two locking gaps in E825 timer control: one
during PHY timer initialization and one in 2xNAC semaphore selection.
Grzegorz Nitka (2):
ice: ptp: serialize E825 PHY timer start with PTP lock
ice: ptp: use primary NAC semaphore on E825
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 24 +++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
base-commit: 3662329d3f304a421e0230ee3913dab021ec3a3d
--
2.39.3
^ permalink raw reply
* [PATCH iwl-net 1/2] ice: ptp: serialize E825 PHY timer start with PTP lock
From: Grzegorz Nitka @ 2026-04-22 12:31 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, anthony.l.nguyen, przemyslaw.kitszel, Grzegorz Nitka,
Arkadiusz Kubalewski
In-Reply-To: <20260422123144.485930-1-grzegorz.nitka@intel.com>
ice_start_phy_timer_eth56g() programs TIMETUS registers and issues
INIT_INCVAL without holding the global PTP semaphore.
This allows concurrent PTP command paths to interleave with PHY timer
start, which can make the sequence fail and leave timer initialization
inconsistent.
Take the PTP lock around TIMETUS registers programming and INIT_INCVAL
command execution, and make sure the lock is released on all error paths.
Keep the subsequent sync step outside of this critical section, since
ice_sync_phy_timer_eth56g() takes the same semaphore internally.
Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index 672218e5d1f9..8bb94e785f2a 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -2141,16 +2141,23 @@ int ice_start_phy_timer_eth56g(struct ice_hw *hw, u8 port)
}
incval = (u64)hi << 32 | lo;
+ if (!ice_ptp_lock(hw)) {
+ dev_err(ice_hw_to_dev(hw), "Failed to acquire PTP semaphore\n");
+ return -EBUSY;
+ }
+
err = ice_write_40b_ptp_reg_eth56g(hw, port, PHY_REG_TIMETUS_L, incval);
if (err)
- return err;
+ goto err_ptp_unlock;
err = ice_ptp_one_port_cmd(hw, port, ICE_PTP_INIT_INCVAL);
if (err)
- return err;
+ goto err_ptp_unlock;
ice_ptp_exec_tmr_cmd(hw);
+ ice_ptp_unlock(hw);
+
err = ice_sync_phy_timer_eth56g(hw, port);
if (err)
return err;
@@ -2166,6 +2173,10 @@ int ice_start_phy_timer_eth56g(struct ice_hw *hw, u8 port)
ice_debug(hw, ICE_DBG_PTP, "Enabled clock on PHY port %u\n", port);
return 0;
+
+err_ptp_unlock:
+ ice_ptp_unlock(hw);
+ return err;
}
/**
--
2.39.3
^ permalink raw reply related
* [PATCH iwl-net 2/2] ice: ptp: use primary NAC semaphore on E825
From: Grzegorz Nitka @ 2026-04-22 12:31 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, anthony.l.nguyen, przemyslaw.kitszel, Grzegorz Nitka,
Arkadiusz Kubalewski
In-Reply-To: <20260422123144.485930-1-grzegorz.nitka@intel.com>
For E825 2xNAC configurations, PTP semaphore operations must hit the
primary NAC register block so both sides coordinate on the same lock.
Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
devices") updated other primary-only PTP register accesses to
use the primary NAC on non-primary functions, but left ice_ptp_lock()
and ice_ptp_unlock() operating on the local NAC. As a result, secondary
NAC PTP paths can take a different semaphore than the primary side.
Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock() when
the current function is not primary, keeping semaphore operations
symmetric and consistent with the rest of the 2xNAC PTP register access
path.
Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices")
Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index 8bb94e785f2a..2c18e16fe053 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -5264,9 +5264,13 @@ static void ice_ptp_init_phy_e830(struct ice_ptp_hw *ptp)
*/
bool ice_ptp_lock(struct ice_hw *hw)
{
+ struct ice_pf *pf = container_of(hw, struct ice_pf, hw);
u32 hw_lock;
int i;
+ if (!ice_is_primary(hw))
+ hw = ice_get_primary_hw(pf);
+
#define MAX_TRIES 15
for (i = 0; i < MAX_TRIES; i++) {
@@ -5293,6 +5297,11 @@ bool ice_ptp_lock(struct ice_hw *hw)
*/
void ice_ptp_unlock(struct ice_hw *hw)
{
+ struct ice_pf *pf = container_of(hw, struct ice_pf, hw);
+
+ if (!ice_is_primary(hw))
+ hw = ice_get_primary_hw(pf);
+
wr32(hw, PFTSYN_SEM + (PFTSYN_SEM_BYTES * hw->pf_id), 0);
}
--
2.39.3
^ permalink raw reply related
* [PATCH net v3 0/2] tcp: symmetric challenge ACK for SEG.ACK > SND.NXT
From: Jiayuan Chen @ 2026-04-22 12:35 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, David Ahern, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan, linux-kernel, linux-kselftest
Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack
Mitigation") quotes RFC 5961 Section 5.2 in full, which requires
that any incoming segment whose ACK value falls outside
[SND.UNA - MAX.SND.WND, SND.NXT] MUST be discarded and an ACK sent
back. Linux currently sends that challenge ACK only on the lower
edge (SEG.ACK < SND.UNA - MAX.SND.WND); on the symmetric upper edge
(SEG.ACK > SND.NXT) the segment is silently dropped with
SKB_DROP_REASON_TCP_ACK_UNSENT_DATA.
Patch 1 completes the mitigation by emitting a rate-limited challenge
ACK on that branch, reusing tcp_send_challenge_ack() and honouring
FLAG_NO_CHALLENGE_ACK for consistency with the lower-edge case. It
also updates the existing tcp_ts_recent_invalid_ack.pkt selftest,
which drives this exact path, to consume the new challenge ACK so
bisect stays clean.
Patch 2 adds a new packetdrill selftest that exercises RFC 5961
Section 5.2 on both edges of the acceptable window, filling a gap in
the selftests tree (neither edge had dedicated coverage before).
---
Changelog
=========
v2 -> v3:
- I don't think the AI's concern holds, but I think I can split write(2000)
into write(1000) so the test doesn't rely on kernel internals.
sashiko: https://sashiko.dev/#/patchset/20260421014128.289362-1-jiayuan.chen%40linux.dev
v1 -> v2:
- Add Reviewed-by tag.
- Fold the tcp_ts_recent_invalid_ack.pkt update into patch 1 so
that bisect stays clean and the fix is self-contained for
backport.
- Extend the new selftest to cover both edges of RFC 5961
Section 5.2 (SEG.ACK > SND.NXT and SEG.ACK < SND.UNA -
MAX.SND.WND) in a single connection, and rename it to
tcp_rfc5961_ack-out-of-window.pkt. Neither edge had explicit
packetdrill coverage before.
v1: https://lore.kernel.org/netdev/20260420025428.101192-1-jiayuan.chen@linux.dev/
Jiayuan Chen (2):
tcp: send a challenge ACK on SEG.ACK > SND.NXT
selftests/net: packetdrill: cover RFC 5961 5.2 challenge ACK on both
edges
net/ipv4/tcp_input.c | 10 ++--
.../tcp_rfc5961_ack-out-of-window.pkt | 48 +++++++++++++++++++
.../packetdrill/tcp_ts_recent_invalid_ack.pkt | 4 +-
3 files changed, 58 insertions(+), 4 deletions(-)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of-window.pkt
--
2.43.0
^ permalink raw reply
* [PATCH net v3 1/2] tcp: send a challenge ACK on SEG.ACK > SND.NXT
From: Jiayuan Chen @ 2026-04-22 12:35 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, David Ahern, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260422123605.320000-1-jiayuan.chen@linux.dev>
RFC 5961 Section 5.2 validates an incoming segment's ACK value
against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states:
"All incoming segments whose ACK value doesn't satisfy the above
condition MUST be discarded and an ACK sent back."
Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack
Mitigation") opted Linux into this mitigation and implements the
challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND),
but the symmetric upper side (SEG.ACK > SND.NXT) still takes the
pre-RFC-5961 path and silently returns
SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9
(now RFC 9293 Section 3.10.7.4) has always required:
"If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT)
then send an ACK, drop the segment, and return."
Complete the mitigation by sending a challenge ACK on that branch,
reusing the existing tcp_send_challenge_ack() path which already
enforces the per-socket RFC 5961 Section 7 rate limit via
__tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for
symmetry with the lower-edge case.
Update the existing tcp_ts_recent_invalid_ack.pkt selftest, which
drives this exact path, to consume the new challenge ACK.
Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp_input.c | 10 +++++++---
.../net/packetdrill/tcp_ts_recent_invalid_ack.pkt | 4 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 021f745747c5..c2b6f05acdfa 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4284,11 +4284,15 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
goto old_ack;
}
- /* If the ack includes data we haven't sent yet, discard
- * this segment (RFC793 Section 3.9).
+ /* If the ack includes data we haven't sent yet, drop the
+ * segment. RFC 793 Section 3.9 and RFC 5961 Section 5.2
+ * require us to send an ACK back in that case.
*/
- if (after(ack, tp->snd_nxt))
+ if (after(ack, tp->snd_nxt)) {
+ if (!(flag & FLAG_NO_CHALLENGE_ACK))
+ tcp_send_challenge_ack(sk, false);
return -SKB_DROP_REASON_TCP_ACK_UNSENT_DATA;
+ }
if (after(ack, prior_snd_una)) {
flag |= FLAG_SND_UNA_ADVANCED;
diff --git a/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt b/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt
index 174ce9a1bfc0..ee6baf7c36cf 100644
--- a/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt
+++ b/tools/testing/selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt
@@ -19,7 +19,9 @@
// bad packet with high tsval (its ACK sequence is above our sndnxt)
+0 < F. 1:1(0) ack 9999 win 20000 <nop,nop,TS val 200000 ecr 100>
-
+// Challenge ACK for SEG.ACK > SND.NXT (RFC 5961 5.2 / RFC 793 3.9).
+// ecr=200 (not 200000) proves ts_recent was not updated from the bad packet.
+ +0 > . 1:1(0) ack 1 <nop,nop,TS val 200 ecr 200>
+0 < . 1:1001(1000) ack 1 win 20000 <nop,nop,TS val 201 ecr 100>
+0 > . 1:1(0) ack 1001 <nop,nop,TS val 200 ecr 201>
--
2.43.0
^ permalink raw reply related
* [PATCH net v3 2/2] selftests/net: packetdrill: cover RFC 5961 5.2 challenge ACK on both edges
From: Jiayuan Chen @ 2026-04-22 12:35 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, David Ahern, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260422123605.320000-1-jiayuan.chen@linux.dev>
RFC 5961 Section 5.2 / RFC 793 Section 3.9 require a challenge ACK
whenever an incoming SEG.ACK falls outside
[SND.UNA - MAX.SND.WND, SND.NXT]. There is currently no packetdrill
coverage for either edge.
Add tcp_rfc5961_ack-out-of-window.pkt, which in a single passive-open
connection exercises:
- Upper edge (SEG.ACK > SND.NXT): peer ACKs data that was never
sent before the server has transmitted anything.
- Lower edge (SEG.ACK < SND.UNA - MAX.SND.WND): after the server
has sent 2000 bytes (the peer-advertised rwnd forces two 1000-byte
segments, both acknowledged), peer sends an ACK that is older
than the acceptable window.
Both cases must elicit a challenge ACK
<SEQ = SND.NXT, ACK = RCV.NXT, CTL = ACK>. The per-socket RFC 5961
Section 7 rate limit is disabled for the duration of the test so that
both challenge ACKs can fire back-to-back.
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
.../tcp_rfc5961_ack-out-of-window.pkt | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of-window.pkt
diff --git a/tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of-window.pkt b/tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of-window.pkt
new file mode 100644
index 000000000000..2776b8728085
--- /dev/null
+++ b/tools/testing/selftests/net/packetdrill/tcp_rfc5961_ack-out-of-window.pkt
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// RFC 5961 Section 5.2 / RFC 793 Section 3.9: an incoming segment's
+// ACK value must lie in [SND.UNA - MAX.SND.WND, SND.NXT]; otherwise
+// the receiver MUST discard the segment and send a challenge ACK
+// back. Exercise both edges of that window in a single connection.
+
+`./defaults.sh
+sysctl -q net.ipv4.tcp_invalid_ratelimit=0
+`
+
+ 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+ +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+ +0 bind(3, ..., ...) = 0
+ +0 listen(3, 1) = 0
+
+// Three-way handshake. Peer advertises rwnd = 1000 (no wscale), so
+// MAX.SND.WND is tracked as 1000.
+ +0 < S 0:0(0) win 1000 <mss 1000,sackOK,nop,nop,nop,wscale 0>
+ +0 > S. 0:0(0) ack 1 <...>
++.1 < . 1:1(0) ack 1 win 1000
+ +0 accept(3, ..., ...) = 4
+
+// ---- Upper edge: SEG.ACK > SND.NXT --------------------------------
+// Server has sent nothing yet, so SND.UNA = SND.NXT = 1.
+// Peer sends a pure ACK with SEG.ACK = 2, beyond SND.NXT.
+ +0 < . 1:1(0) ack 2 win 1000
+// Expect a challenge ACK: <SEQ = SND.NXT = 1, ACK = RCV.NXT = 1>.
+ +0 > . 1:1(0) ack 1
+
+// Advance SND.UNA past MAX.SND.WND so that the lower edge becomes
+// reachable. Issue two 1-MSS writes so each skb is exactly one MSS
+// and PSH is set by tcp_push() at the end of each sendmsg, keeping
+// the setup independent of the TSO / tcp_fragment split path.
+ +0 write(4, ..., 1000) = 1000
+ +0 > P. 1:1001(1000) ack 1
++.01 < . 1:1(0) ack 1001 win 1000
+ +0 write(4, ..., 1000) = 1000
+ +0 > P. 1001:2001(1000) ack 1
++.01 < . 1:1(0) ack 2001 win 1000
+// Now SND.UNA = SND.NXT = 2001, MAX.SND.WND = 1000, bytes_acked = 2000.
+
+// ---- Lower edge: SEG.ACK < SND.UNA - MAX.SND.WND ------------------
+// SND.UNA - MAX.SND.WND = 2001 - 1000 = 1001, so SEG.ACK = 1000 falls
+// below the acceptable range.
+ +0 < . 1:1(0) ack 1000 win 1000
+// Expect a challenge ACK: <SEQ = SND.NXT = 2001, ACK = RCV.NXT = 1>.
+ +0 > . 2001:2001(0) ack 1
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] rxrpc: fix missing validation of ticket length in
From: David Howells @ 2026-04-22 12:37 UTC (permalink / raw)
To: Anderson Nascimento
Cc: dhowells, Marc Dionne, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Steve Dickson,
linux-afs, netdev, linux-kernel
In-Reply-To: <20260422003206.1017863-1-anderson@allelesecurity.com>
> Subject: [PATCH] rxrpc: fix missing validation of ticket length in
...in rxrpc_preparse(), I presume?
David
^ permalink raw reply
* Re: [PATCH net v3 1/1] net: hsr: limit node table growth
From: Felix Maurer @ 2026-04-22 12:38 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Ren Wei, netdev, davem, edumazet, kuba, pabeni, horms, kees,
kexinsun, luka.gejak, m-karicheri2, yuantan098, yifanwucs,
tomapufckgml, bird, xuyuqiabc, royenheart
In-Reply-To: <20260422105854.trLbmAmZ@linutronix.de>
On Wed, Apr 22, 2026 at 12:58:54PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-04-22 11:45:38 [+0200], Felix Maurer wrote:
> > > I don't think the node count exceeds 100 in production. So having a
> > > counter which is incremented while adding to the list and decremented
> > > while removing items from the list would optimize the "worst case". So
> > > instead traversing the list with 1000 we would just give up.
> >
> > The counter is what I had in mind. I agree that allocating under the
> > lock isn't what we want.
> >
> > I'd argue counting through the whole list is the normal case.
>
> yeah but counting here is just a register increment which is cheap.
>
> > hsr_add_node() is only called after the node table has been searched
> > already (without the lock). Here we go through the whole list again
> > under the lock to prevent TOCTOU-type situations.
> >
> > I agree that, overall, it would be optimizing the worst case, but I
> > think it may be worth it to prevent the memory allocations and walking
> > the whole list. But I'd go along with the (current) on-the-fly counting
> > as well.
>
> Yeah. But then you have to manage the counter on add and removal just
> for this "we have too many nodes" case. And theoretically you would have
> to hold the list_lock while checking the counter because nodes might be
> added on both sides in the RX path (unless you check early lockless &
> optimistic and then again before adding under the lock).
Alright, I agree. Let's keep this part as it is (counting while iterting
through the list).
Thanks,
Felix
^ permalink raw reply
* Re: [PATCH net 14/18] drivers: net: xircom: xirc2ps: Remove this driver
From: michael @ 2026-04-22 12:46 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, linux-kernel, netdev,
linux-doc
In-Reply-To: <408d1987-6ecb-4d3b-afed-8e202c8ff21d@lunn.ch>
Am 2026-04-22 14:15, schrieb Andrew Lunn:
> On Wed, Apr 22, 2026 at 08:21:23AM +0200, Michael Fritscher wrote:
>> Good day,
>>
>> actually, I do use Xircom PCMCIA network cards (yes, the 16 bit ones)
>> on
>> Lenovo X60/X61 laptops as a second LAN card for server maintenances
>> with
>> current 64 bit distros (e.g. Debian Trixie, which I plan to update to
>> Trixie+1 when available). Why? Because I have them and they are
>> working ;-)
>
> Hi Michael
>
> I will drop this from the patchset for the moment.
>
> Would you be willing to take up the Maintainer role for it?
>
> Andrew
Hello Andrew,
thanks! If someone mentors me I could try... I have experience with C
programming, esp. in the embedded world, but (almost) no experience with
the Linux kernel development.
But regression tests etc. can be conducted by me - on 32 and 64 bit
machines. The oldest being a P120, the newest the mentioned X61 with its
C2D CPU.
Best regards
Michael
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Andrew Lunn @ 2026-04-22 12:47 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <aeiJ3zr4WJAm1UCk@AMDC4622.eu.corp.samsungelectronics.net>
> I don't see anything wrong with it?
> - naming is correct, same as stmmac_extra_stats from common.h, as it
> wouldn't compile otherwise
> - string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
> not close
> - ethtool just polls data from driver and in my tests it is ok
> - all instances of 'undeflow' are changed
> - 'underflow' semantic is ok, 'undeflow' is just not correct
>
> Please correct me if I am wrong, but imo no issues with this patch.
ABI
This name is published as part of the kAPI. You are changing its
name. User space could be looking for this name, even thought it has a
typo in it.
Andrew
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: ptp: serialize E825 PHY timer start with PTP lock
From: Loktionov, Aleksandr @ 2026-04-22 12:47 UTC (permalink / raw)
To: Nitka, Grzegorz, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Kubalewski, Arkadiusz, Nguyen, Anthony L,
Kitszel, Przemyslaw
In-Reply-To: <20260422123144.485930-2-grzegorz.nitka@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Grzegorz Nitka
> Sent: Wednesday, April 22, 2026 2:32 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: ptp: serialize
> E825 PHY timer start with PTP lock
>
> ice_start_phy_timer_eth56g() programs TIMETUS registers and issues
> INIT_INCVAL without holding the global PTP semaphore.
>
> This allows concurrent PTP command paths to interleave with PHY timer
> start, which can make the sequence fail and leave timer initialization
> inconsistent.
>
> Take the PTP lock around TIMETUS registers programming and INIT_INCVAL
> command execution, and make sure the lock is released on all error
> paths.
>
> Keep the subsequent sync step outside of this critical section, since
> ice_sync_phy_timer_eth56g() takes the same semaphore internally.
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C
> products")
> Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
I recommend to add Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> index 672218e5d1f9..8bb94e785f2a 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> @@ -2141,16 +2141,23 @@ int ice_start_phy_timer_eth56g(struct ice_hw
> *hw, u8 port)
> }
> incval = (u64)hi << 32 | lo;
>
> + if (!ice_ptp_lock(hw)) {
> + dev_err(ice_hw_to_dev(hw), "Failed to acquire PTP
> semaphore\n");
> + return -EBUSY;
> + }
> +
> err = ice_write_40b_ptp_reg_eth56g(hw, port, PHY_REG_TIMETUS_L,
> incval);
> if (err)
> - return err;
> + goto err_ptp_unlock;
>
> err = ice_ptp_one_port_cmd(hw, port, ICE_PTP_INIT_INCVAL);
> if (err)
> - return err;
> + goto err_ptp_unlock;
>
> ice_ptp_exec_tmr_cmd(hw);
>
> + ice_ptp_unlock(hw);
> +
> err = ice_sync_phy_timer_eth56g(hw, port);
> if (err)
> return err;
> @@ -2166,6 +2173,10 @@ int ice_start_phy_timer_eth56g(struct ice_hw
> *hw, u8 port)
> ice_debug(hw, ICE_DBG_PTP, "Enabled clock on PHY port %u\n",
> port);
>
> return 0;
> +
> +err_ptp_unlock:
> + ice_ptp_unlock(hw);
> + return err;
> }
>
> /**
> --
> 2.39.3
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 2/2] ice: ptp: use primary NAC semaphore on E825
From: Loktionov, Aleksandr @ 2026-04-22 12:48 UTC (permalink / raw)
To: Nitka, Grzegorz, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Kubalewski, Arkadiusz, Nguyen, Anthony L,
Kitszel, Przemyslaw
In-Reply-To: <20260422123144.485930-3-grzegorz.nitka@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Grzegorz Nitka
> Sent: Wednesday, April 22, 2026 2:32 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 2/2] ice: ptp: use primary
> NAC semaphore on E825
>
> For E825 2xNAC configurations, PTP semaphore operations must hit the
> primary NAC register block so both sides coordinate on the same lock.
>
> Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
> devices") updated other primary-only PTP register accesses to use the
> primary NAC on non-primary functions, but left ice_ptp_lock() and
> ice_ptp_unlock() operating on the local NAC. As a result, secondary
> NAC PTP paths can take a different semaphore than the primary side.
>
> Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock()
> when the current function is not primary, keeping semaphore operations
> symmetric and consistent with the rest of the 2xNAC PTP register
> access path.
>
> Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
> devices")
> Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
I recommend to add Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> index 8bb94e785f2a..2c18e16fe053 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> @@ -5264,9 +5264,13 @@ static void ice_ptp_init_phy_e830(struct
> ice_ptp_hw *ptp)
> */
> bool ice_ptp_lock(struct ice_hw *hw)
> {
> + struct ice_pf *pf = container_of(hw, struct ice_pf, hw);
> u32 hw_lock;
> int i;
>
> + if (!ice_is_primary(hw))
> + hw = ice_get_primary_hw(pf);
> +
> #define MAX_TRIES 15
>
> for (i = 0; i < MAX_TRIES; i++) {
> @@ -5293,6 +5297,11 @@ bool ice_ptp_lock(struct ice_hw *hw)
> */
> void ice_ptp_unlock(struct ice_hw *hw)
> {
> + struct ice_pf *pf = container_of(hw, struct ice_pf, hw);
> +
> + if (!ice_is_primary(hw))
> + hw = ice_get_primary_hw(pf);
> +
> wr32(hw, PFTSYN_SEM + (PFTSYN_SEM_BYTES * hw->pf_id), 0); }
>
> --
> 2.39.3
^ permalink raw reply
* Re: [PATCH net 06/18] drivers: net: amd: Remove hplance and mvme147
From: Andrew Lunn @ 2026-04-22 12:50 UTC (permalink / raw)
To: Daniel Palmer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
linux-kernel, netdev, linux-doc
In-Reply-To: <CAFr9PXk=3md2oVDqFbmQLNiVMkRr32pHMPNSeskdTpM-1huB=A@mail.gmail.com>
On Wed, Apr 22, 2026 at 06:38:28AM +0900, Daniel Palmer wrote:
> Hi Andrew,
>
> On Wed, 22 Apr 2026 at 04:39, Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > These drivers use the 7990 core with wrappers for the HP300 and
> > Motorola MVME147 SBC circa 1998. It is unlikely they are used with a
> > modern kernel.
>
> I have an MVME147 blinking away running mainline using the mvme147 driver.
> I think some of these need to be CC'd to the specific arch lists so
> the few people using them get a chance to pipe up.
That is part of the problem. No MAINTAINERs entry. so
./scripts/get_maintainers.py does not add an Cc: to the list.
> I think I'm the last person to have touched the mvme147, I don't mind
> being a maintainer for it.
Please submit an entry for MAINTAINERs.
I will drop this patch.
Andrew
^ permalink raw reply
* Re: [PATCH] rxrpc: fix missing validation of ticket length in
From: Anderson Nascimento @ 2026-04-22 12:52 UTC (permalink / raw)
To: David Howells
Cc: Marc Dionne, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steve Dickson, linux-afs, netdev,
linux-kernel
In-Reply-To: <2475724.1776861474@warthog.procyon.org.uk>
On Wed, Apr 22, 2026 at 9:38 AM David Howells <dhowells@redhat.com> wrote:
>
> > Subject: [PATCH] rxrpc: fix missing validation of ticket length in
>
> ...in rxrpc_preparse(), I presume?
>
In fact it was "non-XDR key preparsing", but "in rxrpc_preparse()" also works.
> David
>
--
Anderson Nascimento
Allele Security Intelligence
https://www.allelesecurity.com
^ permalink raw reply
* Re: [PATCH 1/2] net: packetengines: remove obsolete hamachi driver
From: Andrew Lunn @ 2026-04-22 13:04 UTC (permalink / raw)
To: Mingyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <20260422044820.485660-2-25181214217@stu.xidian.edu.cn>
On Wed, Apr 22, 2026 at 12:48:19PM +0800, Mingyu Wang wrote:
> The PacketEngine Hamachi driver is for PCI hardware that has been
> obsolete for over two decades. It recently triggered arithmetic
> exceptions during automated fuzzing.
>
> As suggested by maintainers, remove the driver entirely to eliminate
> dead code and reduce the maintenance burden.
>
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] net: packetengines: remove obsolete yellowfin driver and vendor dir
From: Andrew Lunn @ 2026-04-22 13:04 UTC (permalink / raw)
To: Mingyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <20260422044820.485660-3-25181214217@stu.xidian.edu.cn>
On Wed, Apr 22, 2026 at 12:48:20PM +0800, Mingyu Wang wrote:
> Similar to the hamachi driver, the yellowfin driver supports hardware
> that is over two decades old and no longer in active use.
>
> Since yellowfin was the last remaining driver in the packetengines
> vendor directory, we can now safely remove the entire directory and
> drop its associated references from the parent Kconfig and Makefile.
>
> This eliminates dead code and reduces the overall maintenance burden
> on the netdev subsystem.
>
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-22 13:05 UTC (permalink / raw)
To: Jakub Kicinski, davem, openwrt-devel, Guy Ellis
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <20260422041846.2035118-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
On Tue, 2026-04-21 at 21:18 -0700, Jakub Kicinski wrote:
>
> I'm still deleting the solos driver, chances are nobody uses it.
> Easy enough to revert back in since core is still around.
> The guiding principle is to keep USB modems and delete
> the rest as USB ADSL2+ CPEs were most popular historically.
Still not entirely convinced; I worked on both USB ATM modems and on
Solos, and the Solos is both the most modern and the only one I still
actually have. And the only one we have native support for that could
ever do full 24Mb/s ADSL2+, I believe.
If we drop it, OpenWrt will need to drop support for these, which I
think were quite popular at the time; there were a few UK resellers:
https://openwrt.org/toh/traverse/geos1_1
I still don't actually care *enough* to try to find an ADSL line I
could plug one into for testing though... :)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH net 14/18] drivers: net: xircom: xirc2ps: Remove this driver
From: Andrew Lunn @ 2026-04-22 13:09 UTC (permalink / raw)
To: michael
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, linux-kernel, netdev,
linux-doc
In-Reply-To: <e36510873a1909a1bfd9a05cde99fef0@fritscher.net>
> thanks! If someone mentors me I could try... I have experience with C
> programming, esp. in the embedded world, but (almost) no experience with the
> Linux kernel development.
> But regression tests etc. can be conducted by me - on 32 and 64 bit
> machines. The oldest being a P120, the newest the mentioned X61 with its C2D
> CPU.
For a driver like this, regression testing is mostly what we need,
when we see patches for it.
Please take a look at the MAINTAINERs file, and see if you can send us
a patch adding yourself as the Maintainer of this driver.
Some documents to read:
https://docs.kernel.org/process/submitting-patches.html
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
For patches to MAINTAINERS, please base the patch on net.
Andrew
^ permalink raw reply
* Re: Path forward for NFC in the kernel
From: David Heidelberg @ 2026-04-22 13:11 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Krzysztof Kozlowski, Michael Thalmeier, Raymond Hackley,
Michael Walle, Bongsu Jeon, Mark Greer, netdev, oe-linux-nfc
In-Reply-To: <20260421071044.67a3cee1@kernel.org>
On 21/04/2026 16:10, Jakub Kicinski wrote:
> On Fri, 17 Apr 2026 10:12:22 +0200 David Heidelberg wrote:
>>> +Cc David Heidelberg recently trying to use Linux NFC stack,
>>>
>>> Just "collecting" patches is not a big deal, I could do this, but
>>> actually reviewing the patches with necessary due diligence is the
>>> effort I could not provide in a reasonable time frame. And picking up
>>> patches without proper review feels risky...
>>
>> Hello Krzystof, Jakub,
>>
>> thanks for putting me into loop.
>>
>> I can do limited reviews and basic maintenance. My knowledge about NFC is for
>> now somehow limited (but I'm willing to invest my limited time into learning more).
>>
>> As "I & LLM" wrote [1] userspace very basic reader for GNOME and planning to do
>> more tight integration into GNOME, so would make sense to keep the kernel stack
>> alive.
>
> Hi David!
>
> Sorry for the delay, we (core maintainers) discussed the situation
> off-list and since our choices are either delete all this code or give
> you a chance, everyone agreed that the latter is strictly better :)
> It's a little unusual to designate someone who doesn't have a proven
> track record acting as a de facto maintainer, but such are the times...
>
> Our expectation would be that:
> - you'd create your own tree to gather NFC patches and send us
> periodic pull requests every 2 or 3 weeks, with what you gathered
> - act upon submissions within 48h of posting (excluding weekends)
>
> Of course we'll happy to provide any support and guidance you need,
> specially for the first few months.
>
> Is this what you had in mind? The phrase "limited reviews and basic
> maintenance" is slightly worrying, we assumed it's an expression of
> modesty rather than commitment? :)
Hi,
thanks for giving me the opportunity - I appreciate the trust, especially given
the circumstances.
Yes, this is broadly in line with what I had in mind. To clarify the “limited
reviews and basic maintenance” phrasing: that was more an attempt to set
expectations conservatively. I’m prepared to take on the responsibilities you
outlined — maintaining a tree, collecting and triaging patches, and sending
regular pull requests.
Regarding reviews and responsiveness: I can do the 48h turnaround for initial
feedback on submissions (excluding weekends, and occasional travel), and I’ll
make sure no patch sits unattended. For more complex changes where my current
NFC-specific knowledge may be a limiting factor, I’ll seek input rather than let
things stall.
I’m also planning to ramp up my familiarity with the NFC stack as I go, so I
expect both the quality and depth of my reviews to improve over time.
If that works for you, I’ll proceed with setting up a public tree and start
tracking incoming patches.
Thanks again for the support - I’ll likely take you up on that, especially early on.
Best regards,
David
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Nikolay Aleksandrov @ 2026-04-22 13:17 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, idosch,
jani.nikula, mchehab+huawei, tytso, herbert, geert, ebiggers,
johannes.berg, jonathan.cameron, kees, kuniyu, fourier.thomas,
andriy.shevchenko, rdunlap, akpm, linux-doc, linux-mips,
linuxppc-dev, bridge, dwmw2
In-Reply-To: <20260422041846.2035118-1-kuba@kernel.org>
On 22/04/2026 07:18, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, BR2684, and USB DSL modem
> drivers (drivers/usb/atm/) are retained in-tree to maintain PPP
> over ATM (PPPoA) and PPPoE-over-BR2684 support for DSL connections.
>
> Removed ATM protocol modules:
> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
> - net/atm/lec.c - LAN Emulation Client (LANE)
> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>
> Removed PCI/SBUS ATM device drivers (drivers/atm/):
> - adummy, atmtcp - software/testing ATM devices
> - eni - Efficient Networks ENI155P (OC-3, ~1995)
> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
> - he - ForeRunner HE (OC-3/OC-12, ~2000)
> - idt77105 - IDT 77105 25 Mbps ATM PHY
> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
> - lanai - Efficient Networks Speedstream 3010
> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
> - solos-pci - Traverse Technologies ADSL2+ PCI
> - suni - PMC S/UNI SONET PHY library
>
> Also clean up references in:
> - net/bridge/ - remove ATM LANE hook (br_fdb_test_addr_hook,
> br_fdb_test_addr)
> - net/core/dev.c - remove br_fdb_test_addr_hook export
> - defconfig files - remove ATM driver config options
>
> The removed code is moved to an out-of-tree module package (mod-orphan).
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> v2:
> - keep BR2684
> - correct the claim that Traverse Technologies is defunct,
> I'm still deleting the solos driver, chances are nobody uses it.
> Easy enough to revert back in since core is still around.
> The guiding principle is to keep USB modems and delete
> the rest as USB ADSL2+ CPEs were most popular historically.
> v1: https://lore.kernel.org/20260421021943.1295109-1-kuba@kernel.org
>
> CC: corbet@lwn.net
> CC: skhan@linuxfoundation.org
> CC: linux@armlinux.org.uk
> CC: tsbogend@alpha.franken.de
> CC: maddy@linux.ibm.com
> CC: mpe@ellerman.id.au
> CC: npiggin@gmail.com
> CC: chleroy@kernel.org
> CC: 3chas3@gmail.com
> CC: razor@blackwall.org
> CC: idosch@nvidia.com
> CC: jani.nikula@intel.com
> CC: mchehab+huawei@kernel.org
> CC: tytso@mit.edu
> CC: herbert@gondor.apana.org.au
> CC: geert@linux-m68k.org
> CC: ebiggers@kernel.org
> CC: johannes.berg@intel.com
> CC: jonathan.cameron@huawei.com
> CC: kees@kernel.org
> CC: kuniyu@google.com
> CC: fourier.thomas@gmail.com
> CC: andriy.shevchenko@intel.com
> CC: rdunlap@infradead.org
> CC: akpm@linux-foundation.org
> CC: linux-doc@vger.kernel.org
> CC: linux-mips@vger.kernel.org
> CC: linuxppc-dev@lists.ozlabs.org
> CC: bridge@lists.linux.dev
> CC: dwmw2@infradead.org
> CC: herbert@gondor.apana.org.au
> ---
> MAINTAINERS | 3 +-
> Documentation/.renames.txt | 2 -
> .../device_drivers/atm/fore200e.rst | 66 -
> .../networking/device_drivers/atm/index.rst | 2 -
> .../networking/device_drivers/atm/iphase.rst | 193 -
> drivers/atm/Kconfig | 325 --
> drivers/net/Kconfig | 2 -
> net/atm/Kconfig | 37 -
> drivers/Makefile | 1 -
> drivers/atm/Makefile | 32 -
> net/atm/Makefile | 4 -
> drivers/atm/eni.h | 136 -
> drivers/atm/fore200e.h | 973 -----
> drivers/atm/he.h | 845 ----
> drivers/atm/idt77105.h | 92 -
> drivers/atm/idt77252.h | 816 ----
> drivers/atm/idt77252_tables.h | 781 ----
> drivers/atm/iphase.h | 1452 -------
> drivers/atm/midway.h | 266 --
> drivers/atm/nicstar.h | 759 ----
> drivers/atm/suni.h | 242 --
> drivers/atm/tonga.h | 21 -
> drivers/atm/zeprom.h | 35 -
> net/atm/lec.h | 155 -
> net/atm/lec_arpc.h | 97 -
> net/atm/mpc.h | 65 -
> net/atm/mpoa_caches.h | 99 -
> net/bridge/br_private.h | 4 -
> drivers/atm/adummy.c | 202 -
> drivers/atm/atmtcp.c | 513 ---
> drivers/atm/eni.c | 2321 ----------
> drivers/atm/fore200e.c | 3012 -------------
> drivers/atm/he.c | 2861 -------------
> drivers/atm/idt77105.c | 376 --
> drivers/atm/idt77252.c | 3797 -----------------
> drivers/atm/iphase.c | 3283 --------------
> drivers/atm/lanai.c | 2603 -----------
> drivers/atm/nicstar.c | 2759 ------------
> drivers/atm/nicstarmac.c | 244 --
> drivers/atm/solos-attrlist.c | 83 -
> drivers/atm/solos-pci.c | 1496 -------
> drivers/atm/suni.c | 391 --
> net/atm/clip.c | 960 -----
> net/atm/lec.c | 2274 ----------
> net/atm/mpc.c | 1538 -------
> net/atm/mpoa_caches.c | 565 ---
> net/atm/mpoa_proc.c | 307 --
> net/bridge/br.c | 7 -
> net/bridge/br_fdb.c | 29 -
> net/core/dev.c | 7 -
> arch/arm/configs/ixp4xx_defconfig | 5 -
> arch/mips/configs/gpr_defconfig | 13 -
> arch/mips/configs/mtx1_defconfig | 13 -
> arch/powerpc/configs/ppc6xx_defconfig | 9 -
> drivers/atm/.gitignore | 5 -
> drivers/atm/nicstarmac.copyright | 61 -
> 56 files changed, 2 insertions(+), 37237 deletions(-)
> delete mode 100644 Documentation/networking/device_drivers/atm/fore200e.rst
> delete mode 100644 Documentation/networking/device_drivers/atm/iphase.rst
> delete mode 100644 drivers/atm/Kconfig
> delete mode 100644 drivers/atm/Makefile
> delete mode 100644 drivers/atm/eni.h
> delete mode 100644 drivers/atm/fore200e.h
> delete mode 100644 drivers/atm/he.h
> delete mode 100644 drivers/atm/idt77105.h
> delete mode 100644 drivers/atm/idt77252.h
> delete mode 100644 drivers/atm/idt77252_tables.h
> delete mode 100644 drivers/atm/iphase.h
> delete mode 100644 drivers/atm/midway.h
> delete mode 100644 drivers/atm/nicstar.h
> delete mode 100644 drivers/atm/suni.h
> delete mode 100644 drivers/atm/tonga.h
> delete mode 100644 drivers/atm/zeprom.h
> delete mode 100644 net/atm/lec.h
> delete mode 100644 net/atm/lec_arpc.h
> delete mode 100644 net/atm/mpc.h
> delete mode 100644 net/atm/mpoa_caches.h
> delete mode 100644 drivers/atm/adummy.c
> delete mode 100644 drivers/atm/atmtcp.c
> delete mode 100644 drivers/atm/eni.c
> delete mode 100644 drivers/atm/fore200e.c
> delete mode 100644 drivers/atm/he.c
> delete mode 100644 drivers/atm/idt77105.c
> delete mode 100644 drivers/atm/idt77252.c
> delete mode 100644 drivers/atm/iphase.c
> delete mode 100644 drivers/atm/lanai.c
> delete mode 100644 drivers/atm/nicstar.c
> delete mode 100644 drivers/atm/nicstarmac.c
> delete mode 100644 drivers/atm/solos-attrlist.c
> delete mode 100644 drivers/atm/solos-pci.c
> delete mode 100644 drivers/atm/suni.c
> delete mode 100644 net/atm/clip.c
> delete mode 100644 net/atm/lec.c
> delete mode 100644 net/atm/mpc.c
> delete mode 100644 net/atm/mpoa_caches.c
> delete mode 100644 net/atm/mpoa_proc.c
> delete mode 100644 drivers/atm/.gitignore
> delete mode 100644 drivers/atm/nicstarmac.copyright
>
FWIW,
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Dan Carpenter @ 2026-04-22 13:22 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, kuba, przemyslaw.kitszel, anthony.l.nguyen,
kernel-janitors
In-Reply-To: <aeiHkejLjhRKyj/u@AMDC4622.eu.corp.samsungelectronics.net>
On Wed, Apr 22, 2026 at 10:32:17AM +0200, Jakub Raczynski wrote:
> On Tue, Apr 21, 2026 at 05:11:19PM +0300, Dan Carpenter wrote:
> > On Tue, Apr 21, 2026 at 01:40:29PM +0200, Jakub Raczynski wrote:
> > >
> > > - if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0]))))
> > > + if (!((u32)aq_rc < ARRAY_SIZE(aq_to_posix)))
> >
> > This still isn't beautiful. There are so many parens. The !(foo < size)
> > formulation is weird. The cast is unnnecessary. Better to write it as:
> >
> > if (aq_rc >= ARRAY_SIZE(aq_to_posix))
> > return -ERANGE;
> >
> > > return -ERANGE;
> > >
> > > return aq_to_posix[aq_rc];
> >
> > regards,
> > dan carpenter
> >
>
> Alright, will beautify it and resend soon.
>
> I can see potential original intention of not comparing unsigned from sizeof
> with int, maybe that was original compiler configuration to include that
> warning.
Yeah. I know. I wrote a blog about this...
https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/
Check this out:
$ git grep '(int)' | grep ARRAY_SIZE | wc -l
53
It's as if we want array underflows.
> But at this variable range it is irrelevant and it is probably most disabled
> warning ever.
With the unnecessary cast I had to review to ensure that aq_rc is not
unsigned long type. There is a real downside to this kind of rule.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Dan Carpenter @ 2026-04-22 13:24 UTC (permalink / raw)
To: Jakub Raczynski
Cc: netdev, kuba, przemyslaw.kitszel, anthony.l.nguyen,
kernel-janitors
In-Reply-To: <20260422105710.268003-1-j.raczynski@samsung.com>
On Wed, Apr 22, 2026 at 12:57:12PM +0200, Jakub Raczynski wrote:
> There are still places in the code where manual calculation of array size
> exist, but it is good to enforce usage of single macro through the whole
> code as it makes code bit more readable.
> While at it, beautify condition surrounding it by reversing check and remove
> unnecessary casting.
>
> Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
> ---
Thanks.
Reviewed-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
^ 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