* [PATCH] net : bonding : Remove TODO comment about retrying setting the MAC
From: Paritosh Potukuchi @ 2026-07-03 12:55 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, jv, paritosh.potukuchi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
As correctly pointed out by Jay Vosburgh,
"This comment dates to sometime before git, when it was common for
network device drivers to lack the ability to change the MAC while the
interface is up. To the best of my knowledge, that isn't a issue
today."
Based on the discussion in the RFC linked below, I am removing the
TODO.
Link to the RFC:
https://lore.kernel.org/netdev/2001256.1782860341@famine/T/#t
Signed-off-by: Paritosh Potukuchi <paritosh.potukuchi@amd.com>
---
drivers/net/bonding/bond_main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d2e4dae4e97c..d5c19dc4bc07 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4865,12 +4865,6 @@ static int bond_set_mac_address(struct net_device *bond_dev, void *addr)
__func__, slave);
res = dev_set_mac_address(slave->dev, addr, NULL);
if (res) {
- /* TODO: consider downing the slave
- * and retry ?
- * User should expect communications
- * breakage anyway until ARP finish
- * updating, so...
- */
slave_dbg(bond_dev, slave->dev, "%s: err %d\n",
__func__, res);
goto unwind;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 net-next] ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DA
From: Maxime Chevallier @ 2026-07-03 12:53 UTC (permalink / raw)
To: Siddaraju DH, Michal Kubecek, Andrew Lunn, kuba, netdev
Cc: Shubham Das, Balaji Chintalapalle, Vijay Srinivasan,
Magnus Lindberg, Niklas Damberg, Jonas Wirandi, Siddaraju DH
In-Reply-To: <20260703100537.1109838-1-siddaraju.dh@intel.com>
Hi
On 7/3/26 12:05, Siddaraju DH wrote:
> Add comment to clarify the physical media 10000baseCR follows.
>
> 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD.
> It has no autonegotiation, no link training, and no mandatory FEC.
> The industry standard for this media type is SFF-8431 Appendix-E
> Direct Attach cable, also known as 10G_SFI_DA.
>
> Link: https://lore.kernel.org/r/SN7PR11MB69003D33489DB1D6B17EF72A9AF52@SN7PR11MB6900.namprd11.prod.outlook.com
>
> Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: Add soft reset for 88E1510
From: Andrew Lunn @ 2026-07-03 12:53 UTC (permalink / raw)
To: Ben Brown
Cc: hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Chris Packham
In-Reply-To: <c0d760ff-fe66-48df-bd9f-3226dfdc97fc@alliedtelesis.co.nz>
On Fri, Jul 03, 2026 at 12:14:26AM +0000, Ben Brown wrote:
>
>
> On 7/3/26 11:04, Andrew Lunn wrote:
> > On Fri, Jul 03, 2026 at 10:50:34AM +1200, Ben Brown wrote:
> >> When bringing down then up the link on a 88e1512 phy a link is not
> >> getting established. This is because the phy is coming out of reset then
> >> immediately getting configured. During configuration the page is
> >> unsuccessfully updated causing writes to the wrong registers.
> >>
> >> Add the soft reset function that does a reset then polling read waiting
> >> for the phy to come back online, at which stage the page register can be
> >> updated successfully.
> >>
> >> This was tested on a 88E1512 phy, using ip link to bring up/down the
> >> link.
> >
> > What makes the 88E1512 special that it needs this, but no other
> > Marvell PHY does?
> >
> > Andrew
>
> This may be needed on the other marvell phys, but I only have access to
> a 88E1512 phy so I am only updating what I have seen this on.
The Marvell driver is used a lot, so i would of expected somebody else
to of noticed.
Lets take a step back.
What sort of reset are we talking about? Software or hardware?
Andrew
^ permalink raw reply
* Re: Question: bridge: clarify MST VLAN list RCU traversal contract
From: Runyu Xiao @ 2026-07-03 4:24 UTC (permalink / raw)
To: Ido Schimmel
Cc: Nikolay Aleksandrov, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, bridge, netdev,
linux-kernel, jianhao.xu
In-Reply-To: <20260628174900.GA400397@shredder>
Hi Ido,
On Sun, 28 Jun 2026 20:49:00 +0300, Ido Schimmel wrote:
> I don't think anything needs to change. AFAICT, br_mst_info_size() is
> only reachable via the get_link_af_size() callback and
> rtnl_link_get_af_size() always invokes it from an RCU read-side critical
> section.
>
> Did you see a splat with CONFIG_PROVE_RCU_LIST?
Thanks for the clarification.
No, I did not see an in-kernel splat from the actual rtnetlink path.
The warning I had was from the reviewed out-of-tree reproducer used for
our CONFIG_PROVE_RCU_LIST triage, not from a real bridge netlink call
path.
Given your explanation that rtnl_link_get_af_size() already invokes
this from an RCU read-side critical section, I will treat this as an
intended contract and I will not pursue a patch for it based on the
current evidence.
Thanks,
Runyu
^ permalink raw reply
* Re: [PATCH net v2 2/2] octeon_ep_vf: fix skb frags overflow in the RX path
From: Maciej Fijalkowski @ 2026-07-03 12:11 UTC (permalink / raw)
To: Maoyi Xie
Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-3-maoyixie.tju@gmail.com>
On Fri, Jul 03, 2026 at 02:05:18AM +0800, Maoyi Xie wrote:
> __octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF
> driver. buff_info->len comes from the device response header, and one
> fragment is added per buffer_size chunk with no check against
> MAX_SKB_FRAGS. A long packet yields about 18 fragments, one past the
> default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past
> shinfo->frags[].
>
> The fragment count is now checked before napi_build_skb(). A packet that
> needs more fragments than the skb can hold is dropped. Its descriptors are
> drained the same way the build_skb failure path does.
>
> Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support")
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
> ---
> .../marvell/octeon_ep_vf/octep_vf_rx.c | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> index d982474082..7af6a80671 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> @@ -431,6 +431,26 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
> struct skb_shared_info *shinfo;
> u16 data_len;
>
> + data_len = buff_info->len - oq->max_single_buffer_size;
> + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
> + desc_used++;
> + read_idx = octep_vf_oq_next_idx(oq, read_idx);
> + while (data_len) {
> + dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr,
> + PAGE_SIZE, DMA_FROM_DEVICE);
> + buff_info = (struct octep_vf_rx_buffer *)
> + &oq->buff_info[read_idx];
> + buff_info->page = NULL;
> + if (data_len < oq->buffer_size)
> + data_len = 0;
> + else
> + data_len -= oq->buffer_size;
> + desc_used++;
> + read_idx = octep_vf_oq_next_idx(oq, read_idx);
> + }
> + continue;
> + }
This is exactly repeated code for !skb case below, right? Please pull it
out to helper function then.
> +
> skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
> if (!skb) {
> oq->stats->alloc_failures++;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next v3 13/15] net: macb: re-read ISR inside IRQ handler locked section
From: Conor Dooley @ 2026-07-03 12:09 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-13-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]
Hey,
I'll admit to being a bit confused by this patch..
On Wed, Jul 01, 2026 at 05:59:16PM +0200, Théo Lebrun wrote:
> The IRQ handler reads ISR register into the `status` stack variable.
> If empty, it early returns. Else, it grabs bp->lock and iterates on
> the status bits.
>
> If we tried grabbing bp->lock while already acquired, we might have
> slept and the status might have been updated. Our most likely
This mention of sleeping I think should be removed, it implies sleeping
is required for the status to be updated.
> competitor in this race (condition) is a swap operation, used in
> change_mtu and set_ringparam. It is the only MACB codepath that resets
> interrupts and HW inside a bp->lock critical section. Other codepaths
> that clear HW IRQ status do so outside the bp->lock critical section.
Where do change_mtu and set_ringparam take the bp lock?
As far as I can see, they don't. The commit message should reflect how
the code behaves at the time of the patch, not at some point in the
future after it.
> We can only detect spurious interrupts before grabbing bp->lock if
> MACB_CAPS_ISR_CLEAR_ON_WRITE. If we don't, then we only read ISR once.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 7245c345c78f..5a32d5cb759e 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -2184,13 +2184,21 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
> struct net_device *netdev = bp->netdev;
> u32 status;
>
> - status = queue_readl(queue, ISR);
> -
> - if (unlikely(!status))
> - return IRQ_NONE;
> + /* detect spurious interrupts without grabbing bp->lock */
> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE) {
> + status = queue_readl(queue, ISR);
> + if (unlikely(!status))
> + return IRQ_NONE;
> + }
To be honest, this check feels like penalising the likely^2 case* with an
extra read favour of the unlikely case where there's contention on the
lock and the contending function is capable of affecting the status
register. Could we get away with just the single check of the register
with the lock taken?
* although I don't know what percentage of hardware supports this cap,
so maybe most devices will never run this code
>
> spin_lock(&bp->lock);
>
> + status = queue_readl(queue, ISR);
> + if (unlikely(!status)) {
> + spin_unlock(&bp->lock);
> + return IRQ_NONE;
> + }
> +
> while (status) {
> /* close possible race with dev_close */
> if (unlikely(!netif_running(netdev))) {
>
> --
> 2.55.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 1/2] octeon_ep: fix skb frags overflow in the RX path
From: Maciej Fijalkowski @ 2026-07-03 12:01 UTC (permalink / raw)
To: Maoyi Xie
Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-2-maoyixie.tju@gmail.com>
On Fri, Jul 03, 2026 at 02:05:17AM +0800, Maoyi Xie wrote:
> __octep_oq_process_rx() builds an skb for a multi-buffer packet by adding
> one fragment per buffer_size chunk:
>
> data_len = buff_info->len - oq->max_single_buffer_size;
> while (data_len) {
> ...
> skb_add_rx_frag(skb, shinfo->nr_frags, buff_info->page, 0,
> buff_info->len, buff_info->len);
> ...
> }
>
> buff_info->len comes from the device response header
> (be64_to_cpu(resp_hw->length)). Nothing bounds the fragment count against
> MAX_SKB_FRAGS. data_len can be close to 65535. buffer_size defaults to
> about 3776 on 4K pages, so a full packet yields about 18 fragments. That
> is one more than the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag()
> writes past shinfo->frags[].
>
> The fragment count is now checked before build_skb(). A packet that needs
> more fragments than the skb can hold is dropped. octep_oq_drop_rx()
> consumes its descriptors like the build_skb failure path. The same class
> was fixed in other RX paths, including commit 5ffcb7b890f6 ("net: atlantic:
> fix fragment overflow handling in RX path") and commit f0813bcd2d9d ("net:
> wwan: t7xx: fix potential skb->frags overflow in RX path").
>
> Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
> index e6ebc7e44a..bdbed58c7b 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
> @@ -453,6 +453,15 @@ static int __octep_oq_process_rx(struct octep_device *oct,
>
> octep_oq_next_pkt(oq, buff_info, &read_idx, &desc_used);
>
> + if (buff_info->len > oq->max_single_buffer_size) {
> + u16 data_len = buff_info->len - oq->max_single_buffer_size;
> +
> + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
> + octep_oq_drop_rx(oq, buff_info, &read_idx, &desc_used);
> + continue;
> + }
> + }
> +
> skb = build_skb((void *)resp_hw, PAGE_SIZE);
> if (!skb) {
> octep_oq_drop_rx(oq, buff_info,
> --
> 2.34.1
>
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Michael S. Tsirkin @ 2026-07-03 11:55 UTC (permalink / raw)
To: Simon Schippers
Cc: Jakub Kicinski, Tim Gebauer, Willem de Bruijn, Jason Wang,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-kernel, Brett Sheffield, regressions, netdev
In-Reply-To: <a1bae349-61a1-4c65-a531-179850576642@tu-dortmund.de>
On Fri, Jul 03, 2026 at 12:41:19PM +0200, Simon Schippers wrote:
> On 7/1/26 21:16, Brett Sheffield wrote:
> > TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
> > significant performance regressions with TAP interfaces and multithreaded
> > network code. Please revert.
>
> Micheal, I am convinced that netdev_tx_stop_queue() and
> netdev_tx_wake_queue() are too slow. The communication between the CPUs
> is just too slow. We already spent *a lot* of time speeding it up, the
> patchset was only merged at v12...
>
> Yes, I would *love* to have qdisc backpressure on by default but I do
> not see how anything could speed it up.
>
>
> *Is there any issue if we introduce IFF_BACKPRESSURE?*
> I implemented it and it is a simple patch that only executes the
> stopping / waking if ((tun->flags & IFF_BACKPRESSURE)).
> I could submit that to [net] very soon.
>
> Thank you,
> Simon
Pls go ahead.
--
MST
^ permalink raw reply
* Re: [PATCH net-next v3 11/15] net: macb: change function signatures to take contexts
From: Conor Dooley @ 2026-07-03 11:45 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-11-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 10/15] net: macb: change caps helpers signatures
From: Conor Dooley @ 2026-07-03 11:43 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-10-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 07/15] net: macb: introduce macb_context struct for buffer management
From: Conor Dooley @ 2026-07-03 11:39 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-7-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v2] gtp: parse extension headers before reading inner protocol
From: Pablo Neira Ayuso @ 2026-07-03 11:38 UTC (permalink / raw)
To: Zhixing Chen
Cc: Harald Welte, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, osmocom-net-gprs, netdev
In-Reply-To: <20260703093708.18141-1-running910@gmail.com>
On Fri, Jul 03, 2026 at 05:37:08PM +0800, Zhixing Chen wrote:
> GTPv1-U packets may carry a chain of extension headers before the inner
> IP packet. The receive path already parses and skips these extension
> headers, but it currently reads the inner protocol before doing so.
>
> As a result, the first extension header byte is interpreted as the inner
> IP version. Packets with extension headers are then dropped before PDP
> lookup.
>
> Parse the extension header chain before calling gtp_inner_proto(), so the
> inner protocol is read from the actual inner IP header.
>
> Fixes: c75fc0b9e5be ("gtp: identify tunnel via GTP device + GTP version + TEID + family")
> Signed-off-by: Zhixing Chen <running910@gmail.com>
Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
^ permalink raw reply
* Re: [PATCH net-next v3 05/15] net: macb: enforce reverse christmas tree (RCT) convention
From: Conor Dooley @ 2026-07-03 11:35 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-5-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 04/15] net: macb: unify queue index variable naming convention and types
From: Conor Dooley @ 2026-07-03 11:34 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-4-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5903 bytes --]
On Wed, Jul 01, 2026 at 05:59:07PM +0200, Théo Lebrun wrote:
> Variables are named q or queue_index. Types are int, unsigned int, u32
> and u16. Use `unsigned int q` everywhere.
>
> Skip over taprio functions. They use `u8 queue_id` which fits with the
> `struct macb_queue_enst_config` field. Using `queue_id` everywhere
> would be too verbose.
I'm not sure that I agree about the verbosity, and "q" isn't a letter I
would naturally associate with indexing, in the way ijk etc are. Perhaps
in netdev it is a natural choice however?
Conor.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 86c0e9ccbfce..3b75797381b6 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -877,7 +877,7 @@ static void gem_shuffle_tx_one_ring(struct macb_queue *queue)
> static void gem_shuffle_tx_rings(struct macb *bp)
> {
> struct macb_queue *queue;
> - int q;
> + unsigned int q;
>
> for (q = 0, queue = bp->queues; q < bp->num_queues; q++, queue++)
> gem_shuffle_tx_one_ring(queue);
> @@ -1258,7 +1258,7 @@ static void macb_tx_error_task(struct work_struct *work)
> tx_error_task);
> bool halt_timeout = false;
> struct macb *bp = queue->bp;
> - u32 queue_index;
> + unsigned int q;
> u32 packets = 0;
> u32 bytes = 0;
> struct macb_tx_skb *tx_skb;
> @@ -1267,9 +1267,9 @@ static void macb_tx_error_task(struct work_struct *work)
> unsigned int tail;
> unsigned long flags;
>
> - queue_index = queue - bp->queues;
> + q = queue - bp->queues;
> netdev_vdbg(bp->netdev, "macb_tx_error_task: q = %u, t = %u, h = %u\n",
> - queue_index, queue->tx_tail, queue->tx_head);
> + q, queue->tx_tail, queue->tx_head);
>
> /* Prevent the queue NAPI TX poll from running, as it calls
> * macb_tx_complete(), which in turn may call netif_wake_subqueue().
> @@ -1342,7 +1342,7 @@ static void macb_tx_error_task(struct work_struct *work)
> macb_tx_unmap(bp, tx_skb, 0);
> }
>
> - netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, queue_index),
> + netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, q),
> packets, bytes);
>
> /* Set end of TX queue */
> @@ -1407,7 +1407,7 @@ static bool ptp_one_step_sync(struct sk_buff *skb)
> static int macb_tx_complete(struct macb_queue *queue, int budget)
> {
> struct macb *bp = queue->bp;
> - u16 queue_index = queue - bp->queues;
> + unsigned int q = queue - bp->queues;
> unsigned long flags;
> unsigned int tail;
> unsigned int head;
> @@ -1469,14 +1469,14 @@ static int macb_tx_complete(struct macb_queue *queue, int budget)
> }
> }
>
> - netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, queue_index),
> + netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, q),
> packets, bytes);
>
> queue->tx_tail = tail;
> - if (__netif_subqueue_stopped(bp->netdev, queue_index) &&
> + if (__netif_subqueue_stopped(bp->netdev, q) &&
> CIRC_CNT(queue->tx_head, queue->tx_tail,
> bp->tx_ring_size) <= MACB_TX_WAKEUP_THRESH(bp))
> - netif_wake_subqueue(bp->netdev, queue_index);
> + netif_wake_subqueue(bp->netdev, q);
> spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
>
> if (packets)
> @@ -2470,10 +2470,10 @@ static int macb_pad_and_fcs(struct sk_buff **skb, struct net_device *netdev)
> static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> struct net_device *netdev)
> {
> - u16 queue_index = skb_get_queue_mapping(skb);
> struct macb *bp = netdev_priv(netdev);
> - struct macb_queue *queue = &bp->queues[queue_index];
> + unsigned int q = skb_get_queue_mapping(skb);
> unsigned int desc_cnt, nr_frags, frag_size, f;
> + struct macb_queue *queue = &bp->queues[q];
> unsigned int hdrlen;
> unsigned long flags;
> bool is_lso;
> @@ -2512,8 +2512,8 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
>
> #if defined(DEBUG) && defined(VERBOSE_DEBUG)
> netdev_vdbg(bp->netdev,
> - "start_xmit: queue %hu len %u head %p data %p tail %p end %p\n",
> - queue_index, skb->len, skb->head, skb->data,
> + "start_xmit: queue %u len %u head %p data %p tail %p end %p\n",
> + q, skb->len, skb->head, skb->data,
> skb_tail_pointer(skb), skb_end_pointer(skb));
> print_hex_dump(KERN_DEBUG, "data: ", DUMP_PREFIX_OFFSET, 16, 1,
> skb->data, 16, true);
> @@ -2539,7 +2539,7 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> /* This is a hard error, log it. */
> if (CIRC_SPACE(queue->tx_head, queue->tx_tail,
> bp->tx_ring_size) < desc_cnt) {
> - netif_stop_subqueue(netdev, queue_index);
> + netif_stop_subqueue(netdev, q);
> netdev_dbg(netdev, "tx_head = %u, tx_tail = %u\n",
> queue->tx_head, queue->tx_tail);
> ret = NETDEV_TX_BUSY;
> @@ -2555,7 +2555,7 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> /* Make newly initialized descriptor visible to hardware */
> wmb();
> skb_tx_timestamp(skb);
> - netdev_tx_sent_queue(netdev_get_tx_queue(bp->netdev, queue_index),
> + netdev_tx_sent_queue(netdev_get_tx_queue(bp->netdev, q),
> skb->len);
>
> spin_lock(&bp->lock);
> @@ -2564,7 +2564,7 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> spin_unlock(&bp->lock);
>
> if (CIRC_SPACE(queue->tx_head, queue->tx_tail, bp->tx_ring_size) < 1)
> - netif_stop_subqueue(netdev, queue_index);
> + netif_stop_subqueue(netdev, q);
>
> unlock:
> spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
>
> --
> 2.55.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 03/15] net: macb: unify variable naming convention in at91ether functions
From: Conor Dooley @ 2026-07-03 11:30 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-3-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 02/15] net: macb: unify device pointer naming convention
From: Conor Dooley @ 2026-07-03 11:29 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-2-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Wed, Jul 01, 2026 at 05:59:05PM +0200, Théo Lebrun wrote:
> Here are all device pointer variable permutations inside MACB:
>
> struct device *dev;
> struct net_device *dev;
> struct net_device *ndev;
> struct net_device *netdev;
> struct pci_dev *pdev; // inside macb_pci.c
> struct phy_device *phy;
> struct phy_device *phydev;
> struct platform_device *pdev;
> struct platform_device *plat_dev; // inside macb_pci.c
>
> Unify to this convention:
>
> struct device *dev;
> struct net_device *netdev;
> struct pci_dev *pci;
> struct phy_device *phydev;
> struct platform_device *pdev;
Oh lovely, OCD approved.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 01/15] net: macb: drop "consistent" from alloc/free function names
From: Conor Dooley @ 2026-07-03 11:28 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-1-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
On Wed, Jul 01, 2026 at 05:59:04PM +0200, Théo Lebrun wrote:
> Since commit 4df95131ea80 ("net/macb: change RX path for GEM") those
> functions have not been only allocating or freeing consistent memory
> mappings.
>
> Rename from macb_alloc_consistent() to macb_alloc() and
> from macb_free_consistent() to macb_free().
What does "consistent" even mean? Is it intended to be analogous to
coherent?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net] psp: fix NULL genl_sock deref race with concurrent netns teardown
From: Kiran Kella @ 2026-07-03 11:24 UTC (permalink / raw)
To: daniel.zahka, kuba, willemdebruijn.kernel
Cc: davem, edumazet, pabeni, horms, weibunny, netdev, linux-kernel,
jayakrishnan.udayavarma, ajit.khaparde, akhilesh.samineni,
Kiran Kella, Vikas Gupta, Bhargava Marreddy
The race occurs between network namespace removal and PSP device
unregistration. When a netns is deleted while a PSP device associated
with that netns is concurrently being removed, psp_dev_unregister()
triggers psp_nl_notify_dev() to send a device change notification.
Concurrently, cleanup_net() running in the netns workqueue calls
genl_pernet_exit(), which sets net->genl_sock to NULL. If
genl_pernet_exit() wins the race, two sites in psp_nl_multicast_per_ns()
then dereference the NULL socket and crash:
CPU 0 (netns teardown) CPU 1 (PSP device unregister)
====================== =============================
cleanup_net [workqueue]
genl_pernet_exit() psp_dev_unregister()
net->genl_sock = NULL psp_nl_notify_dev()
psp_nl_multicast_per_ns()
build_ntf()
-> netlink_has_listeners(NULL)
/* crash */
genlmsg_multicast_netns()
-> nlmsg_multicast_filtered(NULL)
/* crash */
Both the main_net path (derived from psd->main_netdev) and each
assoc_net entry in psd->assoc_dev_list are affected.
Fix by replacing the bare dev_net() calls with maybe_get_net().
maybe_get_net() returns NULL if the namespace is already dying.
Holding the reference ensures genl_sock remains valid across both the
build_ntf() and genlmsg_multicast_netns() calls.
Fixes: 00c94ca2b99e ("psp: base PSP device support")
Fixes: 06c2dce2d0f6 ("psp: add new netlink cmd for dev-assoc and dev-disassoc")
Signed-off-by: Kiran Kella <kiran.kella@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com>
Reviewed-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
---
net/psp/psp_nl.c | 33 +++++++++++++++++++++------------
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/net/psp/psp_nl.c b/net/psp/psp_nl.c
index 9610d8c456ff..24ab626a9e8a 100644
--- a/net/psp/psp_nl.c
+++ b/net/psp/psp_nl.c
@@ -62,36 +62,45 @@ psp_nl_multicast_per_ns(struct psp_dev *psd, unsigned int group,
struct net *main_net;
struct sk_buff *ntf;
- main_net = dev_net(psd->main_netdev);
+ main_net = maybe_get_net(dev_net(psd->main_netdev));
+ if (!main_net)
+ return;
+
xa_init(&sent_nets);
list_for_each_entry(entry, &psd->assoc_dev_list, dev_list) {
struct net *assoc_net = dev_net(entry->assoc_dev);
+ struct net *net;
int ret;
if (net_eq(assoc_net, main_net))
continue;
- ret = xa_insert(&sent_nets, (unsigned long)assoc_net, assoc_net,
- GFP_KERNEL);
- if (ret == -EBUSY)
+ net = maybe_get_net(assoc_net);
+ if (!net)
continue;
- ntf = build_ntf(psd, assoc_net, ctx);
- if (!ntf)
+ ret = xa_insert(&sent_nets, (unsigned long)assoc_net, assoc_net,
+ GFP_KERNEL);
+ if (ret == -EBUSY) {
+ put_net(net);
continue;
+ }
- genlmsg_multicast_netns(&psp_nl_family, assoc_net, ntf, 0,
- group, GFP_KERNEL);
+ ntf = build_ntf(psd, net, ctx);
+ if (ntf)
+ genlmsg_multicast_netns(&psp_nl_family, net, ntf, 0,
+ group, GFP_KERNEL);
+ put_net(net);
}
xa_destroy(&sent_nets);
/* Send to main device netns */
ntf = build_ntf(psd, main_net, ctx);
- if (!ntf)
- return;
- genlmsg_multicast_netns(&psp_nl_family, main_net, ntf, 0, group,
- GFP_KERNEL);
+ if (ntf)
+ genlmsg_multicast_netns(&psp_nl_family, main_net, ntf, 0, group,
+ GFP_KERNEL);
+ put_net(main_net);
}
static struct sk_buff *psp_nl_clone_ntf(struct psp_dev *psd, struct net *net,
--
2.54.0
^ permalink raw reply related
* [PATCH iproute2-next] ip: add OVPN device mode support
From: Marco Baffo @ 2026-07-03 11:14 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Stephen Hemminger, Antonio Quartulli, Marco Baffo
Allow selecting point-to-point or multi-peer mode when creating an
OVPN device.
Signed-off-by: Marco Baffo <marco@mandelbit.com>
---
ip/Makefile | 2 +-
ip/iplink.c | 2 +-
ip/iplink_ovpn.c | 87 +++++++++++++++++++++++++++++++++++++++++++
man/man8/ip-link.8.in | 24 ++++++++++++
4 files changed, 113 insertions(+), 2 deletions(-)
create mode 100644 ip/iplink_ovpn.c
diff --git a/ip/Makefile b/ip/Makefile
index 3535ba78..978f6841 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -13,7 +13,7 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \
ipvrf.o iplink_xstats.o ipseg6.o iplink_netdevsim.o iplink_rmnet.o \
ipnexthop.o ipmptcp.o iplink_bareudp.o iplink_wwan.o ipioam6.o \
iplink_amt.o iplink_batadv.o iplink_gtp.o iplink_virt_wifi.o \
- iplink_netkit.o ipstats.o
+ iplink_netkit.o ipstats.o iplink_ovpn.o
RTMONOBJ=rtmon.o
diff --git a/ip/iplink.c b/ip/iplink.c
index 3f0b46c9..c6aee8b6 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -42,7 +42,7 @@ void iplink_types_usage(void)
" ifb | ip6erspan | ip6gre | ip6gretap | ip6tnl |\n"
" ipip | ipoib | ipvlan | ipvtap |\n"
" macsec | macvlan | macvtap | netdevsim |\n"
- " netkit | nlmon | pfcp | rmnet | sit | team | team_slave |\n"
+ " netkit | nlmon | ovpn | pfcp | rmnet | sit | team | team_slave |\n"
" vcan | veth | vlan | vrf | vti | vxcan | vxlan | wwan |\n"
" xfrm | virt_wifi }\n");
}
diff --git a/ip/iplink_ovpn.c b/ip/iplink_ovpn.c
new file mode 100644
index 00000000..08e59526
--- /dev/null
+++ b/ip/iplink_ovpn.c
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * iplink_ovpn.c OpenVPN DCO device support
+ *
+ * Author: Marco Baffo <marco@mandelbit.com>
+ *
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <linux/if_link.h>
+
+#include "utils.h"
+#include "ip_common.h"
+
+static void print_explain(FILE *f)
+{
+ fprintf(f,
+ "Usage: ... ovpn [ mode { p2p | mp } ]\n"
+ "\n"
+ "MODE := p2p | mp\n"
+ "(p2p is the default if mode is not specified)\n");
+}
+
+static int ovpn_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *n)
+{
+ while (argc > 0) {
+ if (matches(*argv, "mode") == 0) {
+ __u8 mode;
+
+ NEXT_ARG();
+ if (strcmp(*argv, "p2p") == 0)
+ mode = OVPN_MODE_P2P;
+ else if (strcmp(*argv, "mp") == 0)
+ mode = OVPN_MODE_MP;
+ else {
+ fprintf(stderr,
+ "Error: argument of \"mode\" must be either \"p2p\" or \"mp\"\n");
+ return -1;
+ }
+ addattr8(n, 1024, IFLA_OVPN_MODE, mode);
+ } else if (matches(*argv, "help") == 0) {
+ print_explain(stderr);
+ return -1;
+ } else {
+ fprintf(stderr, "ovpn: unknown option \"%s\"?\n", *argv);
+ print_explain(stderr);
+ return -1;
+ }
+ argc--;
+ argv++;
+ }
+
+ return 0;
+}
+
+static void ovpn_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
+{
+ __u8 value;
+
+ if (!tb || !tb[IFLA_OVPN_MODE] ||
+ RTA_PAYLOAD(tb[IFLA_OVPN_MODE]) < sizeof(value))
+ return;
+
+ value = rta_getattr_u8(tb[IFLA_OVPN_MODE]);
+
+ const char *mode =
+ value == OVPN_MODE_P2P ? "p2p" :
+ value == OVPN_MODE_MP ? "mp" : "unknown";
+
+ print_string(PRINT_ANY, "mode", "mode %s ", mode);
+}
+
+static void ovpn_print_help(struct link_util *lu, int argc, char **argv,
+ FILE *f)
+{
+ print_explain(f);
+}
+
+struct link_util ovpn_link_util = {
+ .id = "ovpn",
+ .maxattr = IFLA_OVPN_MAX,
+ .parse_opt = ovpn_parse_opt,
+ .print_opt = ovpn_print_opt,
+ .print_help = ovpn_print_help,
+};
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index fc7f0248..d54d2fbc 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -287,6 +287,7 @@ ip-link \- network device configuration
.BR netdevsim " |"
.BR netkit " |"
.BR nlmon " |"
+.BR ovpn " |"
.BR pfcp " |"
.BR rmnet " |"
.BR sit " |"
@@ -430,6 +431,9 @@ Link types:
.BR nlmon
- Netlink monitoring device
.sp
+.BR ovpn
+- OpenVPN Data Channel Offload device
+.sp
.BR pfcp
- Packet Forwarding Control Protocol device
.sp
@@ -1349,6 +1353,26 @@ the following additional arguments are supported:
.BI mode " MODE "
- specifies the mode (datagram or connected) to use.
+.TP
+OVPN Type Support
+For a link of type
+.I OVPN
+the following additional arguments are supported:
+
+.BI "ip link add " DEVICE
+.BR "type ovpn " [ " mode " "{ " p2p " | " mp " }" " ]"
+
+.in +8
+.sp
+.BR mode " { " p2p " | " mp " }"
+- selects the OpenVPN device mode. The default,
+.BR p2p ,
+creates a point-to-point device for a single peer. The
+.B mp
+mode creates a multi-peer device.
+
+.in -8
+
.TP
ERSPAN Type Support
For a link of type
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] ieee802154: hwsim: free PIB after unregistering hardware
From: Yousef Alhouseen @ 2026-07-03 11:19 UTC (permalink / raw)
To: miquel.raynal
Cc: alex.aring, stefan, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-wpan, netdev, linux-kernel, stable,
syzbot+4707bb8a43a42fca2b97
In-Reply-To: <877bncnx25.fsf@bootlin.com>
Hello Miquel,
After ieee802154_unregister_hw() returns, the driver callbacks that
can replace phy->pib have been quiesced, and hwsim_del() has exclusive
ownership of the final teardown. The pointer is no longer being
fetched inside an RCU read-side critical section, so rcu_dereference()
is not appropriate there.
rcu_dereference_protected(phy->pib, 1) expresses that there can no
longer be a concurrent updater at that point; the protection condition
is the completed unregister rather than a locally held lock. The value
is only fetched so the final object can be passed to kfree_rcu().
rcu_access_pointer() would also be sufficient for that limited use if
you prefer it, and I can use that spelling in a v2.
Thanks,
Yousef
On Fri, 03 Jul 2026 13:15:46 +0200, Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
> Hello Yousef,
>
> > @@ -1004,12 +1004,11 @@ static void hwsim_del(struct hwsim_phy *phy)
> > list_del_rcu(&e->list);
> > hwsim_free_edge(e);
> > }
> > - pib = rcu_dereference(phy->pib);
> > rcu_read_unlock();
> >
> > - kfree_rcu(pib, rcu);
> > -
> > ieee802154_unregister_hw(phy->hw);
> > + pib = rcu_dereference_protected(phy->pib, 1);
> > + kfree_rcu(pib, rcu);
> > ieee802154_free_hw(phy->hw);
> > }
>
> Would you mind justifying the choice for the _protected() version,
> please?
>
> Thanks,
> Miquèl
^ permalink raw reply
* Re: [PATCH net] ieee802154: hwsim: free PIB after unregistering hardware
From: Miquel Raynal @ 2026-07-03 11:15 UTC (permalink / raw)
To: Yousef Alhouseen
Cc: Alexander Aring, Stefan Schmidt, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-wpan, netdev,
linux-kernel, stable, syzbot+4707bb8a43a42fca2b97
In-Reply-To: <20260627235805.17310-1-alhouseenyousef@gmail.com>
Hello Yousef,
> @@ -1004,12 +1004,11 @@ static void hwsim_del(struct hwsim_phy *phy)
> list_del_rcu(&e->list);
> hwsim_free_edge(e);
> }
> - pib = rcu_dereference(phy->pib);
> rcu_read_unlock();
>
> - kfree_rcu(pib, rcu);
> -
> ieee802154_unregister_hw(phy->hw);
> + pib = rcu_dereference_protected(phy->pib, 1);
> + kfree_rcu(pib, rcu);
> ieee802154_free_hw(phy->hw);
> }
Would you mind justifying the choice for the _protected() version,
please?
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH net 3/4] afs: Fix UAF when sending a message
From: Marc Dionne @ 2026-07-03 11:12 UTC (permalink / raw)
To: David Howells
Cc: netdev, Jakub Kicinski, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, linux-afs, linux-kernel,
Jeffrey Altman, stable
In-Reply-To: <20260702144919.172295-4-dhowells@redhat.com>
On Thu, Jul 2, 2026 at 11:49 AM David Howells <dhowells@redhat.com> wrote:
>
> In afs_make_call(), there's a race with async call reception and
> destruction. If a call is dispatched that doesn't have call->write_iter
> set (used to specify the data content for FS.StoreData), then the first
> rxrpc_kernel_send_data() will not set MSG_MORE in the msghdr.
>
> Once rxrpc_send_data() queues the last request packet, the response could
> come in at any time and cause the call to be completed and put. However,
> afs_make_call() will look at the call again to see it ->write_iter should
> be handled - something it's only allowed to do if it has its own ref on the
> call. Whilst this is the case for synchronous calls, it isn't true for
> async calls such as FS.FetchData.
>
> generic/650 plays games with randomly taking CPUs offline, and can
> interject a significant delay such that the call is deallocated before
> afs_make_call() gets to check call->write_iter - and a UAF ensues (caught
> by KASAN).
>
> BUG: KASAN: slab-use-after-free in afs_make_call+0x1c90/0x2210 [kafs]
> Read of size 8 at addr ffff888035e050e8 by task fsstress/1409
>
> Fix this by caching the call->write_iter and call->debug_id so that neither
> variable needs to be accessed after the first send.
>
> Fixes: eddf51f2bb2c ("afs: Make {Y,}FS.FetchData an asynchronous operation")
> Reported-by: Marc Dionne <marc.dionne@auristor.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
> cc: Eric Dumazet <edumazet@google.com>
> cc: "David S. Miller" <davem@davemloft.net>
> cc: Jakub Kicinski <kuba@kernel.org>
> cc: Paolo Abeni <pabeni@redhat.com>
> cc: Simon Horman <horms@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: stable@kernel.org
> ---
> fs/afs/rxrpc.c | 12 ++++++++----
> include/trace/events/afs.h | 6 +++---
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
> index d82916657a3d..05fcb9b6adde 100644
> --- a/fs/afs/rxrpc.c
> +++ b/fs/afs/rxrpc.c
> @@ -347,7 +347,9 @@ void afs_make_call(struct afs_call *call, gfp_t gfp)
> struct rxrpc_call *rxcall;
> struct msghdr msg;
> struct kvec iov[1];
> + unsigned int debug_id = call->debug_id;
> size_t len;
> + bool write_iter = call->write_iter;
> s64 tx_total_len;
> int ret;
>
> @@ -410,7 +412,7 @@ void afs_make_call(struct afs_call *call, gfp_t gfp)
> iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, iov, 1, call->request_size);
> msg.msg_control = NULL;
> msg.msg_controllen = 0;
> - msg.msg_flags = MSG_WAITALL | (call->write_iter ? MSG_MORE : 0);
> + msg.msg_flags = MSG_WAITALL | (write_iter ? MSG_MORE : 0);
>
> ret = rxrpc_kernel_send_data(call->net->socket, rxcall,
> &msg, call->request_size,
> @@ -418,7 +420,9 @@ void afs_make_call(struct afs_call *call, gfp_t gfp)
> if (ret < 0)
> goto error_do_abort;
>
> - if (call->write_iter) {
> + /* We lost our ref on call if MSG_MORE was set. */
> +
> + if (write_iter) {
> msg.msg_iter = *call->write_iter;
> msg.msg_flags &= ~MSG_MORE;
> trace_afs_send_data(call, &msg);
> @@ -427,9 +431,9 @@ void afs_make_call(struct afs_call *call, gfp_t gfp)
> call->rxcall, &msg,
> iov_iter_count(&msg.msg_iter),
> afs_notify_end_request_tx);
> - *call->write_iter = msg.msg_iter;
> + /* We lost our ref on call. */
>
> - trace_afs_sent_data(call, &msg, ret);
> + trace_afs_sent_data(debug_id, &msg, ret);
> if (ret < 0)
> goto error_do_abort;
> }
> diff --git a/include/trace/events/afs.h b/include/trace/events/afs.h
> index 1b3c48b5591d..cf7218efb861 100644
> --- a/include/trace/events/afs.h
> +++ b/include/trace/events/afs.h
> @@ -937,9 +937,9 @@ TRACE_EVENT(afs_send_data,
> );
>
> TRACE_EVENT(afs_sent_data,
> - TP_PROTO(struct afs_call *call, struct msghdr *msg, int ret),
> + TP_PROTO(unsigned int call_debug_id, struct msghdr *msg, int ret),
>
> - TP_ARGS(call, msg, ret),
> + TP_ARGS(call_debug_id, msg, ret),
>
> TP_STRUCT__entry(
> __field(unsigned int, call)
> @@ -949,7 +949,7 @@ TRACE_EVENT(afs_sent_data,
> ),
>
> TP_fast_assign(
> - __entry->call = call->debug_id;
> + __entry->call = call_debug_id;
> __entry->ret = ret;
> __entry->offset = msg->msg_iter.xarray_start + msg->msg_iter.iov_offset;
> __entry->count = iov_iter_count(&msg->msg_iter);
>
>
Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
Marc
^ permalink raw reply
* [PATCH net-next] net: airoha: add preliminary support to configure tx hw QoS queue during flowtable offloading
From: Lorenzo Bianconi @ 2026-07-03 11:02 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Add the plumbing to program the AIROHA_FOE_QID field in the PPE FOE
entry with a per-flow priority value during flowtable offload. This
allows the hardware to steer offloaded flows to a specific QoS queue
on the egress QDMA block for traffic forwarded between two interfaces
via hardware acceleration, bypassing the kernel forwarding path.
The priority parameter is currently always zero because netfilter does
not yet provide a mechanism to pass the skb priority field to the
flowtable offload driver. Once that support is added in the netfilter
subsystem, the driver will be able to extract the priority from the
flow rule and map it to the appropriate hardware queue.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index e7c78293002a..fdb973fc779c 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -331,7 +331,7 @@ static int airoha_ppe_foe_entry_prepare(struct airoha_eth *eth,
struct airoha_foe_entry *hwe,
struct net_device *netdev, int type,
struct airoha_flow_data *data,
- int l4proto)
+ int l4proto, u8 priority)
{
u32 qdata = FIELD_PREP(AIROHA_FOE_SHAPER_ID, 0x7f), ports_pad, val;
int wlan_etype = -EINVAL, dsa_port = airoha_get_dsa_port(&netdev);
@@ -386,7 +386,9 @@ static int airoha_ppe_foe_entry_prepare(struct airoha_eth *eth,
*/
channel = dsa_port >= 0 ? dsa_port : port->id;
channel = channel % AIROHA_NUM_QOS_CHANNELS;
- qdata |= FIELD_PREP(AIROHA_FOE_CHANNEL, channel);
+ priority = priority % AIROHA_NUM_QOS_QUEUES;
+ qdata |= FIELD_PREP(AIROHA_FOE_CHANNEL, channel) |
+ FIELD_PREP(AIROHA_FOE_QID, priority);
val |= FIELD_PREP(AIROHA_FOE_IB2_PSE_PORT, pse_port) |
AIROHA_FOE_IB2_PSE_QOS;
@@ -1079,10 +1081,10 @@ static int airoha_ppe_flow_offload_replace(struct airoha_eth *eth,
struct airoha_flow_data data = {};
struct net_device *odev = NULL;
struct flow_action_entry *act;
+ u8 l4proto = 0, priority = 0;
struct airoha_foe_entry hwe;
int err, i, offload_type;
u16 addr_type = 0;
- u8 l4proto = 0;
if (rhashtable_lookup(ð->flow_table, &f->cookie,
airoha_flow_table_params))
@@ -1177,7 +1179,7 @@ static int airoha_ppe_flow_offload_replace(struct airoha_eth *eth,
return -EINVAL;
err = airoha_ppe_foe_entry_prepare(eth, &hwe, odev, offload_type,
- &data, l4proto);
+ &data, l4proto, priority);
if (err)
return err;
---
base-commit: 9507d09b2b8fc775652f5c5670028daa9d83a2bd
change-id: 20260703-airoha-hw-qos-queue-stub-939714339f28
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH net 1/1] net: rds: reject oversized TCP receive messages
From: kernel test robot @ 2026-07-03 10:58 UTC (permalink / raw)
To: Ren Wei, netdev, linux-rdma, rds-devel
Cc: oe-kbuild-all, achender, davem, edumazet, pabeni, horms,
andy.grover, yuantan098, yifanwucs, tomapufckgml, zcliangcn,
dstsmallbird, bronzed_45_vested, enjou1224z
In-Reply-To: <c83365078ea649d7ab2d9c198a445469bffb2550.1782850818.git.bronzed_45_vested@icloud.com>
Hi Ren,
kernel test robot noticed the following build errors:
[auto build test ERROR on net/main]
url: https://github.com/intel-lab-lkp/linux/commits/Ren-Wei/net-rds-reject-oversized-TCP-receive-messages/20260703-135123
base: net/main
patch link: https://lore.kernel.org/r/c83365078ea649d7ab2d9c198a445469bffb2550.1782850818.git.bronzed_45_vested%40icloud.com
patch subject: [PATCH net 1/1] net: rds: reject oversized TCP receive messages
config: x86_64-buildonly-randconfig-006-20260703 (https://download.01.org/0day-ci/archive/20260703/202607031832.sftbLQWx-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260703/202607031832.sftbLQWx-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202607031832.sftbLQWx-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "__rds_conn_path_error" [net/rds/rds_tcp.ko] undefined!
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net v2] mac802154: remove interfaces with RCU list deletion
From: Miquel Raynal @ 2026-07-03 10:57 UTC (permalink / raw)
To: Yousef Alhouseen
Cc: alex.aring, stefan, davem, edumazet, kuba, pabeni, horms, marcel,
kuniyu, linux-wpan, netdev, linux-kernel, stable,
syzbot+36256deb69a588e9290e
In-Reply-To: <20260701164222.9094-1-alhouseenyousef@gmail.com>
Hello,
> Queue wake, stop, and disable paths walk local->interfaces under RCU.
> The bulk hardware teardown path removes entries with list_del(), so an
> asynchronous transmit completion can follow a poisoned list node in
> ieee802154_wake_queue().
>
> Use list_del_rcu() as in the single-interface removal path. The following
> unregister_netdevice() waits for in-flight RCU readers before freeing the
> netdevice, so no separate grace-period wait is needed.
>
> Fixes: 592dfbfc72f5 ("mac820154: move interface unregistration into iface")
> Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e
> Cc: stable@vger.kernel.org
> Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
FWIU, looks correct.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
^ 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