* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Nicolai Buchwitz @ 2026-04-06 20:24 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, netdev, workflows,
linux-doc, linux-kernel, mbloch
In-Reply-To: <345722f0-21b1-4970-8c45-ef85edf9d45b@suse.de>
On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
> [...]
>
> Hi Nicolai,
> maybe I am missing something but [2] isn't from sashiko.dev but from
> netdev AI CI instead. See:
> https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
You're right, I mixed up the two systems - the example I linked was
from the netdev AI bot, not Sashiko. My mistake on the link.
I stumbled over Sashiko when I noticed the name appearing more often
in other reviews and then found Jonathan's LWN article about it [1].
Both tools are actively reviewing patches on the list today. I think
it makes sense to document both rather than just one:
The netdev AI bot at netdev-ai.bots.linux.dev
Sashiko at sashiko.dev, which posts reviews publicly on its website
Both use the same review prompts by Chris Mason [2], so there is
common ground - though results will vary between them due to the
different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
on top of the usual AI uncertainty.
I think it would be useful to document that AI reviews are happening
but mixing AI bots might confuse people.
Agreed, I'll rework the patch to distinguish the two systems once
the discussion has been settled.
>
> The documentation mentioned for running the AI locally is correctly
> related to netdev AI bot.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
>> Check for findings on your submissions and address
>> +valid ones before a maintainer has to relay the same questions.
>> +
>
> I wonder what would be the consequences for this. If less experienced
> submitters are expected to address issues pointed out by AI bots they
> might work on something that isn't valid. AFAIU, the AI output is only
> forwarded to the submitter after a maintainer reviewed it and believes
> it makes sense.
Fair point. The wording should make clear that the local tooling is
an optional aid, not an obligation. I'll soften the language around
addressing findings.
Would appreciate input on how much detail is appropriate here -
should the doc just acknowledge that AI review exists and point to
the tooling, or go into more detail about the workflow?
[1] https://lwn.net/Articles/1063292/
[2]
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/networking.md
>
> Thanks,
> Fernando.
>
>> +You can also run AI reviews locally before submitting. Instructions
>> +and tooling are available at:
>> +
>> + https://netdev-ai.bots.linux.dev/ai-local.html
>> +
>> Testimonials / feedback
>> -----------------------
>>
Thanks for your input
Nicolai
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Russell King (Oracle) @ 2026-04-06 20:28 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Florian Fainelli, Andrew Lunn, Heiner Kallweit, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Broadcom internal kernel review list, netdev, linux-kernel
In-Reply-To: <faf651039d98fb9c1ffb40dbd98bb16b@tipi-net.de>
On Mon, Apr 06, 2026 at 08:29:38PM +0200, Nicolai Buchwitz wrote:
> On 6.4.2026 19:10, Russell King (Oracle) wrote:
> > On Mon, Apr 06, 2026 at 09:43:55AM -0700, Florian Fainelli wrote:
> > > That is almost a guarantee given, there will be a broken MAC
> >
> > Well, it already exists. modern i.MX platforms use stmmac, and some
> > bright spark wired lpi_intr_o together with the main stmmac interrupt
> > which causes interrupt storms when the receive path exits LPI. This
> > makes stmmac LPI unusable on this platform.
> >
> > So, if i.MX is paired with a PHY that can do its own EEE, then we
> > have this exact scenaro.
>
> For DT-based platforms (like the broken i.MX), this could be addressed
> similar to what we already have with eee-broken-* properties. For
> platforms without DT it's getting more complicated and I can't see a
> way without ethtool.
No. It's not that EEE itself is broken, it's that the integration of
the stmmac IP into the SoC is broken. We already have a solution to
disable LPI at stmmac (the STMMAC_FLAG_EEE_DISABLE flag).
That tells stmmac that the MAC doesn't support LPI signalling for an
speed and any interface mode, and will result in phy_disable_eee()
being called, which clears the EEE advertisement, disables LPI, EEE
enables, and fills phydev->eee_disabled_modes.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v2 net 0/6] Fix short frame transmission in enetc
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
This is a belated follow-up to Zefir Kurtisi's report:
https://lore.kernel.org/netdev/20260220132930.2521155-1-zefir.kurtisi@gmail.com/
which is that the ENETC misbehaves when transmitting packets smaller
than 16 octets sans FCS: it sends them but does not update the completed
index in the transmit BD ring. I did find a sentence in the reference
manual explicitly stating these short frames are not supported.
The original series (patches 5, 6) were focused on handling the invalid
frame geometries. However, review pointed out further issues in annex
code. Patches 1-4 handle those.
The main patch is 2/3, which Zefir already tested (in a simpler form)
and confirmed working in the thread from February. The code path should
be identical for his issue, so I've preserved the tag despite the
additions.
v1 at:
https://lore.kernel.org/netdev/20260401172246.1075883-1-vladimir.oltean@nxp.com/
Vladimir Oltean (6):
net: enetc: increment error counter in enetc_xdp_xmit() on DMA mapping
errors
net: enetc: linearize PTP event packets with one-step TX timestamping
net: enetc: ensure enetc_xdp_xmit() calls enetc_update_tx_ring_tail()
net: enetc: fix bogus TX ring consumer index after reinitialization
net: enetc: pad short frames in software
net: enetc: pad short XDP frames coming from devmap
drivers/net/ethernet/freescale/enetc/enetc.c | 38 +++++++++++++++++---
drivers/net/ethernet/freescale/enetc/enetc.h | 2 ++
include/net/xdp.h | 23 ++++++++++++
3 files changed, 59 insertions(+), 4 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 net 1/6] net: enetc: increment error counter in enetc_xdp_xmit() on DMA mapping errors
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
In-Reply-To: <20260406204122.167237-1-vladimir.oltean@nxp.com>
Failures in enetc_xdp_frame_to_xdp_tx_swbd() should cause a bump in the
XDP TX drop counters, like failures of enetc_xdp_tx() do below.
Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: patch is new
---
drivers/net/ethernet/freescale/enetc/enetc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index aa8a87124b10..ece10a58d44e 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1801,8 +1801,10 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
xdp_tx_bd_cnt = enetc_xdp_frame_to_xdp_tx_swbd(tx_ring,
xdp_redirect_arr,
frames[k]);
- if (unlikely(xdp_tx_bd_cnt < 0))
+ if (unlikely(xdp_tx_bd_cnt < 0)) {
+ tx_ring->stats.xdp_tx_drops++;
break;
+ }
if (unlikely(!enetc_xdp_tx(tx_ring, xdp_redirect_arr,
xdp_tx_bd_cnt))) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 net 2/6] net: enetc: linearize PTP event packets with one-step TX timestamping
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
In-Reply-To: <20260406204122.167237-1-vladimir.oltean@nxp.com>
Sashiko reports that enetc_ptp_parse() uses ptp_parse_header(), which
does not handle fragmented headers, and expects the entire area between
skb_mac_header() and the end of the PTP header to be linear.
When the driver fails to parse a fragmented PTP frame to find the
offsets to the originTimestamp and correctionField, it falls back to
two-step timestamping, which is technically not what user space asked
for, and it may not be prepared to receive the timestamped packet
through the socket error queue.
The problem can be avoided relatively easily by linearizing packets with
one-step timestamping requests prior to calling enetc_ptp_parse(). These
are infrequent enough that this should not be a performance problem.
Fixes: 7294380c5211 ("enetc: support PTP Sync packet one-step timestamping")
Link: https://sashiko.dev/#/patchset/20260401172246.1075883-1-vladimir.oltean%40nxp.com
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: patch is new
---
drivers/net/ethernet/freescale/enetc/enetc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index ece10a58d44e..ac6cad5605e4 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1059,6 +1059,11 @@ netdev_tx_t enetc_xmit(struct sk_buff *skb, struct net_device *ndev)
/* Fall back to two-step timestamp if not one-step Sync packet */
if (enetc_cb->flag & ENETC_F_TX_ONESTEP_SYNC_TSTAMP) {
+ if (unlikely(skb_linearize(skb))) {
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+ }
+
if (enetc_ptp_parse(skb, &udp, &msgtype, &twostep,
&offset1, &offset2) ||
msgtype != PTP_MSGTYPE_SYNC || twostep != 0) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 net 3/6] net: enetc: ensure enetc_xdp_xmit() calls enetc_update_tx_ring_tail()
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
In-Reply-To: <20260406204122.167237-1-vladimir.oltean@nxp.com>
enetc_xdp_xmit() keeps track of 3 numbers:
- num_frames: total length of passed struct xdp_frame **frames array
- xdp_tx_frm_cnt: number of frames successfully sent
- k: index of currently sent frame from array
With "k != xdp_tx_frm_cnt", the intention was to detect an early break
due to an inability to send a frame, and to trigger a TX doorbell
anyway.
However, that doesn't work because every time when the loop breaks,
k and xdp_tx_frm_cnt are mathematically equal.
The correct condition on which we should ring the doorbell is when at
least one frame was sent, and either the caller required us to flush, or
we couldn't enqueue the entire passed array.
Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: patch is new
---
drivers/net/ethernet/freescale/enetc/enetc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index ac6cad5605e4..5b97f9e668ba 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1823,7 +1823,8 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
xdp_tx_frm_cnt++;
}
- if (unlikely((flags & XDP_XMIT_FLUSH) || k != xdp_tx_frm_cnt))
+ if (unlikely(xdp_tx_frm_cnt && ((flags & XDP_XMIT_FLUSH) ||
+ xdp_tx_frm_cnt < num_frames)))
enetc_update_tx_ring_tail(tx_ring);
tx_ring->stats.xdp_tx += xdp_tx_frm_cnt;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 net 4/6] net: enetc: fix bogus TX ring consumer index after reinitialization
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
In-Reply-To: <20260406204122.167237-1-vladimir.oltean@nxp.com>
The TBCIR (Transmit Buffer Descriptor Ring Consumer Index) register has
the BD index as the lower 16 bits, but the upper 16 bits contain this
field:
STAT_ID: Status identifier. Incremented each time the BDR_INDEX is
updated and an error status bit was set for one of the processed BDs.
Clears on read.
If there was any transmit error prior to the ring reinitialization and
this is the first time we re-read the TBCIR register, reading it will
give us a value with non-zero upper bits, which is saved in
bdr->next_to_clean.
If subsequently NAPI gets invoked and enetc_clean_tx_ring() runs, this
will dereference the &tx_ring->tx_swbd[] for the bogus (and huge)
next_to_clean index, and will result in an out-of-bounds memory access.
Other places like enetc_bd_ready_count() do mask out the upper bits, so
let's do that here as well.
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: none
---
drivers/net/ethernet/freescale/enetc/enetc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index 5b97f9e668ba..a48ee3040b80 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -2604,7 +2604,8 @@ static void enetc_setup_txbdr(struct enetc_hw *hw, struct enetc_bdr *tx_ring)
* adjust sw indexes
*/
tx_ring->next_to_use = enetc_txbdr_rd(hw, idx, ENETC_TBPIR);
- tx_ring->next_to_clean = enetc_txbdr_rd(hw, idx, ENETC_TBCIR);
+ tx_ring->next_to_clean = enetc_txbdr_rd(hw, idx, ENETC_TBCIR) &
+ ENETC_TBCIR_IDX_MASK;
if (tx_ring->next_to_use != tx_ring->next_to_clean &&
!is_enetc_rev1(si)) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 net 5/6] net: enetc: pad short frames in software
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
In-Reply-To: <20260406204122.167237-1-vladimir.oltean@nxp.com>
The ENETC does not support BUF_LEN or FRM_LEN in TX buffer descriptors
less than 16. This is written in the reference manual of all SoCs
supported by the driver: LS1028A, i.MX943, i.MX95 etc.
Frames must not have a FRM_LEN that is less than 16 bytes. Frames of
0-15 bytes are not supported.
(...)
The first descriptor in a chain must not have a BUFF_LEN that is less
than 16 bytes.
I don't think proper attention was paid to this during development, we
found the text at the end of a bug investigation. Therefore, the driver
does not enforce this.
But the frame length is out of the driver's control, and the network
stack can actually send packets with skb->len smaller than that. The
result is unpleasant, as will be explained below, so for simplicity
sake, we just pad anything shorter than ETH_ZLEN.
Zefir Kurtisi found a case where transmitting L2 WNM keep-alive frames
through ENETC would soft-lockup the host through an IRQ storm. He later
distilled this into a small enetc-killer.c user space program which
sends a packet with MAC DA, MAC SA and EtherType IPv4 (14 octets in
length) through an AF_PACKET raw socket.
The IRQ storm is actually a curious effect of a chain of events.
The hardware behaviour, when an invalid BD is put in its TX ring, is
that it would transmit the packet as normal, update counters, raise
completion interrupt as normal, but it would just not advance the
consumer index of the ring (TBaCIR) to signify that the BD has been
consumed and is available for software to free. The ring will also get
its TBaSR[BUSY] bit persistently set to 1 afterwards.
It deserves an explanation why the behaviour above would lead to an
IRQ storm, since ENETC interrupts are message-based (MSI-X), and an
unhandled interrupt would typically just be lost rather than retrigger
itself as a wired interrupt would.
NAPI processing in ENETC has 3 steps:
I. the enetc_msix() hardirq handler disables RBaIER, TBaIER and sets
softirq processing to the 'pending' state.
II. the enetc_poll() softirq handler for the IRQ vector walks through
the TX rings affine to that vector, checks which ones have a TBCIR
updated since last time - enetc_bd_ready_count() - processes those
completed frames, and clears pending interrupts in these updated TX
rings by writing to TBaIDR. (I've excluded RX processing due to it
being irrelevant).
III. After the softirq handler does its round of checking all RX and TX
rings for updates, it re-enables all interrupts in RBaIER and
TBaIER that were previously disabled by the hardirq handler, and
exits.
Because the TX ring with the short frame is skipped at step II (TBCIR
wasn't updated as part of HW malfunction), its pending IRQ is not
cleared in TBaIDR by enetc_clean_tx_ring().
But because enetc_msix() disables TBaIER at step I and re-enables it at
step III, another MSI will be fired upon re-enabling it. This is what
completes the cycle and the driver goes back to step I.
So the driver misinterprets the mixed signals it's getting from the
hardware, and ends up causing a software-amplified IRQ storm.
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Reported-by: Zefir Kurtisi <zefir.kurtisi@westermo.com>
Closes: https://lore.kernel.org/netdev/b3d9136c-2803-4203-b1ea-1f9e62de80a1@gmail.com/
Tested-by: Zefir Kurtisi <zefir.kurtisi@westermo.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2: handle the BUF_LEN limitation too, independently of FRM_LEN
---
drivers/net/ethernet/freescale/enetc/enetc.c | 13 +++++++++++++
drivers/net/ethernet/freescale/enetc/enetc.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index a48ee3040b80..c70df45422e0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1050,6 +1050,19 @@ netdev_tx_t enetc_xmit(struct sk_buff *skb, struct net_device *ndev)
u8 udp, msgtype, twostep;
u16 offset1, offset2;
+ /* Hardware does not support transmit buffer descriptors with a total
+ * length of less than 16 bytes, or a first buffer size of less than
+ * 16 bytes.
+ */
+ if (unlikely(skb_headlen(skb) < ENETC_MIN_BUFF_SIZE &&
+ skb_linearize(skb))) {
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+ }
+
+ if (eth_skb_pad(skb))
+ return NETDEV_TX_OK;
+
/* Mark tx timestamp type on enetc_cb->flag if requires */
if ((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
(priv->active_offloads & ENETC_F_TX_TSTAMP_MASK))
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h
index aecd40aeef9c..819e643538b1 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -21,6 +21,8 @@
#define ENETC_MAX_MTU (ENETC_MAC_MAXFRM_SIZE - \
(ETH_FCS_LEN + ETH_HLEN + VLAN_HLEN))
+#define ENETC_MIN_BUFF_SIZE 16
+
#define ENETC_CBD_DATA_MEM_ALIGN 64
#define ENETC_MADDR_HASH_TBL_SZ 64
--
2.43.0
^ permalink raw reply related
* [PATCH v2 net 6/6] net: enetc: pad short XDP frames coming from devmap
From: Vladimir Oltean @ 2026-04-06 20:41 UTC (permalink / raw)
To: netdev
Cc: Zefir Kurtisi, Claudiu Manoil, Wei Fang, Clark Wang, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ioana Ciornei, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, bpf, imx, linux-kernel
In-Reply-To: <20260406204122.167237-1-vladimir.oltean@nxp.com>
Similar to the skb path issue explained in the previous change, ENETC
could end up transmitting short frames coming from XDP.
The way in which this could happen is a bit contrived, but it involves
XDP_REDIRECT from a veth interface pair.
As for enetc_xmit(), there are two separate limitations for the overall
FRM_LEN and for the head BUFF_LEN. For the head BUFF_LEN, we add a
direct restriction in enetc_xdp_xmit(), and for the overall FRM_LEN, we
introduce a xdp_frame_pad() best-effort generic helper which we call
from the same place.
This helper alters the frame, but that should be safe, because
ndo_xdp_xmit() is the hand-off function where the XDP frames become the
responsibility of the driver. AFAIU, struct xdp_frame doesn't have
multiple copies.
I say best-effort because xdp_frame_pad() can only expand the head
buffer of an XDP frame. It cannot expand the last fragment of a
multi-buffer XDP frame, because, unlike bpf_xdp_frags_increase_tail(),
it lacks access to the rxq->frag_size, aka the capacity of the chunk of
memory being pointed to by the fragment.
So, if the frame happens to be less than minimum Ethernet size, but
fragmented, callers of this function will have to drop it.
Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v1->v2:
- handle multi-buffer frames instead of being unaware of their
multi-buffer quality
- add separate restriction for BUFF_LEN
- increment drop counter
---
drivers/net/ethernet/freescale/enetc/enetc.c | 10 ++++++++-
include/net/xdp.h | 23 ++++++++++++++++++++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index c70df45422e0..196b7828e2aa 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1816,9 +1816,17 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
prefetchw(ENETC_TXBD(*tx_ring, tx_ring->next_to_use));
for (k = 0; k < num_frames; k++) {
+ struct xdp_frame *xdpf = frames[k];
+
+ if (unlikely(xdp_frame_pad(xdpf) ||
+ xdpf->len < ENETC_MIN_BUFF_SIZE)) {
+ tx_ring->stats.xdp_tx_drops++;
+ break;
+ }
+
xdp_tx_bd_cnt = enetc_xdp_frame_to_xdp_tx_swbd(tx_ring,
xdp_redirect_arr,
- frames[k]);
+ xdpf);
if (unlikely(xdp_tx_bd_cnt < 0)) {
tx_ring->stats.xdp_tx_drops++;
break;
diff --git a/include/net/xdp.h b/include/net/xdp.h
index aa742f413c35..276afc9aa21d 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -477,6 +477,29 @@ xdp_get_frame_len(const struct xdp_frame *xdpf)
return len;
}
+static inline int xdp_frame_pad(struct xdp_frame *xdpf)
+{
+ unsigned int total_len, pad;
+ void *sinfo;
+
+ total_len = xdp_get_frame_len(xdpf);
+ if (likely(total_len >= ETH_ZLEN))
+ return 0;
+
+ if (unlikely(xdp_frame_has_frags(xdpf)))
+ return -EOPNOTSUPP;
+
+ pad = ETH_ZLEN - total_len;
+ sinfo = xdp_get_shared_info_from_frame(xdpf);
+ if (unlikely(xdpf->data + xdpf->len + pad > sinfo))
+ return -ENOMEM;
+
+ memset(xdpf->data + xdpf->len, 0, pad);
+ xdpf->len += pad;
+
+ return 0;
+}
+
int __xdp_rxq_info_reg(struct xdp_rxq_info *xdp_rxq,
struct net_device *dev, u32 queue_index,
unsigned int napi_id, u32 frag_size);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v3 3/3] gve: implement PTP gettimex64
From: Jordan Rhee @ 2026-04-06 20:41 UTC (permalink / raw)
To: Jacob Keller
Cc: Harshitha Ramamurthy, netdev, joshwash, andrew+netdev, davem,
edumazet, kuba, pabeni, richardcochran, willemb, nktgrg, jfraker,
ziweixiao, maolson, thostet, jefrogers, alok.a.tiwari, yyd,
linux-kernel, Naman Gulati
In-Reply-To: <d02145e3-8ac4-4057-a888-3ce074a295ea@intel.com>
On Fri, Apr 3, 2026 at 2:18 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> On 4/3/2026 12:44 PM, Harshitha Ramamurthy wrote:
> > From: Jordan Rhee <jordanrhee@google.com>
> >
> > Enable chrony and phc2sys to synchronize system clock to NIC clock.
> >
> > The system cycle counters are sampled by the device to minimize the
> > uncertainty window. If the system times are sampled in the host, the
> > delta between pre and post readings is 100us or more due to AQ command
> > latency. The system times returned by the device have a delta of ~1us,
> > which enables significantly more accurate clock synchronization.
> >
> > Reviewed-by: Willem de Bruijn <willemb@google.com>
> > Reviewed-by: Kevin Yang <yyd@google.com>
> > Reviewed-by: Naman Gulati <namangulati@google.com>
> > Signed-off-by: Jordan Rhee <jordanrhee@google.com>
> > Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > ---
>
> > +/*
> > + * Convert a raw cycle count (e.g. from get_cycles()) to the system clock
> > + * type specified by clockid. The system_time_snapshot must be taken before
> > + * the cycle counter is sampled.
> > + */
> > +static int gve_cycles_to_timespec64(struct gve_priv *priv, clockid_t clockid,
> > + struct system_time_snapshot *snap,
> > + u64 cycles, struct timespec64 *ts)
> > +{
> > + struct gve_cycles_to_clock_callback_ctx ctx = {0};
> > + struct system_device_crosststamp xtstamp;
> > + int err;
> > +
> > + ctx.cycles = cycles;
> > + err = get_device_system_crosststamp(gve_cycles_to_clock_fn, &ctx, snap,
> > + &xtstamp);
> > + if (err) {
> > + dev_err_ratelimited(&priv->pdev->dev,
> > + "get_device_system_crosststamp() failed to convert %lld cycles to system time: %d\n",
> > + cycles,
> > + err);
> > + return err;
> > + }
> > +
>
> This looks a lot like a cross timestamp (i.e. something like PCIe PTM)
> Why not just implement the .crosstimestamp and PTP_SYS_OFF_PRECISE? Does
> that not work properly? Or is this not really a cross timestamp despite
> use of the get_device_system_crosststamp handler? :D
.crosstimestamp is for devices that support simultaneous NIC and
system timestamps. Devices that don't support simultaneous timestamps
have to take a system time sandwich by calling
ptp_read_system_prets()/ptp_read_system_postts() on either side of the
NIC timestamp. Upper layers (e.g. chrony) use the sandwich delta in
nontrivial ways when estimating the system clock / NIC clock offset.
This is information that must be preserved, and it would be incorrect
to implement .crosstimestamp by returning the midpoint of the
sandwich, as tempting as that implementation might be.
Gvnic does not support simultaneous NIC and system timestamps, so it
must use the sandwich technique. Since the NIC timestamp is obtained
using a firmware (hypervisor) call, the uncertainty window would be
too large if it were taken inside the VM. Gvnic takes the sandwich in
the hypervisor and returns the raw TSC values to the VM.
get_device_system_crosststamp() is used to convert the TSCs to system
times, which I believe is the only correct way to do this conversion.
Jordan
>
> Thanks,
> Jake
>
> > + switch (clockid) {
> > + case CLOCK_REALTIME:
> > + *ts = ktime_to_timespec64(xtstamp.sys_realtime);
> > + break;
> > + case CLOCK_MONOTONIC_RAW:
> > + *ts = ktime_to_timespec64(xtstamp.sys_monoraw);
> > + break;
> > + default:
> > + dev_err_ratelimited(&priv->pdev->dev,
> > + "Cycle count conversion to clockid %d not supported\n",
> > + clockid);
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + return 0;
> > +}
> > +
^ permalink raw reply
* Re: [PATCH net-next] net: phy: realtek: get rid of magic numbers in rtl8201_config_intr()
From: Daniel Golle @ 2026-04-06 20:43 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni,
vladimir.oltean, michael, markus.stockhausen, ih, rmk+kernel,
netdev, linux-kernel
In-Reply-To: <20260406201222.1043396-1-olek2@wp.pl>
On Mon, Apr 06, 2026 at 10:12:12PM +0200, Aleksander Jan Bajkowski wrote:
> Replace the magic numbers with defines. Register names were obtained from
> publicly available documentation[1]. This should make it clear what's going
> on in the code.
>
> 1. RTL8201F/RTL8201FL/RTL8201FN Rev. 1.4 Datasheet
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
^ permalink raw reply
* Re: [PATCH net-next] net: phy: realtek: get rid of magic numbers in rtl8201_config_intr()
From: Nicolai Buchwitz @ 2026-04-06 20:44 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, daniel,
vladimir.oltean, michael, markus.stockhausen, ih, rmk+kernel,
netdev, linux-kernel
In-Reply-To: <20260406201222.1043396-1-olek2@wp.pl>
On 6.4.2026 22:12, Aleksander Jan Bajkowski wrote:
> Replace the magic numbers with defines. Register names were obtained
> from
> publicly available documentation[1]. This should make it clear what's
> going
> on in the code.
>
> 1. RTL8201F/RTL8201FL/RTL8201FN Rev. 1.4 Datasheet
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
> drivers/net/phy/realtek/realtek_main.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c
> b/drivers/net/phy/realtek/realtek_main.c
> index 75565fbdbf6d..e78f3b9e89db 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -22,7 +22,14 @@
> #include "../phylib.h"
> #include "realtek.h"
>
> +#define RTL8201F_IER_PAGE 0x07
> #define RTL8201F_IER 0x13
> +#define RTL8201F_IER_LINK BIT(13)
> +#define RTL8201F_IER_DUPLEX BIT(12)
> +#define RTL8201F_IER_ANERR BIT(11)
> +#define RTL8201F_IER_MASK (RTL8201F_IER_ANERR | \
> + RTL8201F_IER_DUPLEX | \
> + RTL8201F_IER_LINK)
>
> #define RTL8201F_ISR 0x1e
> #define RTL8201F_ISR_ANERR BIT(15)
> @@ -346,11 +353,13 @@ static int rtl8201_config_intr(struct phy_device
> *phydev)
> if (err)
> return err;
>
> - val = BIT(13) | BIT(12) | BIT(11);
> - err = phy_write_paged(phydev, 0x7, RTL8201F_IER, val);
> + val = RTL8201F_IER_MASK;
> + err = phy_write_paged(phydev, RTL8201F_IER_PAGE,
> + RTL8201F_IER, val);
> } else {
> val = 0;
> - err = phy_write_paged(phydev, 0x7, RTL8201F_IER, val);
> + err = phy_write_paged(phydev, RTL8201F_IER_PAGE,
> + RTL8201F_IER, val);
> if (err)
> return err;
Matches the datasheet (RTL8201F/RTL8201FL/RTL8201FN Rev. 1.4 Datasheet)
Reviewed-by: Nicolai Buchwitz nb@tipi-net.de
^ permalink raw reply
* Re: [net-next v2 3/3] selftests/net: Test PACKET_AUXDATA
From: Willem de Bruijn @ 2026-04-06 20:56 UTC (permalink / raw)
To: Joe Damato, Willem de Bruijn
Cc: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, dalias, andrew+netdev,
linux-kernel, willemb, linux-kselftest
In-Reply-To: <adPm+n8Uw3O2S5bY@devvm20253.cco0.facebook.com>
Joe Damato wrote:
> On Sat, Apr 04, 2026 at 11:30:09PM -0400, Willem de Bruijn wrote:
> > Willem de Bruijn wrote:
> > > Joe Damato wrote:
>
> [...]
>
> > > > -static void do_rx(int fd, int expected_len, char *expected)
> > > > +static void check_aux_data(struct cmsghdr *cmsg, int expected_len)
> > > > {
> > > > + struct tpacket_auxdata *adata;
> > > > +
> > > > + if (!cmsg)
> > > > + error(1, 0, "auxdata null");
> > > > +
> > > > + if (cmsg->cmsg_level != SOL_PACKET)
> > > > + error(1, 0, "cmsg_level != SOL_PACKET");
> > > > +
> > > > + if (cmsg->cmsg_type != PACKET_AUXDATA)
> > > > + error(1, 0, "cmsg_type != PACKET_AUXDATA");
> > > > +
> > > > + adata = (struct tpacket_auxdata *)CMSG_DATA(cmsg);
> > >
> > > Sashiko had another interesting observation that this access may be
> > > unaligned, as cmsg_buf[1024] has 1-byte alignment.
> > >
> > > That is not new in this patch. Indeed most tests in this dir just
> > > deference msg_control as struct cmsghdr * and CMSG_DATA as whatever
> > > domain specific type.
> > >
> > > The man page also warns about this and suggests using memcpy to
> > > access CMSG_DATA. Not sure why it does not warn about the other
> > > cmsg_.. fields.
> >
> > The commit that introduced that has more context
> >
> > https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man/man3/cmsg.3?id=36d25246b4333513fefdbec7f78f29d193cf5d9a
> >
> > It points out 32-bit platforms where cmsghdr is 12 bytes.
> >
> > At least one example given, ptpd, uses a union to ensure alignment
> >
> > union {
> > struct cmsghdr cm;
> > char control[256];
> > } cmsg_un;
> >
> > But at least one other example, ssmping, does not. So I think not even
> > the 4B (on 32-bit archs) of cmsghdr fields can be depended on.
>
> I'm fine with adding an "__attribute__((aligned(8)))" to be safe, but FWIW, I
> think the key point from the commit message linked above is:
>
> shows access to int payload via *(int *)CMSG_DATA(cmsg) (of course
> int is safe because its alignment is <= header alignment, but this
> is not mentioned).
But that conditional on having a union as showed to make sure that
the structure has the struct cmsghdr alignment.
A bare char[] won't have that.
Anyway, in practice on the platforms we test this hasn't been an issue.
Fine to copy the example from other tests, leaving out the alignment.
I will follow-up with one patch to update all of them at once, once
I'm certain that I did not overlook some other mechanism that
implicitly does guarantee this alignment on all platforms.
> struct tpacket_auxdata only has u32 and u16, so 4 byte alignment seems fine
> and I don't think the issue applies in this particular case. But, as I said
> above, I am fine with adding the attribute to be defensive.
^ permalink raw reply
* Re: [PATCH v12 5/6] tls: add hardware offload key update support
From: Sabrina Dubroca @ 2026-04-06 20:59 UTC (permalink / raw)
To: Rishikesh Jethwani
Cc: netdev, saeedm, tariqt, mbloch, borisp, john.fastabend, kuba,
davem, pabeni, edumazet, leon
In-Reply-To: <20260402235511.664801-6-rjethwani@purestorage.com>
2026-04-02, 17:55:10 -0600, Rishikesh Jethwani wrote:
> During a TLS 1.3 KeyUpdate the NIC key cannot be replaced immediately
> if previously encrypted HW records are awaiting ACK. start_rekey sets
> up a temporary SW context with the new key and redirects sendmsg through
> tls_sw_sendmsg_locked. When no records are pending, complete_rekey runs
> inline during setsockopt. Otherwise, clean_acked sets REKEY_READY once
> all old-key records are ACKed, and the next sendmsg calls complete_rekey.
> complete_rekey flushes remaining SW records, reinstalls HW offload at
> the current write_seq, and frees the temporary context.
>
> If another KeyUpdate arrives while a rekey is already pending,
> start_rekey just re-keys the existing SW AEAD in place.
>
> If complete_rekey fails (tls_dev_add or crypto_aead_setkey),
> we stay in SW mode (REKEY_FAILED) until a subsequent rekey
> succeeds, while maintaining TLS_HW configuration.
>
> Tested on Mellanox ConnectX-6 Dx (Crypto Enabled) with multiple
> TLS 1.3 key update cycles.
Something here doesn't seem to work. I have a very simple
client/server pair where one side just loops doing large send()s and
does a rekey (send keyupdate + change key) every N iterations (I've
set N large enough that it goes about 5 seconds between rekeys), and
the other receives all the data and changes its RX key when it sees a
keyupdate. If both sides are doing SW, it works. If I configure either
side to use offload, decrypt fails after the rekey unless I add a
small sleep() just after changing keys on the TX side.
--
Sabrina
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Laurent Pinchart @ 2026-04-06 21:06 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Fernando Fernandez Mancera, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev, workflows, linux-doc, linux-kernel, mbloch
In-Reply-To: <56c5bdfe2e37738e47b3b4d22e21697c@tipi-net.de>
On Mon, Apr 06, 2026 at 10:24:14PM +0200, Nicolai Buchwitz wrote:
> On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
> > [...]
>
> >
> > Hi Nicolai,
> > maybe I am missing something but [2] isn't from sashiko.dev but from
> > netdev AI CI instead. See:
> > https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
>
> You're right, I mixed up the two systems - the example I linked was
> from the netdev AI bot, not Sashiko. My mistake on the link.
>
> I stumbled over Sashiko when I noticed the name appearing more often
> in other reviews and then found Jonathan's LWN article about it [1].
>
> Both tools are actively reviewing patches on the list today. I think
> it makes sense to document both rather than just one:
>
> The netdev AI bot at netdev-ai.bots.linux.dev
> Sashiko at sashiko.dev, which posts reviews publicly on its website
> Both use the same review prompts by Chris Mason [2], so there is
> common ground - though results will vary between them due to the
> different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
> on top of the usual AI uncertainty.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
> Agreed, I'll rework the patch to distinguish the two systems once
> the discussion has been settled.
>
> > The documentation mentioned for running the AI locally is correctly
> > related to netdev AI bot.
> >
> > I think it would be useful to document that AI reviews are happening
> > but mixing AI bots might confuse people.
> >
> >> Check for findings on your submissions and address
> >> +valid ones before a maintainer has to relay the same questions.
> >> +
> >
> > I wonder what would be the consequences for this. If less experienced
> > submitters are expected to address issues pointed out by AI bots they
> > might work on something that isn't valid. AFAIU, the AI output is only
> > forwarded to the submitter after a maintainer reviewed it and believes
> > it makes sense.
>
> Fair point. The wording should make clear that the local tooling is
> an optional aid, not an obligation. I'll soften the language around
> addressing findings.
>
> Would appreciate input on how much detail is appropriate here -
> should the doc just acknowledge that AI review exists and point to
> the tooling, or go into more detail about the workflow?
In general, if a workflow is expected by a subsystem, it should be
documented. I don't see much to be gained from not telling submitters
what they're expecting to do.
More precisely in this case, as a submitter, I would take it pretty
badly if I was told to act on the output of a tool that is prone to
hallucinations without a maintainer first triaging the comments.
> [1] https://lwn.net/Articles/1063292/
> [2] https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/networking.md
>
> >> +You can also run AI reviews locally before submitting. Instructions
> >> +and tooling are available at:
> >> +
> >> + https://netdev-ai.bots.linux.dev/ai-local.html
> >> +
> >> Testimonials / feedback
> >> -----------------------
> >>
>
> Thanks for your input
>
> Nicolai
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Fernando Fernandez Mancera @ 2026-04-06 21:14 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, netdev, workflows,
linux-doc, linux-kernel, mbloch
In-Reply-To: <56c5bdfe2e37738e47b3b4d22e21697c@tipi-net.de>
On 4/6/26 10:24 PM, Nicolai Buchwitz wrote:
> On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
>> [...]
>
>>
>> Hi Nicolai,
>> maybe I am missing something but [2] isn't from sashiko.dev but from
>> netdev AI CI instead. See: https://netdev-ai.bots.linux.dev/ai-
>> review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
>
> You're right, I mixed up the two systems - the example I linked was
> from the netdev AI bot, not Sashiko. My mistake on the link.
>
> I stumbled over Sashiko when I noticed the name appearing more often
> in other reviews and then found Jonathan's LWN article about it [1].
>
> Both tools are actively reviewing patches on the list today. I think
> it makes sense to document both rather than just one:
>
> The netdev AI bot at netdev-ai.bots.linux.dev
> Sashiko at sashiko.dev, which posts reviews publicly on its website
> Both use the same review prompts by Chris Mason [2], so there is
> common ground - though results will vary between them due to the
> different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
> on top of the usual AI uncertainty.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
> Agreed, I'll rework the patch to distinguish the two systems once
> the discussion has been settled.
>
>>
>> The documentation mentioned for running the AI locally is correctly
>> related to netdev AI bot.
>>
>> I think it would be useful to document that AI reviews are happening
>> but mixing AI bots might confuse people.
>>
>>> Check for findings on your submissions and address
>>> +valid ones before a maintainer has to relay the same questions.
>>> +
>>
>> I wonder what would be the consequences for this. If less experienced
>> submitters are expected to address issues pointed out by AI bots they
>> might work on something that isn't valid. AFAIU, the AI output is only
>> forwarded to the submitter after a maintainer reviewed it and believes
>> it makes sense.
>
> Fair point. The wording should make clear that the local tooling is
> an optional aid, not an obligation. I'll soften the language around
> addressing findings.
>
Thank you! Regarding this topic it seems people have been already
discussing this around other subsystems [1]. It might be useful to check
out similar discussions and outcomes.
[1] https://lwn.net/Articles/1064830/
> Would appreciate input on how much detail is appropriate here -
> should the doc just acknowledge that AI review exists and point to
> the tooling, or go into more detail about the workflow?
>
To be honest that is hard for me to tell, I am not a maintainer and not
the one doing the forwarding currently. I think there isn't an official
workflow regarding this. Maybe a good starter would be to just mention
that they exist. Or maybe this is a good opportunity to define an
official workflow!
Thanks,
Fernando.
^ permalink raw reply
* Re: [net-next v2 2/3] selftests/net: Test PACKET_STATISTICS drops
From: Willem de Bruijn @ 2026-04-06 21:20 UTC (permalink / raw)
To: Joe Damato, Willem de Bruijn
Cc: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, andrew+netdev,
linux-kernel, willemb, linux-kselftest
In-Reply-To: <adPfTwbARPVFLys8@devvm20253.cco0.facebook.com>
Joe Damato wrote:
> On Sat, Apr 04, 2026 at 11:08:15AM -0400, Willem de Bruijn wrote:
> > Joe Damato wrote:
>
> [...]
>
> > > @@ -396,6 +424,11 @@ static void run_test(void)
> > >
> > > total_len = do_tx();
> > >
> > > + if (cfg_drop) {
> > > + check_packet_stats(fds);
> > > + goto out;
> > > + }
> >
> > Sashiko pointed out
>
> In the future, please link to the AI report.
>
> > that there may be a race here between rx
> > processing in the softirq and check_packet_stats. Seems plausible.
>
> Can you elaborate why this is true?
>
> I could be wrong, but I scanned the code and __local_bh_enable_ip seems to run
> softirq synchronously in this case, so I think the code is correct.
You mean that after the return to user in sendmsg, the packets are
guaranteed to have been queued to the sd->input_pkt_queue, the napi
schedule was run by enqueue_to_backlog and napi was run on this
cpu as a result of reenabling BH. At the end of dev_queue_xmit? I
recall that there may be a common one on syscall return too, but the
details elude me right now.
Either way, makes sense. I had not fully appreciated that the
softirq schedule is this deterministic.
^ permalink raw reply
* [PATCH net-next 0/4] dsa_loop and platform_data cleanups
From: Vladimir Oltean @ 2026-04-06 21:21 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn
While working to add some new features to dsa_loop, I gathered a number
of cleanup patches. They mostly remove some data structures that became
unused after the multi-switch platforms were migrated to the modern DT
bindings.
Vladimir Oltean (4):
net: dsa: remove struct platform_data
net: dsa: clean up struct dsa_chip_data
net: dsa: remove unused platform_data definitions
net: dsa: eliminate <linux/dsa/loop.h>
Documentation/networking/dsa/dsa.rst | 5 ----
drivers/net/dsa/dsa_loop.c | 35 ++++++++++++++++++++++-
include/linux/dsa/loop.h | 42 ----------------------------
include/linux/platform_data/dsa.h | 40 --------------------------
4 files changed, 34 insertions(+), 88 deletions(-)
delete mode 100644 include/linux/dsa/loop.h
--
2.43.0
^ permalink raw reply
* [PATCH net-next 1/4] net: dsa: remove struct platform_data
From: Vladimir Oltean @ 2026-04-06 21:21 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn
In-Reply-To: <20260406212158.721806-1-vladimir.oltean@nxp.com>
This is not used anywhere in the kernel.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Documentation/networking/dsa/dsa.rst | 5 -----
include/linux/platform_data/dsa.h | 17 -----------------
2 files changed, 22 deletions(-)
diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst
index 5c79740a533b..fd3c254ced1d 100644
--- a/Documentation/networking/dsa/dsa.rst
+++ b/Documentation/networking/dsa/dsa.rst
@@ -383,11 +383,6 @@ DSA data structures are defined in ``include/net/dsa.h`` as well as
well as various properties of its ports: names/labels, and finally a routing
table indication (when cascading switches)
-- ``dsa_platform_data``: platform device configuration data which can reference
- a collection of dsa_chip_data structures if multiple switches are cascaded,
- the conduit network device this switch tree is attached to needs to be
- referenced
-
- ``dsa_switch_tree``: structure assigned to the conduit network device under
``dsa_ptr``, this structure references a dsa_platform_data structure as well as
the tagging protocol supported by the switch tree, and which receive/transmit
diff --git a/include/linux/platform_data/dsa.h b/include/linux/platform_data/dsa.h
index d4d9bf2060a6..fec1ae5bddb9 100644
--- a/include/linux/platform_data/dsa.h
+++ b/include/linux/platform_data/dsa.h
@@ -48,21 +48,4 @@ struct dsa_chip_data {
s8 rtable[DSA_MAX_SWITCHES];
};
-struct dsa_platform_data {
- /*
- * Reference to a Linux network interface that connects
- * to the root switch chip of the tree.
- */
- struct device *netdev;
- struct net_device *of_netdev;
-
- /*
- * Info structs describing each of the switch chips
- * connected via this network interface.
- */
- int nr_chips;
- struct dsa_chip_data *chip;
-};
-
-
#endif /* __DSA_PDATA_H */
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 2/4] net: dsa: clean up struct dsa_chip_data
From: Vladimir Oltean @ 2026-04-06 21:21 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn
In-Reply-To: <20260406212158.721806-1-vladimir.oltean@nxp.com>
This has accumulated some fields which are no longer parsed by the core
or set by any driver. Remove them.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
include/linux/platform_data/dsa.h | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/include/linux/platform_data/dsa.h b/include/linux/platform_data/dsa.h
index fec1ae5bddb9..031f4cf83ae2 100644
--- a/include/linux/platform_data/dsa.h
+++ b/include/linux/platform_data/dsa.h
@@ -10,12 +10,6 @@ struct net_device;
#define DSA_RTABLE_NONE -1
struct dsa_chip_data {
- /*
- * How to access the switch configuration registers.
- */
- struct device *host_dev;
- int sw_addr;
-
/*
* Reference to network devices
*/
@@ -24,12 +18,6 @@ struct dsa_chip_data {
/* set to size of eeprom if supported by the switch */
int eeprom_len;
- /* Device tree node pointer for this specific switch chip
- * used during switch setup in case additional properties
- * and resources needs to be used
- */
- struct device_node *of_node;
-
/*
* The names of the switch's ports. Use "cpu" to
* designate the switch port that the cpu is connected to,
@@ -38,14 +26,6 @@ struct dsa_chip_data {
* or any other string to indicate this is a physical port.
*/
char *port_names[DSA_MAX_PORTS];
- struct device_node *port_dn[DSA_MAX_PORTS];
-
- /*
- * An array of which element [a] indicates which port on this
- * switch should be used to send packets to that are destined
- * for switch a. Can be NULL if there is only one switch chip.
- */
- s8 rtable[DSA_MAX_SWITCHES];
};
#endif /* __DSA_PDATA_H */
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 4/4] net: dsa: eliminate <linux/dsa/loop.h>
From: Vladimir Oltean @ 2026-04-06 21:21 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn
In-Reply-To: <20260406212158.721806-1-vladimir.oltean@nxp.com>
There is no reason at all to export these data types to the global
include directory.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/dsa/dsa_loop.c | 35 ++++++++++++++++++++++++++++++-
include/linux/dsa/loop.h | 42 --------------------------------------
2 files changed, 34 insertions(+), 43 deletions(-)
delete mode 100644 include/linux/dsa/loop.h
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index b41254b3ac42..7058faf23592 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -14,13 +14,46 @@
#include <linux/workqueue.h>
#include <linux/module.h>
#include <linux/if_bridge.h>
-#include <linux/dsa/loop.h>
+#include <linux/if_vlan.h>
+#include <linux/types.h>
#include <net/dsa.h>
#define DSA_LOOP_NUM_PORTS 6
#define DSA_LOOP_CPU_PORT (DSA_LOOP_NUM_PORTS - 1)
#define NUM_FIXED_PHYS (DSA_LOOP_NUM_PORTS - 2)
+struct dsa_loop_vlan {
+ u16 members;
+ u16 untagged;
+};
+
+struct dsa_loop_mib_entry {
+ char name[ETH_GSTRING_LEN];
+ unsigned long val;
+};
+
+enum dsa_loop_mib_counters {
+ DSA_LOOP_PHY_READ_OK,
+ DSA_LOOP_PHY_READ_ERR,
+ DSA_LOOP_PHY_WRITE_OK,
+ DSA_LOOP_PHY_WRITE_ERR,
+ __DSA_LOOP_CNT_MAX,
+};
+
+struct dsa_loop_port {
+ struct dsa_loop_mib_entry mib[__DSA_LOOP_CNT_MAX];
+ u16 pvid;
+ int mtu;
+};
+
+struct dsa_loop_priv {
+ struct mii_bus *bus;
+ unsigned int port_base;
+ struct dsa_loop_vlan vlans[VLAN_N_VID];
+ struct net_device *netdev;
+ struct dsa_loop_port ports[DSA_MAX_PORTS];
+};
+
struct dsa_loop_pdata {
/* Must be first, such that dsa_register_switch() can access this
* without gory pointer manipulations
diff --git a/include/linux/dsa/loop.h b/include/linux/dsa/loop.h
deleted file mode 100644
index b8fef35591aa..000000000000
--- a/include/linux/dsa/loop.h
+++ /dev/null
@@ -1,42 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef DSA_LOOP_H
-#define DSA_LOOP_H
-
-#include <linux/if_vlan.h>
-#include <linux/types.h>
-#include <linux/ethtool.h>
-#include <net/dsa.h>
-
-struct dsa_loop_vlan {
- u16 members;
- u16 untagged;
-};
-
-struct dsa_loop_mib_entry {
- char name[ETH_GSTRING_LEN];
- unsigned long val;
-};
-
-enum dsa_loop_mib_counters {
- DSA_LOOP_PHY_READ_OK,
- DSA_LOOP_PHY_READ_ERR,
- DSA_LOOP_PHY_WRITE_OK,
- DSA_LOOP_PHY_WRITE_ERR,
- __DSA_LOOP_CNT_MAX,
-};
-
-struct dsa_loop_port {
- struct dsa_loop_mib_entry mib[__DSA_LOOP_CNT_MAX];
- u16 pvid;
- int mtu;
-};
-
-struct dsa_loop_priv {
- struct mii_bus *bus;
- unsigned int port_base;
- struct dsa_loop_vlan vlans[VLAN_N_VID];
- struct net_device *netdev;
- struct dsa_loop_port ports[DSA_MAX_PORTS];
-};
-
-#endif /* DSA_LOOP_H */
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 3/4] net: dsa: remove unused platform_data definitions
From: Vladimir Oltean @ 2026-04-06 21:21 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn
In-Reply-To: <20260406212158.721806-1-vladimir.oltean@nxp.com>
Pretty self-explanatory, nobody needs these.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
include/linux/platform_data/dsa.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/platform_data/dsa.h b/include/linux/platform_data/dsa.h
index 031f4cf83ae2..77424bb24723 100644
--- a/include/linux/platform_data/dsa.h
+++ b/include/linux/platform_data/dsa.h
@@ -3,11 +3,8 @@
#define __DSA_PDATA_H
struct device;
-struct net_device;
-#define DSA_MAX_SWITCHES 4
#define DSA_MAX_PORTS 12
-#define DSA_RTABLE_NONE -1
struct dsa_chip_data {
/*
--
2.43.0
^ permalink raw reply related
* [PATCH net 0/9][pull request] Intel Wired LAN Driver Updates 2026-04-06 (idpf, ice, ixgbe, ixgbevf, igb, e1000)
From: Tony Nguyen @ 2026-04-06 21:30 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev; +Cc: Tony Nguyen
Emil converts to use spinlock_t for virtchnl transactions to make
consistent use of the xn_bm_lock when accessing the free_xn_bm bitmap,
while also avoiding nested raw/bh spinlock issue on PREEMPT_RT kernels.
He also sets payload size before calling the async handler, to make sure
it doesn't error out prematurely due to invalid size check for idpf.
Kohei Enju changes WARN_ON for missing PTP control PF to a dev_info() on
ice as there are cases where this is expected and acceptable.
Petr Oros fixes conditions in which error paths failed to call
ice_ptp_port_phy_restart() breaking PTP functionality on ice.
Alex significantly reduces reporting of driver information, and time
under RTNL locl, on ixgbe e610 devices by reducing reads of flash info
only on events that could change it.
Michal Schmidt adds missing Hyper-V op on ixgbevf.
Alex Dvoretsky removes call to napi_synchronize() in igb_down() to
resolve a deadlock.
Agalakov Daniil adds error check on e1000 for failed EEPROM read.
The following are changes since commit 1caa871bb0615e2b68aa11bb7b453eeac770ea1d:
Merge branch 'net-stmmac-fix-tegra234-mgbe-clock'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 200GbE
Agalakov Daniil (1):
e1000: check return value of e1000_read_eeprom
Aleksandr Loktionov (1):
ixgbe: stop re-reading flash on every get_drvinfo for e610
Alex Dvoretsky (1):
igb: remove napi_synchronize() in igb_down()
Emil Tantilov (3):
idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
idpf: improve locking around idpf_vc_xn_push_free()
idpf: set the payload size before calling the async handler
Kohei Enju (1):
ice: ptp: don't WARN when controlling PF is unavailable
Michal Schmidt (1):
ixgbevf: add missing negotiate_features op to Hyper-V ops table
Petr Oros (1):
ice: fix PTP timestamping broken by SyncE code on E825C
.../net/ethernet/intel/e1000/e1000_ethtool.c | 8 ++++-
drivers/net/ethernet/intel/ice/ice_ptp.c | 30 ++++++++++++-------
.../net/ethernet/intel/idpf/idpf_virtchnl.c | 20 +++++++------
.../net/ethernet/intel/idpf/idpf_virtchnl.h | 5 ++--
drivers/net/ethernet/intel/igb/igb_main.c | 3 +-
.../ethernet/intel/ixgbe/devlink/devlink.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
.../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 13 ++++----
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 +++++++
drivers/net/ethernet/intel/ixgbevf/vf.c | 7 +++++
10 files changed, 67 insertions(+), 33 deletions(-)
--
2.47.1
^ permalink raw reply
* [PATCH net 1/9] idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling
From: Tony Nguyen @ 2026-04-06 21:30 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Emil Tantilov, anthony.l.nguyen, sgzhang, stable,
Sebastian Andrzej Siewior, Aleksandr Loktionov, Samuel Salin
In-Reply-To: <20260406213038.444732-1-anthony.l.nguyen@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Switch from using the completion's raw spinlock to a local lock in the
idpf_vc_xn struct. The conversion is safe because complete/_all() are
called outside the lock and there is no reason to share the completion
lock in the current logic. This avoids invalid wait context reported by
the kernel due to the async handler taking BH spinlock:
[ 805.726977] =============================
[ 805.726991] [ BUG: Invalid wait context ]
[ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE
[ 805.727026] -----------------------------
[ 805.727038] kworker/u261:0/572 is trying to lock:
[ 805.727051] ff190da6a8dbb6a0 (&vport_config->mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
[ 805.727099] other info that might help us debug this:
[ 805.727111] context-{5:5}
[ 805.727119] 3 locks held by kworker/u261:0/572:
[ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730
[ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&(&adapter->mbx_task)->work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730
[ 805.727191] #2: ff190da765190020 (&x->wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf]
[ 805.727218] stack backtrace:
...
[ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf]
[ 805.727247] Call Trace:
[ 805.727249] <TASK>
[ 805.727251] dump_stack_lvl+0x77/0xb0
[ 805.727259] __lock_acquire+0xb3b/0x2290
[ 805.727268] ? __irq_work_queue_local+0x59/0x130
[ 805.727275] lock_acquire+0xc6/0x2f0
[ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
[ 805.727284] ? _printk+0x5b/0x80
[ 805.727290] _raw_spin_lock_bh+0x38/0x50
[ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
[ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf]
[ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf]
[ 805.727317] process_one_work+0x226/0x730
[ 805.727322] worker_thread+0x19e/0x340
[ 805.727325] ? __pfx_worker_thread+0x10/0x10
[ 805.727328] kthread+0xf4/0x130
[ 805.727333] ? __pfx_kthread+0x10/0x10
[ 805.727336] ret_from_fork+0x32c/0x410
[ 805.727345] ? __pfx_kthread+0x10/0x10
[ 805.727347] ret_from_fork_asm+0x1a/0x30
[ 805.727354] </TASK>
Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
Cc: stable@vger.kernel.org
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reported-by: Ray Zhang <sgzhang@google.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 14 +++++---------
drivers/net/ethernet/intel/idpf/idpf_virtchnl.h | 5 +++--
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index 113ecfc16dd7..582e0c8e9dc0 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -287,26 +287,21 @@ int idpf_send_mb_msg(struct idpf_adapter *adapter, struct idpf_ctlq_info *asq,
return err;
}
-/* API for virtchnl "transaction" support ("xn" for short).
- *
- * We are reusing the completion lock to serialize the accesses to the
- * transaction state for simplicity, but it could be its own separate synchro
- * as well. For now, this API is only used from within a workqueue context;
- * raw_spin_lock() is enough.
- */
+/* API for virtchnl "transaction" support ("xn" for short). */
+
/**
* idpf_vc_xn_lock - Request exclusive access to vc transaction
* @xn: struct idpf_vc_xn* to access
*/
#define idpf_vc_xn_lock(xn) \
- raw_spin_lock(&(xn)->completed.wait.lock)
+ spin_lock(&(xn)->lock)
/**
* idpf_vc_xn_unlock - Release exclusive access to vc transaction
* @xn: struct idpf_vc_xn* to access
*/
#define idpf_vc_xn_unlock(xn) \
- raw_spin_unlock(&(xn)->completed.wait.lock)
+ spin_unlock(&(xn)->lock)
/**
* idpf_vc_xn_release_bufs - Release reference to reply buffer(s) and
@@ -338,6 +333,7 @@ static void idpf_vc_xn_init(struct idpf_vc_xn_manager *vcxn_mngr)
xn->state = IDPF_VC_XN_IDLE;
xn->idx = i;
idpf_vc_xn_release_bufs(xn);
+ spin_lock_init(&xn->lock);
init_completion(&xn->completed);
}
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
index fe065911ad5a..6876e3ed9d1b 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
@@ -42,8 +42,8 @@ typedef int (*async_vc_cb) (struct idpf_adapter *, struct idpf_vc_xn *,
* struct idpf_vc_xn - Data structure representing virtchnl transactions
* @completed: virtchnl event loop uses that to signal when a reply is
* available, uses kernel completion API
- * @state: virtchnl event loop stores the data below, protected by the
- * completion's lock.
+ * @lock: protects the transaction state fields below
+ * @state: virtchnl event loop stores the data below, protected by @lock
* @reply_sz: Original size of reply, may be > reply_buf.iov_len; it will be
* truncated on its way to the receiver thread according to
* reply_buf.iov_len.
@@ -58,6 +58,7 @@ typedef int (*async_vc_cb) (struct idpf_adapter *, struct idpf_vc_xn *,
*/
struct idpf_vc_xn {
struct completion completed;
+ spinlock_t lock;
enum idpf_vc_xn_state state;
size_t reply_sz;
struct kvec reply;
--
2.47.1
^ permalink raw reply related
* [PATCH net 2/9] idpf: improve locking around idpf_vc_xn_push_free()
From: Tony Nguyen @ 2026-04-06 21:30 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Emil Tantilov, anthony.l.nguyen, bigeasy, clrkwllms, rostedt,
linux-rt-devel, stable, Ray Zhang, Aleksandr Loktionov,
Samuel Salin
In-Reply-To: <20260406213038.444732-1-anthony.l.nguyen@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Protect the set_bit() operation for the free_xn bitmask in
idpf_vc_xn_push_free(), to make the locking consistent with rest of the
code and avoid potential races in that logic.
Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager")
Cc: stable@vger.kernel.org
Reported-by: Ray Zhang <sgzhang@google.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index 582e0c8e9dc0..fbd5a15b015c 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -402,7 +402,9 @@ static void idpf_vc_xn_push_free(struct idpf_vc_xn_manager *vcxn_mngr,
struct idpf_vc_xn *xn)
{
idpf_vc_xn_release_bufs(xn);
+ spin_lock_bh(&vcxn_mngr->xn_bm_lock);
set_bit(xn->idx, vcxn_mngr->free_xn_bm);
+ spin_unlock_bh(&vcxn_mngr->xn_bm_lock);
}
/**
--
2.47.1
^ 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