* Re: Re: [PATCH net] seg6: validate SRH length before reading fixed fields
From: Nuoqi Gui @ 2026-06-23 9:52 UTC (permalink / raw)
To: Andrea Mayer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev, bpf, linux-kernel, stefano.salsano
In-Reply-To: <20260622213317.52c8b5a38b88d4ccc3849e22@uniroma2.it>
> -----Original Messages-----
> From: "Andrea Mayer" <andrea.mayer@uniroma2.it>
> Send time:Tuesday, 23/06/2026 03:33:17
> To: "Nuoqi Gui" <gnq25@mails.tsinghua.edu.cn>
> Cc: "David S. Miller" <davem@davemloft.net>, "Eric Dumazet" <edumazet@google.com>, "Jakub Kicinski" <kuba@kernel.org>, "Paolo Abeni" <pabeni@redhat.com>, "Simon Horman" <horms@kernel.org>, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, stefano.salsano@uniroma2.it, "Andrea Mayer" <andrea.mayer@uniroma2.it>
> Subject: Re: [PATCH net] seg6: validate SRH length before reading fixed fields
>
> On Sat, 20 Jun 2026 23:55:51 +0800
> Nuoqi Gui <gnq25@mails.tsinghua.edu.cn> wrote:
>
> Hi Nuoqi,
> Thanks for the patch.
>
> > seg6_validate_srh() reads fixed SRH fields such as srh->type and
> > srh->hdrlen before checking that the supplied length covers the fixed
> > struct ipv6_sr_hdr fields. Callers that pass a length smaller than
> > sizeof(struct ipv6_sr_hdr) therefore expose those reads to memory
> > outside the validated range.
> >
> > The BPF SEG6 encap path (bpf_lwt_push_encap() -> bpf_push_seg6_encap())
> > is one such caller: it forwards a BPF program-supplied pointer and
> > length straight to seg6_validate_srh() with no minimum-size guard, so a
> > 2-byte SEG6 encap header lets the validator read srh->type at offset 2
> > beyond the caller-supplied buffer.
>
> Besides the BPF use case, is there a caller that can reach it with
> len < sizeof(*srh)? The ones I found all pass at least the fixed header.
>
No, I don't see another current caller that can reach seg6_validate_srh()
with len < sizeof(*srh). I'll narrow the commit message accordingly.
> >
> > Reject lengths shorter than the fixed SRH at the top of
> > seg6_validate_srh(), before any field is read. This fixes the BPF helper
> > path and hardens the common validator for any other caller that reaches it
> > with a too-short SRH.
> >
> > Fixes: fe94cc290f53 ("bpf: Add IPv6 Segment Routing helpers")
> > Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
> > ---
> > net/ipv6/seg6.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> > index 1c3ad25700c4c..d2cb32a1058af 100644
> > --- a/net/ipv6/seg6.c
> > +++ b/net/ipv6/seg6.c
> > @@ -29,6 +29,9 @@ bool seg6_validate_srh(struct ipv6_sr_hdr *srh, int len, bool reduced)
> > int max_last_entry;
> > int trailing;
> >
> > + if (len < (int)sizeof(*srh))
> > + return false;
> > +
>
> The (int) cast only changes the result when len < 0, which is not a meaningful
> byte length. Plain "len < sizeof(*srh)" would be enough.
>
I'll use plain len < sizeof(*srh).
> > if (srh->type != IPV6_SRCRT_TYPE_4)
> > return false;
> >
> >
> > ---
> > base-commit: 96e7f9122aae0ed000ee321f324b812a447906d9
> > change-id: 20260619-f01-17-seg6-srh-len-a85f35427e0b
> >
> > Best regards,
> > --
> > Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
> >
>
> Regards,
> Andrea
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] igc: Fix RX HW timestamp reporting when NET_RX_BUSY_POLL is disabled
From: Kwapulinski, Piotr @ 2026-06-23 9:46 UTC (permalink / raw)
To: Ding Meng, Nguyen, Anthony L, Kitszel, Przemyslaw,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, Kiszka, Jan, Bezdeka, Florian
Cc: intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, wq.wang@siemens.com
In-Reply-To: <20260622041718.6106-1-meng.ding@siemens.com>
>-----Original Message-----
>From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Ding Meng via Intel-wired-lan
>Sent: Monday, June 22, 2026 6:13 AM
>To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Kiszka, Jan <jan.kiszka@siemens.com>; Bezdeka, Florian <florian.bezdeka@siemens.com>
>Cc: intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; meng.ding@siemens.com; wq.wang@siemens.com
>Subject: [Intel-wired-lan] [PATCH net] igc: Fix RX HW timestamp reporting when NET_RX_BUSY_POLL is disabled
>
>When CONFIG_NET_RX_BUSY_POLL is deactivated, fetching RX HW timestamps from the NIC no longer works as expected.
>
>This occurs because disabling CONFIG_NET_RX_BUSY_POLL disables the SKB NAPI mapping in __skb_mark_napi_id(). Consequently, get_timestamp() fails to perform its driver lookup, and the igc driver's struct net_device_ops::ndo_get_tstamp is never invoked.
>
>Instead, get_timestamp() falls back to use shhwtstamps(skb)->hwtstamp, a field that the driver has not populated.
>
>Fix this by populating the hwtstamp field with the correct timestamp in the default timer when CONFIG_NET_RX_BUSY_POLL is disabled.
>
>Fixes: 069b142f5819 ("igc: Add support for PTP .getcyclesx64()")
>Co-developed-by: Florian Bezdeka <florian.bezdeka@siemens.com>
>Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
>Signed-off-by: Ding Meng <meng.ding@siemens.com>
>---
> drivers/net/ethernet/intel/igc/igc_main.c | 38 ++++++++++++++++-------
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
>index 8ac16808023..1da8d7aa76d 100644
>--- a/drivers/net/ethernet/intel/igc/igc_main.c
>+++ b/drivers/net/ethernet/intel/igc/igc_main.c
>@@ -1992,7 +1992,26 @@ static struct sk_buff *igc_build_skb(struct igc_ring *rx_ring,
> return skb;
> }
>
>-static struct sk_buff *igc_construct_skb(struct igc_ring *rx_ring,
>+static void igc_construct_skb_timestamps(struct igc_adapter *adapter,
>+ struct sk_buff *skb,
>+ struct igc_xdp_buff *ctx)
>+{
>+ if (!ctx->rx_ts)
>+ return;
>+#ifdef CONFIG_NET_RX_BUSY_POLL
>+ skb_shinfo(skb)->tx_flags |= SKBTX_HW_TSTAMP_NETDEV;
>+ skb_hwtstamps(skb)->netdev_data = ctx->rx_ts; #else
>+ struct igc_inline_rx_tstamps *tstamps;
Please move at the top of the function and add:
Reviewed-by: Piotr Kwapulinski <piotr.kwapulinski@intel.com
>+
>+ tstamps = ctx->rx_ts;
>+ skb_hwtstamps(skb)->hwtstamp = igc_ptp_rx_pktstamp(adapter,
>+ tstamps->timer0);
>+#endif
>+}
>+
>+static struct sk_buff *igc_construct_skb(struct igc_adapter *adapter,
>+ struct igc_ring *rx_ring,
> struct igc_rx_buffer *rx_buffer,
> struct igc_xdp_buff *ctx)
> {
>@@ -2013,10 +2032,7 @@ static struct sk_buff *igc_construct_skb(struct igc_ring *rx_ring,
> if (unlikely(!skb))
> return NULL;
>
>- if (ctx->rx_ts) {
>- skb_shinfo(skb)->tx_flags |= SKBTX_HW_TSTAMP_NETDEV;
>- skb_hwtstamps(skb)->netdev_data = ctx->rx_ts;
>- }
>+ igc_construct_skb_timestamps(adapter, skb, ctx);
>
> /* Determine available headroom for copy */
> headlen = size;
>@@ -2686,7 +2702,7 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
> else if (ring_uses_build_skb(rx_ring))
> skb = igc_build_skb(rx_ring, rx_buffer, &ctx.xdp);
> else
>- skb = igc_construct_skb(rx_ring, rx_buffer, &ctx);
>+ skb = igc_construct_skb(adapter, rx_ring, rx_buffer, &ctx);
>
> /* exit if we failed to retrieve a buffer */
> if (!xdp_res && !skb) {
>@@ -2738,7 +2754,8 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
> return total_packets;
> }
>
>-static struct sk_buff *igc_construct_skb_zc(struct igc_ring *ring,
>+static struct sk_buff *igc_construct_skb_zc(struct igc_adapter *adapter,
>+ struct igc_ring *ring,
> struct igc_xdp_buff *ctx)
> {
> struct xdp_buff *xdp = &ctx->xdp;
>@@ -2760,10 +2777,7 @@ static struct sk_buff *igc_construct_skb_zc(struct igc_ring *ring,
> __skb_pull(skb, metasize);
> }
>
>- if (ctx->rx_ts) {
>- skb_shinfo(skb)->tx_flags |= SKBTX_HW_TSTAMP_NETDEV;
>- skb_hwtstamps(skb)->netdev_data = ctx->rx_ts;
>- }
>+ igc_construct_skb_timestamps(adapter, skb, ctx);
>
> return skb;
> }
>@@ -2775,7 +2789,7 @@ static void igc_dispatch_skb_zc(struct igc_q_vector *q_vector,
> struct igc_ring *ring = q_vector->rx.ring;
> struct sk_buff *skb;
>
>- skb = igc_construct_skb_zc(ring, ctx);
>+ skb = igc_construct_skb_zc(q_vector->adapter, ring, ctx);
> if (!skb) {
> ring->rx_stats.alloc_failed++;
> set_bit(IGC_RING_FLAG_RX_ALLOC_FAILED, &ring->flags);
>
>base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
>--
>2.47.3
>
>
^ permalink raw reply
* Re: Ethtool : PRBS feature
From: Andrew Lunn @ 2026-06-23 9:43 UTC (permalink / raw)
To: Das, Shubham
Cc: Maxime Chevallier, Alexander H Duyck, lee@trager.us,
netdev@vger.kernel.org, mkubecek@suse.cz, D H, Siddaraju,
Chintalapalle, Balaji, Lindberg, Magnus,
niklas.damberg@ericsson.com
In-Reply-To: <SN7PR11MB8109149608172808784CDCBEFFEF2@SN7PR11MB8109.namprd11.prod.outlook.com>
On Mon, Jun 22, 2026 at 03:38:30PM +0000, Das, Shubham wrote:
> Hi Maxime,
>
> > Can you elaborate on what you have in mind for now ? what would the "ethtool --
> > phy-test" command look like in terms of its behaviour and parameters ?
>
> We are trying to converge on a userspace uAPI for PRBS/BERT functionality that can work across
> different hardware models (PHY-managed, MAC/NIC-offloaded, or firmware-based implementations),
> without exposing those differences to userspace.
>
> Based on the functionality we currently have, we proposed below commands in first email :
>
> PRBS Transmitter/Checker Pattern Configuration:
> ethtool --phy-test eth1 tx-prbs prbs7
> ethtool --phy-test eth2 rx-prbs prbs7
>
> BERT Test:
> ethtool --phy-test eth2 bert start
> ethtool --phy-test eth2 bert stop
>
> BERT Test Counter Read/ PRBS Lock Status:
> ethtool --phy-test eth2 stats
>
> BERT Clear stats - Symbol and Error counter:
> ethtool --phy-test eth2 clear-stats
>
> TX Error Injection:
> ethtool --phy-test eth1 inject-error 1
> ethtool --phy-test eth1 inject-error 1e-3
>
> Disable PRBS Pattern : TX/RX
> ethtool --phy-test eth1 tx-prbs off
> ethtool --phy-test eth2 rx-prbs off
>
> Approach would be to add a generic ethtool netlink API for PHY/SerDes and allow drivers to implement the operations directly.
> Conceptually:
> ethtool ⇒ ethtool netlink ⇒ driver-specific implementation
>
> We would appreciate your input on whether a command-based model is suitable for a uAPI, and how we should design
> it to accommodate different implementation models, such as PHY-based, phylib-based, and MAC/firmware-offloaded PRBS.
This is technical, not the uAPI. You need to define the netlink
messages and all the attributes that are passed between user space and
kernel. Please take a look at Documentation/netlink/specs and propose
an extension to ethtool.yaml.
Taking a quick look at this:
You are missing a way to enumerate what test patterns the hardware
supports. There is more than prbs7. You want to be able to report the
contents of C45 1.1500, and other similar registers.
To avoid race conditions, maybe some of these commands need combining.
ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
The configuration is then atomic, with respect to the uAPI, so we
don't get two users configuring it at the same time, ending up with a
messed up configuration.
Traditionally, Unix does not offer a way to clear statistic counters
back to zero. So i'm not sure about clear-stats. We also need to think
about hardware which does not support that. And there is locking
issues, can the stats be cleared while a test is active?
You need to think about the units for inject errors. There is no
floating point support. Also, is this corrupt packets? Or single bit
flips in the stream? It needs to be well defined what it actually
means. The driver can then convert it to whatever the hardware
supports. How does 802.3 specify this?
Also, 802.3 defines PRBS7 as a benign pattern. With a quick look, i
did not find a definition of benign, but injecting errors does not
seem benign to me.
I'm assuming when 'start' is used, the networking core will change the
interface status to IF_OPER_TESTING. It is not always obvious why an
interface is in testing mode, rather than IF_OPER_UP. Cable testing
could also be running, etc. So maybe there needs to be a way to report
why it is in IF_OPER_TESTING?
I also wounder if a timeout should be used with start, so that it will
return to IF_OPER_UP after a time period?
Andrew
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Askar Safin @ 2026-06-23 9:42 UTC (permalink / raw)
To: avagin
Cc: akpm, alexander, axboe, bernd, brauner, criu, david, dhowells,
fuse-devel, hch, jack, joannelkoong, linux-api, linux-fsdevel,
linux-kernel, linux-mm, miklos, netdev, patches, pfalcato,
rostedt, safinaskar, torvalds, val, viro, willy
In-Reply-To: <CANaxB-xVCP5HSUNwphFrKPdW0Qh1pA33A6npac60WArkZMFt7w@mail.gmail.com>
Andrei Vagin <avagin@gmail.com>:
> Actually, this change introduces a performance and functional
> regression for CRIU.
>
> Here is a brief overview of how CRIU currently dumps memory pages:
>
> CRIU injects a parasite code blob into the target process's address
> space. The parasite invokes vmsplice() with the SPLICE_F_GIFT flag to
> pin physical pages directly inside a pipe without copying them. The main
> CRIU process then takes over from outside the target context, calling
> splice() on the other end of the pipe to stream the data directly into
> checkpoint image files or a remote network socket.
>
> I ran a simple test that creates an anonymous mapping and touches every
> page within it:
> Without this patch, CRIU takes 9 seconds to dump the test process.
> With this patch, It takes 18 seconds...
>
> Plus, it obviously introduces some memory overhead.
>
> If these changes are merged, we will need to completely rework the
> memory dumping mechanism in CRIU. Using vmsplice() in this proposed form
> no longer makes any sense for our architecture...
I just have read some docs for CRIU. I found this statement:
> #### Why `splice` is Better:
> * **Consistency via COW**: The `SPLICE_F_GIFT` flag ensures that if the process modifies a "gifted" page after resuming, the kernel performs a **Copy-on-Write (COW)**. The pipe buffer > continues to hold the *original* version of the page as it existed at the moment of the `vmsplice()` call, ensuring a perfectly consistent snapshot of that page.
This is wrong (with released kernels). I confirmed this by testing this on my current kernel (6.12.90).
See the code in the end of this message.
If you actually rely on mentioned consistency, then, it seems, CRIU is broken.
So, in fact, my patch actually brings consistency to CRIU. :)
--
Askar Safin
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/uio.h>
#include <sys/wait.h>
#include <errno.h>
int
main (void)
{
int p[2];
if (pipe (p) != 0)
abort ();
char buf[1] = {'a'};
struct iovec iov[] = {
{
.iov_base = buf,
.iov_len = 1,
}
};
// I pass "SPLICE_F_NONBLOCK | SPLICE_F_GIFT" here, because this is what criu passes
if (vmsplice (p[1], iov, 1, SPLICE_F_NONBLOCK | SPLICE_F_GIFT) != 1)
abort ();
if (close (p[1]) != 0)
abort ();
buf[0] = 'b';
char buf2[1];
if (read (p[0], buf2, 1) != 1)
abort ();
printf ("[%c]\n", buf2[0]); // Prints "b" as opposed to "a" on Linux 6.12.90
return 0;
}
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Jie Luo @ 2026-06-23 9:42 UTC (permalink / raw)
To: Andrew Lunn, Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lei Wei, Suruchi Agarwal, Pavithra R, linux-kernel, linux-arm-msm,
linux-clk, devicetree, netdev
In-Reply-To: <0247dfba-1c14-4fea-aab3-5489a36f35f6@lunn.ch>
On 6/23/2026 4:10 PM, Andrew Lunn wrote:
>> Driver is not supported - in terms of how netdev understands supported
>> commitment - if maintainer does not care to receive the patches for its
>> code, so demote it to "maintained" to reflect true status.
>
> Maybe "Orphan" would be better, if the listed Maintainer is not doing
> any Maintainer work?
>
> Andrew
Hello Andrew, Krzysztof,
I will continue to maintain the listed drivers, so their status can
remain Supported.
^ permalink raw reply
* [bug report] net: stmmac: fix dma physical address of descriptor when display ring
From: Dan Carpenter @ 2026-06-23 9:38 UTC (permalink / raw)
To: Joakim Zhang; +Cc: netdev, linux-stm32
Hello Joakim Zhang,
Commit bfaf91ca848e ("net: stmmac: fix dma physical address of
descriptor when display ring") from Feb 25, 2021 (linux-next), leads
to the following Smatch static checker warning:
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c:431 dwmac4_display_ring()
warn: duplicate check 'desc_size == 32' (previous on line 418)
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
399 static void dwmac4_display_ring(void *head, unsigned int size, bool rx,
400 dma_addr_t dma_rx_phy, unsigned int desc_size)
401 {
402 dma_addr_t dma_addr;
403 int i;
404
405 pr_info("%s descriptor ring:\n", rx ? "RX" : "TX");
406
407 if (desc_size == sizeof(struct dma_desc)) {
408 struct dma_desc *p = (struct dma_desc *)head;
409
410 for (i = 0; i < size; i++) {
411 dma_addr = dma_rx_phy + i * sizeof(*p);
412 pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x\n",
413 i, &dma_addr,
414 le32_to_cpu(p->des0), le32_to_cpu(p->des1),
415 le32_to_cpu(p->des2), le32_to_cpu(p->des3));
416 p++;
417 }
418 } else if (desc_size == sizeof(struct dma_extended_desc)) {
419 struct dma_extended_desc *extp = (struct dma_extended_desc *)head;
420
421 for (i = 0; i < size; i++) {
422 dma_addr = dma_rx_phy + i * sizeof(*extp);
423 pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n",
424 i, &dma_addr,
425 le32_to_cpu(extp->basic.des0), le32_to_cpu(extp->basic.des1),
426 le32_to_cpu(extp->basic.des2), le32_to_cpu(extp->basic.des3),
427 le32_to_cpu(extp->des4), le32_to_cpu(extp->des5),
428 le32_to_cpu(extp->des6), le32_to_cpu(extp->des7));
429 extp++;
430 }
--> 431 } else if (desc_size == sizeof(struct dma_edesc)) {
The dma_extended_desc and dma_edesc structs are the same size but
just the basic info is at the start vs at the end. This code is
quite old, but I think maybe we changed the Kconfig so now it's showing
up as a static checker warning?
/* Extended descriptor structure (e.g. >= databook 3.50a) */
struct dma_extended_desc {
struct dma_desc basic; /* Basic descriptors */
__le32 des4; /* Extended Status */
__le32 des5; /* Reserved */
__le32 des6; /* Tx/Rx Timestamp Low */
__le32 des7; /* Tx/Rx Timestamp High */
};
/* Enhanced descriptor for TBS */
struct dma_edesc {
__le32 des4;
__le32 des5;
__le32 des6;
__le32 des7;
struct dma_desc basic;
};
432 struct dma_edesc *ep = dma_desc_to_edesc(head);
433
434 for (i = 0; i < size; i++) {
435 dma_addr = dma_rx_phy + i * sizeof(*ep);
436 pr_info("%03d [%pad]: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n",
437 i, &dma_addr,
438 le32_to_cpu(ep->des4), le32_to_cpu(ep->des5),
439 le32_to_cpu(ep->des6), le32_to_cpu(ep->des7),
440 le32_to_cpu(ep->basic.des0), le32_to_cpu(ep->basic.des1),
441 le32_to_cpu(ep->basic.des2), le32_to_cpu(ep->basic.des3));
442 ep++;
443 }
444 } else {
445 pr_err("unsupported descriptor!");
446 }
447 }
This email is a free service from the Smatch-CI project [smatch.sf.net].
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support
From: Konrad Dybcio @ 2026-06-23 9:37 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alex Elder
Cc: linux-arm-msm, devicetree, linux-kernel, netdev
In-Reply-To: <20260622-sm8450-ipa-v1-1-532f0299f96e@proton.me>
On 6/23/26 3:44 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Add support for IPA in DT while expanding the IMEM region just enough to
> accommodate the modem tables used by IPA.
> As reference, SM8450 uses IPA v5.1.
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
[...]
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 55 ++++++++++++++++++++++++++++++++----
> 1 file changed, 50 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 56cb6e959e4e..c904720008fa 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2639,6 +2639,47 @@ adreno_smmu: iommu@3da0000 {
> dma-coherent;
> };
>
> + ipa: ipa@3f40000 {
> + compatible = "qcom,sm8450-ipa";
> +
> + iommus = <&apps_smmu 0x5c0 0x0>,
> + <&apps_smmu 0x5c2 0x0>;
> + reg = <0 0x3f40000 0 0x10000>,
> + <0 0x3f50000 0 0x5000>,
size = 0xb0000 for the RAM and uC regions that the driver seems
to poke at (at a glance anyway..)
[...]
> usb_1_hsphy: phy@88e3000 {
> compatible = "qcom,sm8450-usb-hs-phy",
> "qcom,usb-snps-hs-7nm-phy";
> @@ -4970,17 +5011,21 @@ cti@13900000 {
> clock-names = "apb_pclk";
> };
>
> - sram@146aa000 {
> + sram@146a8000 {
> compatible = "qcom,sm8450-imem", "syscon", "simple-mfd";
> - reg = <0 0x146aa000 0 0x1000>;
> - ranges = <0 0 0x146aa000 0x1000>;
> + reg = <0 0x146a8000 0 0x3000>;
base=0x1468_0000
size=0x40_000
Konrad
^ permalink raw reply
* [PATCH] xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags()
From: Chen YanJun @ 2026-06-23 9:22 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: netdev, moomichen
From: Chen YanJun <moomichen@tencent.com>
When iptfs_skb_add_frags() copies frag references from the source
frag walk into a new SKB, it increments the page reference count via
__skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the
destination SKB's skb_shinfo->flags.
If the source SKB carries shared frags (e.g. from a page-pool backed
receive path), the new inner SKB will appear to ESP as having privately
owned frags. A subsequent esp_input() call for a nested transport-mode
SA then takes the no-COW fast path and decrypts in place, writing over
pages that are still referenced by the outer IPTFS SKB. This causes
kernel-visible memory corruption and can trigger a panic.
All other frag-transfer helpers in the kernel (skb_try_coalesce,
skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly
propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this
convention.
Fixes: 5f2b6a909574 ("xfrm: iptfs: add skb-fragment sharing code")
Signed-off-by: Chen YanJun <moomichen@tencent.com>
---
net/xfrm/xfrm_iptfs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
index ad810d1f97c0..0e0dcf47a470 100644
--- a/net/xfrm/xfrm_iptfs.c
+++ b/net/xfrm/xfrm_iptfs.c
@@ -496,6 +496,10 @@ static int iptfs_skb_add_frags(struct sk_buff *skb,
walk->past += frag->len; /* careful, use src bv_len */
walk->fragi++;
}
+
+ if (skb_shinfo(skb)->nr_frags)
+ skb_shinfo(skb)->flags |= SKBFL_SHARED_FRAG;
+
return len;
}
--
2.47.0
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH iwl-net] ice: clear the default forwarding VSI rule when releasing a VSI
From: Marcin Szycik @ 2026-06-23 9:22 UTC (permalink / raw)
To: Petr Oros, netdev
Cc: Przemek Kitszel, Eric Dumazet, linux-kernel, Andrew Lunn,
Tony Nguyen, Michal Swiatkowski, Jacob Keller, Jakub Kicinski,
Paolo Abeni, David S. Miller, intel-wired-lan
In-Reply-To: <e85d04b5-9108-4a5a-85e7-81178b6ef679@redhat.com>
On 22.06.2026 17:30, Petr Oros wrote:
>
> On 6/22/26 15:52, Marcin Szycik wrote:
>>
>> On 22/06/2026 10:10, Petr Oros wrote:
>>> When a VSI is configured as the switch's default forwarding VSI
>>> (ICE_SW_LKUP_DFLT) and is then torn down, the rule is left behind in
>>> the switch. ice_vsi_release() no longer removes it, and the SR-IOV VF
>>> free path (ice_free_vfs() -> ice_free_vf_res() -> ice_vf_vsi_release()
>>> -> ice_vsi_release()) does not disable promiscuous mode either, which
>>> only happens on VF reset in ice_vf_clear_all_promisc_modes().
>>>
>>> A trusted VF that enters unicast promiscuous mode becomes the default
>>> forwarding VSI (this is the default mode, when the PF does not have VF
>>> true-promiscuous mode enabled). If the VFs are then destroyed without
>>> the VF first leaving promiscuous mode, the ICE_SW_LKUP_DFLT rule for
>>> the now-freed VSI is leaked. When VFs are recreated, a VSI reuses the
>>> freed hw_vsi_id. If it is assigned a different VSI handle than the
>>> leaked rule holds, ice_set_dflt_vsi() does not recognize it as
>>> already-default, and ice_add_update_vsi_list() folds the dangling
>>> (freed) handle into a VSI list, which the firmware rejects. The VSI
>>> handle assigned on re-creation varies, so the failure is intermittent
>>> rather than every cycle.
>>>
>>> Reproduce by repeatedly running the cycle below on the two ports of the
>>> same card, where $VF0 and $VF1 are the netdevs of vf 15 once they
>>> appear. The VF must be brought up so iavf actually pushes the unicast
>>> promiscuous request, and the rule must settle before the VFs are torn
>>> down again:
>>>
>>> echo 16 > /sys/class/net/$PF0/device/sriov_numvfs
>>> echo 16 > /sys/class/net/$PF1/device/sriov_numvfs
>>> ip link set $PF0 vf 15 trust on
>>> ip link set $PF1 vf 15 trust on
>>> ip link set $VF0 up
>>> ip link set $VF1 up
>>> ip link set $VF0 promisc on
>>> ip link set $VF1 promisc on
>>> sleep 1
>>> echo 0 > /sys/class/net/$PF0/device/sriov_numvfs
>>> echo 0 > /sys/class/net/$PF1/device/sriov_numvfs
>>>
>>> Within a few cycles the ice PF and iavf VF log:
>>>
>>> Failed to set VSI 25 as the default forwarding VSI, error -22
>>> Turning on/off promiscuous mode for VF 63 failed, error: -22
>>> PF returned error -53 (IAVF_ERR_ADMIN_QUEUE_ERROR) to our request 14
>>>
>>> This cleanup used to live in ice_vsi_release() but was dropped by the
>>> referenced refactor. Restore it. Clear the default forwarding VSI rule
>>> in ice_vsi_release() when this VSI owns it, which covers every teardown
>>> path.
>>>
>>> Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions")
>>> Signed-off-by: Petr Oros <poros@redhat.com>
>>> ---
>>> drivers/net/ethernet/intel/ice/ice_lib.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
>>> index 2717cc31bff8fe..408464434506ef 100644
>>> --- a/drivers/net/ethernet/intel/ice/ice_lib.c
>>> +++ b/drivers/net/ethernet/intel/ice/ice_lib.c
>>> @@ -2872,6 +2872,9 @@ int ice_vsi_release(struct ice_vsi *vsi)
>>> return -ENODEV;
>>> pf = vsi->back;
>>> + if (ice_is_vsi_dflt_vsi(vsi))
>>> + ice_clear_dflt_vsi(vsi);
>> In the referenced commit, the chunk of code that contained these missing 2 lines
>> was moved to ice_vsi_decfg(). It also sounds like a good place for them and will
>> be called from ice_vsi_release(). Are you sure we should place them directly in
>> ice_vsi_release() instead?
> No, ice_vsi_decfg() is not a good place for them because it is not
> release only. It also runs on the rebuild and reconfig paths
> (ice_vsi_rebuild(), ice_vf_reconfig_vsi(), the ice_vsi_cfg() error
> path), where the VSI is reconfigured in place and stays alive, so it
> can still be the default VSI afterwards.
>
> Before the refactor the release-path clear lived only in
> ice_vsi_release() and the old ice_vsi_rebuild() never cleared it.
> Putting it in ice_vsi_decfg() would also clear the default VSI whenever
> the default VSI itself is reset or reconfigured, which the original
> code never did. ice_vsi_release() keeps it to the case where the owning
> VSI is actually torn down, and the ice_is_vsi_dflt_vsi() guard makes it
> a no-op everywhere else.
>
> So I would prefer to keep it in ice_vsi_release().
>
> Regards,
>
> Petr
Thanks for the writeup, sounds reasonable.
Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
>
>> Thanks,
>> Marcin
>>
>>> +
>>> if (test_bit(ICE_FLAG_RSS_ENA, pf->flags))
>>> ice_rss_clean(vsi);
>>>
>>
>
^ permalink raw reply
* Re: [PATCH net] net: dst: block BH in ipip6_tunnel_xmit
From: yuan.gao @ 2026-06-23 2:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Yue Haibing, Kuniyuki Iwashima, Thorsten Blum, Kyle Zeng,
Kees Cook, netdev, linux-kernel
In-Reply-To: <CANn89i+hKw-G3jewJoEPgGu-BOWUNuUn0RMdGh5L3B1ubD+OMw@mail.gmail.com>
On Mon, Jun 22, 2026 at 01:13:30AM -0700, Eric Dumazet wrote:
> On Sun, Jun 21, 2026 at 8:31 PM yuan.gao <yuan.gao@ucloud.cn> wrote:
> >
> > Similar to commit 1378817486d6 ("tipc: block BH before using dst_cache"),
> > the dst cache helper functions must be invoked with local BH disabled.
> >
> > This ensures proper synchronization and fixes a potential race condition
> > on SMP systems.
> >
> > Signed-off-by: yuan.gao <yuan.gao@ucloud.cn>
> > ---
>
> All ndo_start_xmit() methods already run with BH blocked, can you give
> us a stack trace when this would not be enforced?
>
> You forgot a Fixes: tag.
Many thanks for pointing that out — I completely missed that detail.
Cheers,
Yuan Gao
^ permalink raw reply
* Re: [PATCH net-next] net: sparx5: change ndo_set_rx_mode_async return type to int
From: Robert Marko @ 2026-06-23 9:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, Steen.Hegelund,
daniel.machon, UNGLinuxDriver, sdf.kernel, netdev,
linux-arm-kernel, linux-kernel, luka.perkov
In-Reply-To: <20260613112940.05bba5ff@kernel.org>
On Sat, Jun 13, 2026 at 8:29 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 11 Jun 2026 12:11:13 +0200 Robert Marko wrote:
> > Commit ("net: add retry mechanism to ndo_set_rx_mode_async") changed the
> > ndo_set_rx_mode_async return type to int, however it did not update the
> > SparX-5 driver.
> >
> > So, simply update the sparx5_set_rx_mode return type to int, propagate
> > return from __hw_addr_sync_dev or simply return 0.
> >
> > Fixes: d90b85c23b3d ("net: add retry mechanism to ndo_set_rx_mode_async")
>
> This commit does not exist, as I said in:
> https://lore.kernel.org/all/20260507091012.7eeb17f5@kernel.org/
> the first two patches of that series were _not_ applied.
Ahh, sorry for this then, I had those patches applied locally.
Regards,
Robert
> --
> pw-bot: reject
--
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr
^ permalink raw reply
* Re: [PATCH v4 net] net: mana: Optimize irq affinity for low vcpu configs
From: Shradha Gupta @ 2026-06-23 9:11 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Dexuan Cui, Wei Liu, Haiyang Zhang, K. Y. Srinivasan, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Konstantin Taranov,
Simon Horman, Erni Sri Satya Vennela, Dipayaan Roy, Shiraz Saleem,
Michael Kelley, Long Li, Yury Norov, linux-hyperv, linux-kernel,
netdev, Paul Rosswurm, Shradha Gupta, Saurabh Singh Sengar,
stable
In-Reply-To: <20260622182248.5bfc49ce@kernel.org>
On Mon, Jun 22, 2026 at 06:22:48PM -0700, Jakub Kicinski wrote:
> On Fri, 19 Jun 2026 00:33:35 -0700 Shradha Gupta wrote:
> > Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically")
> > Cc: stable@vger.kernel.org
>
> If you want this to be a fix -- could you please rewrite the commit
> message? What matters most is the comparison before the bad commit,
> the bad commit, and then with this fix applied. Perhaps the three
> cases you list is that but it's not immediately obvious..
> --
> pw-bot: cr
sure, Jakub. Let me send out a newer version with this change in commit
message
regards,
Shradha
^ permalink raw reply
* Re: [PATCH] [net] eth: mlx5: fix macsec dependency
From: Sabrina Dubroca @ 2026-06-23 9:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Arnd Bergmann, Daniel Zahka, Rahul Rameshbabu,
Raed Salem, netdev, linux-rdma, linux-kernel
In-Reply-To: <20260622124229.2444502-1-arnd@kernel.org>
2026-06-22, 14:41:07 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Configurations with mlx5 built-in but macsec=m fail to link:
>
> x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_add_gid_macsec_operations':
> macsec.c:(.text+0x77d): undefined reference to `macsec_netdev_is_offloaded'
> x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_del_gid_macsec_operations':
> macsec.c:(.text+0xe81): undefined reference to `macsec_netdev_is_offloaded'
>
> Fix the dependency so this configuration cannot happen.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
> drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
...
> @@ -144,7 +144,7 @@ config MLX5_CORE_IPOIB
> config MLX5_MACSEC
> bool "Connect-X support for MACSec offload"
> depends on MLX5_CORE_EN
> - depends on MACSEC
> + depends on MACSEC=y || MACSEC=MLX5_CORE
I'd never seen this 'configA=configB' syntax, cool.
--
Sabrina
^ permalink raw reply
* [PATCH net-next] selftests/xsk: preserve UMEM view in bidi test
From: Maciej Fijalkowski @ 2026-06-23 9:10 UTC (permalink / raw)
To: netdev
Cc: bpf, magnus.karlsson, stfomichev, kuba, pabeni, horms,
tushar.vyavahare, kerneljasonxing, Maciej Fijalkowski
The UMEM state refactor made __send_pkts() use xsk->umem for Tx
address generation. At the same time, the shared-UMEM Tx setup copies the
Rx UMEM state into a Tx-local state object and resets base_addr and
next_buffer before configuring the Tx socket.
Passing that Tx-local object to xsk_configure() makes xsk->umem point to
the zero-based Tx allocator state. This breaks the BIDIRECTIONAL test once
the roles are switched: the same socket is then used for Rx validation, but
received descriptors from the other logical UMEM half are checked against
base_addr == 0. With the new UMEM bounds check, a valid address such as
base_addr + XDP_PACKET_HEADROOM is rejected as being outside the UMEM
window.
Keep xsk->umem as the shared/Rx UMEM view used for socket configuration
and Rx validation. Use the ifobject-local UMEM copy only for Tx descriptor
address generation, preserving the BIDIRECTIONAL test's intent of using
the proper logical UMEM half after the direction switch.
Fixes: b17631032769 ("selftests/xsk: Move UMEM state from ifobject to xsk_socket_info")
Signed-off-by: Maciej Fijalkowski maciej.fijalkowski@intel.com
---
tools/testing/selftests/bpf/prog_tests/test_xsk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
index d8a1c0d40e5a..50a8dbacb63d 100644
--- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c
+++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
@@ -1169,8 +1169,8 @@ static int receive_pkts(struct test_spec *test)
static int __send_pkts(struct ifobject *ifobject, struct xsk_socket_info *xsk, bool timeout)
{
u32 i, idx = 0, valid_pkts = 0, valid_frags = 0, buffer_len;
+ struct xsk_umem_info *umem = ifobject->xsk_arr[0].umem_real;
struct pkt_stream *pkt_stream = xsk->pkt_stream;
- struct xsk_umem_info *umem = xsk->umem;
bool use_poll = ifobject->use_poll;
struct pollfd fds = { };
int ret;
@@ -1524,7 +1524,7 @@ static int thread_common_ops_tx(struct test_spec *test, struct ifobject *ifobjec
umem_tx->base_addr = 0;
umem_tx->next_buffer = 0;
- ret = xsk_configure(test, ifobject, umem_tx, true);
+ ret = xsk_configure(test, ifobject, umem_rx, true);
if (ret)
return ret;
ifobject->xsk = &ifobject->xsk_arr[0];
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Jie Luo @ 2026-06-23 9:08 UTC (permalink / raw)
To: Andrew Lunn, Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lei Wei, Suruchi Agarwal, Pavithra R, linux-kernel, linux-arm-msm,
linux-clk, devicetree, netdev
In-Reply-To: <0247dfba-1c14-4fea-aab3-5489a36f35f6@lunn.ch>
On 6/23/2026 4:10 PM, Andrew Lunn wrote:
> Emails to the maintainer of Qualcomm PPE Ethernet driver (Luo Jie
> <quic_luoj@quicinc.com>) bounce permanently (full mailbox), because the
> "quicinc.com" addresses were deprecated for public work. All Qualcomm
> contributors are aware of that and were asked to fix their addresses.
>
> Driver is not supported - in terms of how netdev understands supported
> commitment - if maintainer does not care to receive the patches for its
> code, so demote it to "maintained" to reflect true status.
>
> Fix all occurences of Luo Jie email address to preferred and working
> domain.
Thanks a lot for fixing my email address and for the help!
Acked-by: Luo Jie <jie.luo@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next 0/3] selftests/xsk: stabilize timeout test behavior
From: Maciej Fijalkowski @ 2026-06-23 9:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jason Xing, Tushar Vyavahare, netdev, magnus.karlsson, stfomichev,
kernelxing, davem, pabeni, ast, daniel, tirthendu.sarkar, bpf
In-Reply-To: <20260622160706.0b4a27bf@kernel.org>
On Mon, Jun 22, 2026 at 04:07:06PM -0700, Jakub Kicinski wrote:
> On Wed, 17 Jun 2026 11:43:14 +0200 Maciej Fijalkowski wrote:
> > > On Tue, Jun 16, 2026 at 11:50 PM Tushar Vyavahare
> > > <tushar.vyavahare@intel.com> wrote:
> > > >
> > > > This series improves AF_XDP selftests by making timeout handling
> > > > explicit and fixing sources of non-determinism in xsk timeout tests.
> > > >
> > > > Patch 1 introduces test_spec::poll_tmout and removes implicit
> > > > dependence on RX UMEM setup state for timeout behavior.
> > > >
> > > > Patch 2 fixes thread harness sequencing by attaching XDP programs
> > > > before worker startup, removing signal-based termination, and using
> > > > barrier synchronization only for dual-thread runs.
> > > >
> > > > Patch 3 restores shared_umem after POLL_TXQ_FULL so test-local
> > > > configuration does not leak into subsequent cases on shared-netdev
> > > > runs.
> > > >
> > > > Together these changes make timeout handling easier to follow and
> > > > improve selftest stability, especially on real NIC runs.
> > >
> > > net-next is closed, but in the meantime I'll review the series ASAP.
> > >
> > > BTW, another thing about selftests I had in my mind is that are you
> > > planning to work on this [1]?
> >
> > This one is on me. I took your changes Jason and aligned ZC batching side
> > to this behavior, followed by xskxceiver adjustment. I am planning to send
> > this today EOD, however let's see how badly internal Sashiko will kick my
> > ass.
>
> Hi Maciej, do you want these applied? If they help make the tests less
> flaky I think that it's fine to take them during the merge window.
Hi Jakub,
last refactor from Tushar broke BIDIRECTIONAL test case when HW is test
target, but not on veth, so let me test these changes locally and then get
back to you.
BPF CI runs xskxceiver on veth so this has not been caught. Seems my/our
focus should be to enable xskxceiver HW tests on any kind of
environment/infrastructure.
Gonna get back to you by the EOD.
Maciej
^ permalink raw reply
* Re: [PATCH] atm: fore200e: disable PCI device on DMA mask failure
From: Andrew Lunn @ 2026-06-23 8:56 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Chas Williams, netdev, linux-atm-general, linux-kernel, Ijae Kim
In-Reply-To: <20260623075405.47120-1-mhun512@gmail.com>
On Tue, Jun 23, 2026 at 04:53:56PM +0900, Myeonghun Pak wrote:
> fore200e_pca_detect() enables the PCI device before setting the DMA
> mask. If dma_set_mask_and_coherent() fails, the current error path
> returns without disabling the device.
>
> Reuse the existing out_disable unwind label for this failure path so
> pci_disable_device() is called after a successful pci_enable_device().
What tree is this against?
ommit 6deb53595092b1426885f6503d93eedc1e3ece77
Author: Jakub Kicinski <kuba@kernel.org>
Date: Mon Apr 20 13:42:28 2026 -0700
net: remove unused ATM protocols and legacy ATM device drivers
Remove the ATM protocol modules and PCI/SBUS ATM device drivers
that are no longer in active use.
The ATM core protocol stack, PPPoATM, BR2684, and USB DSL modem
drivers (drivers/usb/atm/) are retained in-tree to maintain PPP
over ATM (PPPoA) and PPPoE-over-BR2684 support for DSL connections.
The Solos ADSL2+ PCI driver is also retained.
Removed ATM protocol modules:
- net/atm/clip.c - Classical IP over ATM (RFC 2225)
- net/atm/lec.c - LAN Emulation Client (LANE)
- net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
Removed PCI/SBUS ATM device drivers (drivers/atm/):
- adummy, atmtcp - software/testing ATM devices
- eni - Efficient Networks ENI155P (OC-3, ~1995)
- fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
Please subscribe to the netdev Mailing list, so you know what is going
on.
Andrew
---
pw-bot: reject
^ permalink raw reply
* [net] ipv6: honor per-interface proxy_ndp in forward and NA paths
From: Chenguang Zhao @ 2026-06-23 8:56 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Chenguang Zhao, Simon Horman, netdev
ndisc_recv_ns() has always checked both devconf_all and idev->cnf for
proxy_ndp, but ip6_forward() and ndisc_recv_na() only looked at the
global setting.
Honor per-interface proxy_ndp in both places to match the NS path and
allow setups that only enable proxy_ndp on specific interfaces.
Fixes: fbea49e1e240 ("[IPV6] NDISC: Add proxy_ndp sysctl.")
Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
---
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/ndisc.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 368e4fa3b43c..c4ca4a813479 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -579,8 +579,8 @@ int ip6_forward(struct sk_buff *skb)
return -ETIMEDOUT;
}
- /* XXX: idev->cnf.proxy_ndp? */
- if (READ_ONCE(net->ipv6.devconf_all->proxy_ndp) &&
+ if ((READ_ONCE(net->ipv6.devconf_all->proxy_ndp) ||
+ (idev && READ_ONCE(idev->cnf.proxy_ndp))) &&
pneigh_lookup(&nd_tbl, net, &hdr->daddr, skb->dev)) {
int proxied = ip6_forward_proxy_check(skb);
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index f867ec8d3d90..e03e94681738 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1096,9 +1096,9 @@ static enum skb_drop_reason ndisc_recv_na(struct sk_buff *skb)
*/
if (lladdr && !memcmp(lladdr, dev->dev_addr, dev->addr_len) &&
READ_ONCE(net->ipv6.devconf_all->forwarding) &&
- READ_ONCE(net->ipv6.devconf_all->proxy_ndp) &&
+ (READ_ONCE(net->ipv6.devconf_all->proxy_ndp) ||
+ (idev && READ_ONCE(idev->cnf.proxy_ndp))) &&
pneigh_lookup(&nd_tbl, net, &msg->target, dev)) {
- /* XXX: idev->cnf.proxy_ndp */
goto out;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support
From: Krzysztof Kozlowski @ 2026-06-23 8:55 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alex Elder, linux-arm-msm,
devicetree, linux-kernel, netdev
In-Reply-To: <20260622-sm8450-ipa-v1-1-532f0299f96e@proton.me>
On Mon, Jun 22, 2026 at 09:44:17PM -0400, Esteban Urrutia wrote:
> Add support for IPA in DT while expanding the IMEM region just enough to
> accommodate the modem tables used by IPA.
> As reference, SM8450 uses IPA v5.1.
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 55 ++++++++++++++++++++++++++++++++----
> 1 file changed, 50 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 56cb6e959e4e..c904720008fa 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2639,6 +2639,47 @@ adreno_smmu: iommu@3da0000 {
> dma-coherent;
> };
>
> + ipa: ipa@3f40000 {
> + compatible = "qcom,sm8450-ipa";
> +
> + iommus = <&apps_smmu 0x5c0 0x0>,
> + <&apps_smmu 0x5c2 0x0>;
> + reg = <0 0x3f40000 0 0x10000>,
'reg' is always the second property, followed by reg-names.
> + <0 0x3f50000 0 0x5000>,
> + <0 0x3e04000 0 0xfc000>;
> + reg-names = "ipa-reg",
> + "ipa-shared",
> + "gsi";
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: net: qcom,ipa: Add SM8450 compatible string
From: Krzysztof Kozlowski @ 2026-06-23 8:54 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alex Elder, linux-arm-msm,
devicetree, linux-kernel, netdev
In-Reply-To: <20260622-sm8450-ipa-v1-2-532f0299f96e@proton.me>
On Mon, Jun 22, 2026 at 09:44:18PM -0400, Esteban Urrutia wrote:
> Declare compatible string in ipa binding for SM8450,
> which uses IPA v5.1.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
With this fixed:
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init
From: Romanowski, Rafal @ 2026-06-23 8:11 UTC (permalink / raw)
To: Nguyen, Anthony L, Loktionov, Aleksandr,
intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
In-Reply-To: <c26b9257-97e7-40b8-a532-3fc0bb985a58@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Tony
> Nguyen
> Sent: Friday, June 5, 2026 10:02 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in
> ice_parser_profile_init
>
>
>
> On 5/27/2026 12:18 AM, Aleksandr Loktionov wrote:
> > set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
> > ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
> > providing ptype >= 1024 through VIRTCHNL, resulting in a write past
> > the end of the bitmap and a kernel page fault.
> >
> > Reproduced with a custom kernel module injecting a crafted
> > VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91
> 0x800214af
> > 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1.
> >
> > crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
> > crash_parser: setting ptype=0xffff (max valid=1023)
> > crash_parser: calling ice_parser_profile_init -- expect OOB crash!
> > BUG: kernel NULL pointer dereference, address: 0000000000000000
> > #PF: supervisor write access in kernel mode
> > #PF: error_code(0x0002) - not-present page
> > Oops: Oops: 0002 [#1] SMP NOPTI
> > CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U
> > OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB
> > RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace:
> > <TASK>
> > ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
> > crash_init+0x127/0xff0 [crash_parser]
> > do_one_initcall+0x45/0x310
> > do_init_module+0x64/0x270
> > init_module_from_file+0xcc/0xf0
> > idempotent_init_module+0x17b/0x280
> > __x64_sys_finit_module+0x6e/0xe0
> >
> > Bail out early with -EINVAL when ptype is out of range.
> >
> > Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > ---
> > drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c
> > b/drivers/net/ethernet/intel/ice/ice_parser.c
> > index f8e6963..3ede4c1 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> > @@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Andrew Lunn @ 2026-06-23 8:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Luo Jie,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R, linux-kernel,
linux-arm-msm, linux-clk, devicetree, netdev
In-Reply-To: <20260623073307.36483-2-krzysztof.kozlowski@oss.qualcomm.com>
> Driver is not supported - in terms of how netdev understands supported
> commitment - if maintainer does not care to receive the patches for its
> code, so demote it to "maintained" to reflect true status.
Maybe "Orphan" would be better, if the listed Maintainer is not doing
any Maintainer work?
Andrew
^ permalink raw reply
* Re: [PATCH net] net: bcmgenet: report MDIO busy timeout
From: Andrew Lunn @ 2026-06-23 8:06 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <20260623061524.51411-1-pengpeng@iscas.ac.cn>
On Tue, Jun 23, 2026 at 02:15:24PM +0800, Pengpeng Hou wrote:
> bcmgenet_mii_wait() waits for the UNIMAC MDIO command busy bit to clear,
> but ignores wait_event_timeout() and always returns success.
>
> Return -ETIMEDOUT when the busy bit remains set for the whole wait
> period so MDIO callers see the failed transaction instead of continuing
> as if the bus were idle.
MDIO is a very simple bus, basically a shift register, clocked at a
fixed rate, no possible protocol failure scenarios.
Have you actually seen this timeout occur? Or is this theoretical,
from code inspection?
We are getting lots and lots of theoretical issues reported and fixed,
while very few new developers are contributing new code, new
features. Please could you try to concentrate on things which actually
matter? Theoretical issues just waist Reviewer and Maintainer time.
Also, the merge window is open at the moment. You need to repost when
it closes:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next v3 2/2] net: phy: mdio-i2c: defer RollBall bridge probe to PHY discovery
From: Petr Wozniak @ 2026-06-23 8:05 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
In-Reply-To: <20260623080538.7646-1-petr.wozniak@gmail.com>
commit 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO
bridge in mdio-i2c") introduced a regression: the RollBall I2C-to-MDIO
bridge is not yet ready to respond to CMD_READ/CMD_DONE cycles when
sfp_sm_add_mdio_bus() runs in SFP_S_INIT. The 200 ms probe times out,
i2c_mii_probe_rollball() returns -ENODEV, and sfp_sm_add_mdio_bus()
sets mdio_protocol = MDIO_I2C_NONE. By the time sfp_sm_probe_for_phy()
runs (up to ~17 s later on affected hardware), the bridge is fully
initialized but PHY probing is skipped because the protocol has already
been changed to NONE.
This affects both modules inserted before boot and hotplugged modules on
hardware where bridge initialization exceeds the 200 ms probe window
(confirmed: FLYPRO SFP-10GT-CS-30M with Aquantia AQR113C, hotplugged).
Move the probe from i2c_mii_init_rollball(), called at bus-creation time,
to sfp_sm_probe_for_phy() in sfp.c, where it runs after the SFP state
machine module initialization delays. Export the probe function as
mdio_i2c_probe_rollball() so sfp.c can call it.
For RTL8261BE-based modules the probe correctly returns -ENODEV at PHY
discovery time, causing sfp_sm_probe_for_phy() to destroy the MDIO bus
and set MDIO_I2C_NONE, eliminating the 5+ minute PHY probe retry loop.
For genuine RollBall modules (e.g. FLYPRO SFP-10GT-CS-30M with Aquantia
AQR113C) the probe now runs after initialization is complete and
correctly returns 0, so PHY detection proceeds normally.
Reported-by: Aleksander Bajkowski <olek2@wp.pl>
Fixes: 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c")
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
v3: regenerated against net-next (v2 failed to apply due to transit
corruption); fixed block comment style (checkpatch); no functional
change.
v2: commit message only - generalized scope (Aleksander Bajkowski);
corrected SM description (Jan Hoffmann); no code change from v1.
v1: initial.
drivers/net/mdio/mdio-i2c.c | 15 +++++++++------
drivers/net/phy/sfp.c | 22 +++++++++++++---------
include/linux/mdio/mdio-i2c.h | 1 +
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/net/mdio/mdio-i2c.c b/drivers/net/mdio/mdio-i2c.c
index b88f63234b4e..2a3a418c1369 100644
--- a/drivers/net/mdio/mdio-i2c.c
+++ b/drivers/net/mdio/mdio-i2c.c
@@ -419,7 +419,7 @@ static int i2c_mii_write_rollball(struct mii_bus *bus, int phy_id, int devad,
return 0;
}
-static int i2c_mii_probe_rollball(struct i2c_adapter *i2c)
+int mdio_i2c_probe_rollball(struct i2c_adapter *i2c)
{
u8 data_buf[] = { ROLLBALL_DATA_ADDR, 0x01, 0x00, 0x00 };
u8 cmd_buf[] = { ROLLBALL_CMD_ADDR, ROLLBALL_CMD_READ };
@@ -462,9 +462,13 @@ static int i2c_mii_probe_rollball(struct i2c_adapter *i2c)
return -ENODEV;
}
+EXPORT_SYMBOL_GPL(mdio_i2c_probe_rollball);
static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
{
+ /* Send the RollBall unlock password; bridge presence is verified
+ * later, in sfp_sm_probe_for_phy(), after module initialization.
+ */
struct i2c_msg msg;
u8 pw[5];
int ret;
@@ -486,7 +490,7 @@ static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
if (ret != 1)
return -EIO;
- return i2c_mii_probe_rollball(i2c);
+ return 0;
}
static bool mdio_i2c_check_functionality(struct i2c_adapter *i2c,
@@ -531,10 +535,9 @@ struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
case MDIO_I2C_ROLLBALL:
ret = i2c_mii_init_rollball(i2c);
if (ret < 0) {
- if (ret != -ENODEV)
- dev_err(parent,
- "Cannot initialize RollBall MDIO I2C protocol: %d\n",
- ret);
+ dev_err(parent,
+ "Cannot initialize RollBall MDIO I2C protocol: %d\n",
+ ret);
mdiobus_free(mii);
return ERR_PTR(ret);
}
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index c4d274ab651e..bbfaa0450798 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -2174,17 +2174,10 @@ static void sfp_sm_fault(struct sfp *sfp, unsigned int next_state, bool warn)
static int sfp_sm_add_mdio_bus(struct sfp *sfp)
{
- int ret;
-
if (sfp->mdio_protocol == MDIO_I2C_NONE)
return 0;
- ret = sfp_i2c_mdiobus_create(sfp);
- if (ret == -ENODEV) {
- sfp->mdio_protocol = MDIO_I2C_NONE;
- return 0;
- }
- return ret;
+ return sfp_i2c_mdiobus_create(sfp);
}
/* Probe a SFP for a PHY device if the module supports copper - the PHY
@@ -2215,7 +2208,18 @@ static int sfp_sm_probe_for_phy(struct sfp *sfp)
break;
case MDIO_I2C_ROLLBALL:
- err = sfp_sm_probe_phy(sfp, SFP_PHY_ADDR_ROLLBALL, true);
+ /* Probe here, after module initialization delays, so that
+ * genuine RollBall bridges have had time to start up.
+ * Modules without a bridge (e.g. RTL8261BE) return -ENODEV.
+ */
+ err = mdio_i2c_probe_rollball(sfp->i2c);
+ if (err == -ENODEV) {
+ sfp_i2c_mdiobus_destroy(sfp);
+ sfp->mdio_protocol = MDIO_I2C_NONE;
+ break;
+ }
+ if (!err)
+ err = sfp_sm_probe_phy(sfp, SFP_PHY_ADDR_ROLLBALL, true);
break;
}
diff --git a/include/linux/mdio/mdio-i2c.h b/include/linux/mdio/mdio-i2c.h
index 65b550a6fc32..5cf14f45c94b 100644
--- a/include/linux/mdio/mdio-i2c.h
+++ b/include/linux/mdio/mdio-i2c.h
@@ -20,5 +20,6 @@ enum mdio_i2c_proto {
struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
enum mdio_i2c_proto protocol);
+int mdio_i2c_probe_rollball(struct i2c_adapter *i2c);
#endif
--
2.51.0
^ permalink raw reply related
* [PATCH net-next v3 1/2] net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
From: Petr Wozniak @ 2026-06-23 8:05 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
In-Reply-To: <20260623080538.7646-1-petr.wozniak@gmail.com>
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create().
Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release")
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
drivers/net/phy/sfp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db9..c4d274ab651e 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -963,6 +963,7 @@ static int sfp_i2c_mdiobus_create(struct sfp *sfp)
static void sfp_i2c_mdiobus_destroy(struct sfp *sfp)
{
mdiobus_unregister(sfp->i2c_mii);
+ mdiobus_free(sfp->i2c_mii);
sfp->i2c_mii = NULL;
}
--
2.51.0
^ 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