* Re: [PATCH net-next v2 13/14] net: macb: use context swapping in .set_ringparam()
From: Théo Lebrun @ 2026-04-22 14:00 UTC (permalink / raw)
To: Jakub Kicinski, Alexandre Belloni
Cc: nicolas.ferre, claudiu.beznea, andrew+netdev, davem, edumazet,
pabeni, richardcochran, linux, pvalerio, conor, nb,
vladimir.kondratiev, gregory.clement, benoit.monin, tawfik.bayouk,
thomas.petazzoni, maxime.chevallier, netdev, linux-kernel
In-Reply-To: <20260414005654.3766959-1-kuba@kernel.org>
On Tue Apr 14, 2026 at 2:56 AM CEST, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: macb: use context swapping in .set_ringparam()
>
> This patch modifies the ethtool set_ringparam implementation to use a
> context swapping mechanism. Instead of closing and reopening the interface,
> it allocates new buffers, stops the interface temporarily, swaps the active
> context, and then frees the old one.
>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>> index 3deab87c565b5..d1536cb1e40bb 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -3081,6 +3081,89 @@ static void macb_configure_dma(struct macb *bp)
> [ ... ]
>> +static void macb_context_swap_start(struct macb *bp)
>> +{
> [ ... ]
>> + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>> + napi_disable(&queue->napi_rx);
>> + napi_disable(&queue->napi_tx);
>
> This isn't a regression from this patch, but does calling napi_disable()
> unconditionally crash on EMAC devices?
>
> EMAC devices appear to not initialize NAPI, which leaves the NAPI struct
> zero-initialized (n->dev is NULL), potentially causing a NULL pointer
> dereference in napi_disable(). Additionally, does this path also blindly
> call bp->macbgem_ops.mog_init_rings() which is NULL on EMAC?
So the LLM is correct in that queue->napi_{rx,tx} fields are never
initialised on at91 platforms [0]. Then we use the fields from many
places without checking.
Most are safe because at91 uses its own netdev_ops.
Functions that get called on at91 and do NAPI calls are:
- macb_suspend() & macb_resume() => system-wide suspend => ignored
- macb_{close,open}() called by macb_set_ringparam()
The codepaths for at91 are so different, context swap support for at91
sounds unrelevant. I'll update both change_mtu and set_ringparam to
return -EOPNOTSUPP if netif_running() && IS_EMAC.
[0]: NAPI fields are initialised in macb_init_dflt() which is either
used as the default config->init() or called by some of those init
functions. at91ether_init() doesn't.
>
>> + netdev_tx_reset_queue(netdev_get_tx_queue(bp->netdev, q));
>> + cancel_work_sync(&queue->tx_error_task);
>> + }
> [ ... ]
>> +static void macb_context_swap_end(struct macb *bp,
>> + struct macb_context *new_ctx)
>> +{
> [ ... ]
>> + /* Swap contexts & give buffer pointers to HW. */
>> +
>> + old_ctx = bp->ctx;
>> + bp->ctx = new_ctx;
>> + macb_init_buffers(bp);
>
> Since the new context swap doesn't call phylink_stop(), could a concurrent
> macb_mac_link_up() execution set the RE and TE bits in NCR during the window
> where bp->lock is dropped?
>
> If so, macb_init_buffers() would write new DMA ring base addresses to RBQP
> and TBQP while the MAC is actively enabled, which violates hardware
> specifications and could cause DMA corruption.
Again this is correct. We can have a race inbetween the swap and phylink
callbacks. However running phylink_stop() would partially ruin the idea
behind context swapping.
bp->lock is not the solution. We need either to disable phylink
operations for the swap duration or to synchronise with them. We cannot
grab bp->lock for the whole swap timespan because some calls might want
to sleep.
Both .mac_link_{up,down}() get called by phylink_resolve() which
acquires phydev->mutex [1]. Getting this mutex for the swap operation
sounds like the solution. PHY status updates will be delayed until the
end of our context swap operation (or the opposite).
Accessible from bp->netdev->phydev->lock. A few drivers already grab
that lock, but no one is for context swapping. Looked at fbnic for
example and there is no sync inbetween phylink ops and set_ringparam.
See fbnic_set_ringparam(), fbnic_phylink_mac_link_down
(), fbnic_mac_link_down_asic(). Maybe the sequence has been crafted to
work fine with concurrent accesses?
⟩ git grep -l 'mutex_lock.*phydev' drivers/net/ethernet/
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
drivers/net/ethernet/broadcom/genet/bcmmii.c
drivers/net/ethernet/cadence/macb_main.c
drivers/net/ethernet/faraday/ftgmac100.c
drivers/net/ethernet/realtek/r8169_main.c
drivers/net/ethernet/ti/icssg/icssg_prueth.c
[1]: https://elixir.bootlin.com/linux/v7.0/source/drivers/net/phy/phylink.c#L1620
>> + if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
>> + for (q = 0, queue = bp->queues; q < bp->num_queues;
>> + ++q, ++queue) {
>> + queue_writel(queue, IER,
>> + bp->rx_intr_mask |
>> + MACB_TX_INT_FLAGS |
>> + MACB_BIT(HRESP));
>> + }
>> + }
>
> Hardware interrupts are disabled unconditionally for all devices in
> macb_context_swap_start() by writing -1 to IDR.
>
> Will this explicit check prevent EMAC devices from having their interrupts
> re-enabled?
>
> Since EMAC devices do not use NAPI and rely on hardware interrupts, leaving
> them masked might silently halt all network traffic after a ring parameter
> change.
The check will be dropped. As said above, context swapping won't support
at91 platforms.
>> + ctrl = macb_readl(bp, NCR);
>> + macb_writel(bp, NCR, ctrl | MACB_BIT(RE) | MACB_BIT(TE));
>
> Can this unprotected read-modify-write of the NCR register race with phylink
> state changes?
>
> If an asynchronous phylink callback like macb_mac_config() modifies NCR
> while holding bp->lock, this unlocked write could overwrite and drop those
> concurrent updates.
The phydev->lock will help here as well.
macb_mac_config() == phylink_mac_ops::mac_config()
<- phylink_mac_config()
<- phylink_major_config()
<- phylink_resolve() (OR phylink_mac_initial_config())
both grab phydev->lock
>
>> +
>> + netif_tx_start_all_queues(bp->netdev);
>> +
>> + /* Free old context. */
>> +
>> + macb_free_consistent(old_ctx);
>
> This isn't a regression from this patch, but does this context swap leak
> pending TX packets and their DMA mappings?
>
> When freeing the old context, macb_free_consistent() appears to only free
> the pointer array. If it doesn't iterate from txq->tail to txq->head to
> unmap the active DMA mappings and free the sk_buff structs, repeatedly
> modifying ring parameters could cause a memory and DMA mapping leak.
Yes it does. I already have a patch pending. This bug has been present
since forever. :-)
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] mptcp: do not drop partial packets
From: Paolo Abeni @ 2026-04-22 13:51 UTC (permalink / raw)
To: Shardul Bankar, matttbe, martineau
Cc: geliang, davem, edumazet, kuba, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, Shardul Bankar
In-Reply-To: <20260422120954.8877-1-shardul.b@mpiricsoftware.com>
On 4/22/26 2:09 PM, Shardul Bankar wrote:
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 614c3f583ca0..6858e6e283e3 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -397,12 +397,27 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)
> return false;
> }
>
> - /* old data, keep it simple and drop the whole pkt, sender
> - * will retransmit as needed, if needed.
> + /* Completely old data? */
> + if (!after64(MPTCP_SKB_CB(skb)->end_seq, msk->ack_seq)) {
> + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> + mptcp_drop(sk, skb);
> + return false;
> + }
> +
> + /* Partial packet: map_seq < ack_seq < end_seq.
> + * Skip the already-acked bytes and enqueue the new data.
> */
> - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);
> - mptcp_drop(sk, skb);
> - return false;
> + copy_len = MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq;
> + MPTCP_SKB_CB(skb)->offset += msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq;
here MPTCP_SKB_CB(skb)->offset is always != 0 ...
> + msk->bytes_received += copy_len;
> + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
> + tail = skb_peek_tail(&sk->sk_receive_queue);
> + if (tail && mptcp_try_coalesce(sk, tail, skb))
... so mptcp_try_coalesce() will always fail.
/P
^ permalink raw reply
* Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR
From: Sebastian Andrzej Siewior @ 2026-04-22 13:27 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netdev, (JC), Jayachandran, David S. Miller, Andrew Lunn,
Chintan Vankar, Danish Anwar, Daolin Qiu, Eric Dumazet,
Felix Maurer, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Simon Horman, Raghavendra, Vignesh, Bajjuri, Praneeth,
TK, Pratheesh Gangadhar, Muralidharan, Neelima
In-Reply-To: <willemdebruijn.kernel.270fa204f615f@gmail.com>
On 2026-04-21 03:41:52 [-0400], Willem de Bruijn wrote:
> Sebastian Andrzej Siewior wrote:
Hi Willem,
> > I understand your concern. I tried to make as self contained as
> > possible and little runtime overhead as possible.
> >
> > > One perhaps interesting Rx only option I had missed before is
> > > SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
> > > device ifindex today?
> >
> > The upper logic expects to poll() on the fd. If I need to filter the
> > device based on this then breaks the expectations.
> > I need also to receive packets without a timestamp so I don't think this
> > works.
>
> I don't follow this. My suggestion is to optionally receive this
> additional metadata along with the data. Not as a filter.
Yes. Just ignore that part.
> > cb[] is limited to one layer. I do have a skb_ext variant working but
> > this requires cmsg to set it. Do you think about generic skb_ext which
> > is set from af_packet? But I don't think it brings much value if I can't
> > filter on the RX side before returning the packet to userland.
> >
> > > But at this point I see enough options that do not require changes
> > > to packet sockets.
> > >
> > > To get back to the simplest approach: skb->mark. Is there any
> > > concrete risk that on this path that would conflict with other
> > > uses of that field? If packet sockets inject directly into this
> > > driver (possibly even with PACKET_QDISC_BYPASS)?
> >
> > So I have a skb->mark variant working. I do read on the ethX interface
>
> When reading on both ethX interfaces, that gives you all the info you
> need on Rx, right? Or alternatively by attaching to hsr0 with
> SOF_TIMESTAMPING_OPT_PKTINFO.
>
> So skb->mark is only relevant to the Tx side, right? There might be
> yet another way to identify in the hsr ndo_start_xmit that a packet
> arrived from a PF_PACKET socket. E.g., by checking skb->sk->sk_family.
> As alternative or complement to skb->protocol.
>
> Btw, on receive the inverse could also be true: insert a synthetic
> header and pop that in userspace, e.g., a VLAN tag.
So I made this:
I open hsr0 for TX with a custom header. The header is expected if the
ether-type is set to PTP. This extra header holds the HSR-header
information and port request.
I open eth0 for RX. I set PACKET_IGNORE_OUTGOING to avoid the feedback
from hsr0 writes. This is part is crucial ;)
I use skb_ext to pass the information from the inline-header to
the network driver since the data pointer of the skb is forwarded after
that header. In the end I have no idea if the network driver supports HW
offloading and needs this information or not and sends the packet as-is.
HW offloading becomes a bit tricky but relying on skb_ext (for HSR) and
checking otherwise for the ether type vs PTP (in the PRP case) does the
trick.
So it is slightly more complicated but seems to work.
Let me wait until after the merge window and then I present what I have.
Sebastian
^ permalink raw reply
* Re: [net-next v2 0/3] Add motorcomm 8531s set ds func and 8522 driver
From: Andrew Lunn @ 2026-04-22 13:27 UTC (permalink / raw)
To: Minda Chen
Cc: Frank, Andrew Lunn, Heiner Kallweit, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260422083255.29692-1-minda.chen@starfivetech.com>
On Wed, Apr 22, 2026 at 04:32:52PM +0800, Minda Chen wrote:
> This patch is for Starfive JHB100 EVB board. JHB100 contain
> 1 RGMII/RMII and 1 RMII synopsys GMAC cores. In the EVB board, RGMII
> interface connect with YT8531s Ethernet PHY. RMII interface connect
> with YT8522 ethernet PHY. So patch 1-2 is for RGMII interface
> patch 3 is RMII is for RMII interface.
>
> JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
> Managent Controller). Similar with Aspeed 27x0.
>
> The JHB100 minimal system upstream is in progress:
> https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
Please take a read of sections 1.3 and 1.4 of:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH] m68k: mvme147: Make me the maintainer
From: Daniel Palmer @ 2026-04-22 13:27 UTC (permalink / raw)
To: andrew+netdev
Cc: geert, James.Bottomley, martin.petersen, davem, edumazet, kuba,
pabeni, linux-m68k, linux-scsi, netdev, linux-kernel,
Daniel Palmer
I'm actively using mainline + patches on this board as a bootloader
for another VME board and as a terminal server using a multiport
serial board in the same VME backplane. I even have mainline u-boot
on real EPROMs.
Make me the maintainer of its ethernet, scsi and arch code so I get
an email before one or more of them get deleted.
Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d25342ca8aa1..9949b5528bcf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15311,6 +15311,13 @@ S: Maintained
W: http://www.tazenda.demon.co.uk/phil/linux-hp
F: arch/m68k/hp300/
+M68K ON MVME147
+M: Daniel Palmer <daniel@thingy.jp>
+S: Maintained
+F: arch/m68k/mvme147/
+F: drivers/net/ethernet/amd/mvme147.c
+F: drivers/scsi/mvme147.*
+
M88DS3103 MEDIA DRIVER
L: linux-media@vger.kernel.org
S: Orphan
--
2.53.0
^ permalink raw reply related
* 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
* 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 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: 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 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: [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 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 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] 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 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: [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: [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: [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: [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 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] 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
* [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
* [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 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 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
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