* Re: [PATCH net-next v3 01/15] net: macb: drop "consistent" from alloc/free function names
From: Théo Lebrun @ 2026-07-03 16:32 UTC (permalink / raw)
To: Conor Dooley
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260703-stucco-broadly-d9393f789868@spud>
Hello Conor,
On Fri Jul 3, 2026 at 1:28 PM CEST, Conor Dooley wrote:
> On Wed, Jul 01, 2026 at 05:59:04PM +0200, Théo Lebrun wrote:
>> Since commit 4df95131ea80 ("net/macb: change RX path for GEM") those
>> functions have not been only allocating or freeing consistent memory
>> mappings.
>>
>> Rename from macb_alloc_consistent() to macb_alloc() and
>> from macb_free_consistent() to macb_free().
>
> What does "consistent" even mean? Is it intended to be analogous to
> coherent?
That's my guess. We used to have pci_alloc_consistent(), being an alias
to dma_alloc_coherent().
This alias has been present since forever (since Git):
git show 1da177e4c3f4:include/asm-generic/pci-dma-compat.h
The alias got removed in commit 7968778914e5 ("PCI: Remove the
deprecated "pci-dma-compat.h" API", 2022-03-09).
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v9 4/4] net: phy: realtek: load firmware for RTL8261C_CG
From: Andrew Lunn @ 2026-07-03 16:30 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
maxime.chevallier, netdev, linux-kernel, daniel, vladimir.oltean
In-Reply-To: <20260703071330.1707-5-javen_xu@realsil.com.cn>
On Fri, Jul 03, 2026 at 03:13:30PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds support for loading firmware. Download some parameters
> for RTL8261C_CG.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCHv2 3/4] mmc: sdhci-esdhc-mcf: do not use readl()/writel() on ColdFire
From: Adrian Hunter @ 2026-07-03 16:29 UTC (permalink / raw)
To: Greg Ungerer, linux-m68k
Cc: linux-kernel, arnd, wei.fang, frank.li, shenwei.wang, imx, netdev,
nico, adureghello, ulfh, linux-mmc, linux-can, linux-spi, olteanv
In-Reply-To: <20260609142139.1563360-5-gerg@linux-m68k.org>
On 09/06/2026 17:13, Greg Ungerer wrote:
> The implementation of the readX() and writeX() family of IO access
> functions is non-standard on ColdFire platforms. They check the supplied
> IO address and will return either big or little endian results based on
> that check. This is non-standard, they are expected to always return
> little-endian byte ordered data. Unfortunately this behavior also means
> that ioreadX()/iowroteX() and their big-endian counter parts
> ioreadXbe()/iowriteXbe() are wrong. This is now in the process of being
> cleaned up and fixed.
>
> Change the use of the readX() and writeX() access functions in this driver
> to use the recently defined specific ColdFire internal SoC hardware IO
> access functions mcf_read8()/mcf_read16()/mcf_read32() and
> mcf_write8()/mcf_write16()/mcf_write32().
>
> There is no functional change to the driver. Though it does have the
> effect of making the IO access slightly more efficient, since there is
> no longer a need to do the address check at every register access.
>
> Acked-by: Angelo Dureghello <adureghello@baylibre.com>
> Tested-by: Angelo Dureghello <adureghello@baylibre.com>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> v2: moved from RFC to PATCH
>
> drivers/mmc/host/sdhci-esdhc-mcf.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-mcf.c b/drivers/mmc/host/sdhci-esdhc-mcf.c
> index 375fce5639d7..6853521e8b2c 100644
> --- a/drivers/mmc/host/sdhci-esdhc-mcf.c
> +++ b/drivers/mmc/host/sdhci-esdhc-mcf.c
> @@ -55,7 +55,7 @@ static inline void esdhc_clrset_be(struct sdhci_host *host,
> if (reg == SDHCI_HOST_CONTROL)
> val |= ESDHC_PROCTL_D3CD;
>
> - writel((readl(base) & ~mask) | val, base);
> + mcf_write32((mcf_read32(base) & ~mask) | val, base);
> }
>
> /*
> @@ -71,7 +71,7 @@ static void esdhc_mcf_writeb_be(struct sdhci_host *host, u8 val, int reg)
> if (reg == SDHCI_HOST_CONTROL) {
> u32 host_ctrl = ESDHC_DEFAULT_HOST_CONTROL;
> u8 dma_bits = (val & SDHCI_CTRL_DMA_MASK) >> 3;
> - u8 tmp = readb(host->ioaddr + SDHCI_HOST_CONTROL + 1);
> + u8 tmp = mcf_read8(host->ioaddr + SDHCI_HOST_CONTROL + 1);
>
> tmp &= ~0x03;
> tmp |= dma_bits;
> @@ -82,12 +82,12 @@ static void esdhc_mcf_writeb_be(struct sdhci_host *host, u8 val, int reg)
> */
> host_ctrl |= val;
> host_ctrl |= (dma_bits << 8);
> - writel(host_ctrl, host->ioaddr + SDHCI_HOST_CONTROL);
> + mcf_write32(host_ctrl, host->ioaddr + SDHCI_HOST_CONTROL);
>
> return;
> }
>
> - writel((readl(base) & mask) | (val << shift), base);
> + mcf_write32((mcf_read32(base) & mask) | (val << shift), base);
> }
>
> static void esdhc_mcf_writew_be(struct sdhci_host *host, u16 val, int reg)
> @@ -110,24 +110,24 @@ static void esdhc_mcf_writew_be(struct sdhci_host *host, u16 val, int reg)
> * As for the fsl driver,
> * we have to set the mode in a single write here.
> */
> - writel(val << 16 | mcf_data->aside,
> + mcf_write32(val << 16 | mcf_data->aside,
> host->ioaddr + SDHCI_TRANSFER_MODE);
> return;
> }
>
> - writel((readl(base) & mask) | (val << shift), base);
> + mcf_write32((mcf_read32(base) & mask) | (val << shift), base);
> }
>
> static void esdhc_mcf_writel_be(struct sdhci_host *host, u32 val, int reg)
> {
> - writel(val, host->ioaddr + reg);
> + mcf_write32(val, host->ioaddr + reg);
> }
>
> static u8 esdhc_mcf_readb_be(struct sdhci_host *host, int reg)
> {
> if (reg == SDHCI_HOST_CONTROL) {
> u8 __iomem *base = host->ioaddr + (reg & ~3);
> - u16 val = readw(base + 2);
> + u16 val = mcf_read16(base + 2);
> u8 dma_bits = (val >> 5) & SDHCI_CTRL_DMA_MASK;
> u8 host_ctrl = val & 0xff;
>
> @@ -137,7 +137,7 @@ static u8 esdhc_mcf_readb_be(struct sdhci_host *host, int reg)
> return host_ctrl;
> }
>
> - return readb(host->ioaddr + (reg ^ 0x3));
> + return mcf_read8(host->ioaddr + (reg ^ 0x3));
> }
>
> static u16 esdhc_mcf_readw_be(struct sdhci_host *host, int reg)
> @@ -149,14 +149,14 @@ static u16 esdhc_mcf_readw_be(struct sdhci_host *host, int reg)
> if (reg == SDHCI_HOST_VERSION)
> reg -= 2;
>
> - return readw(host->ioaddr + (reg ^ 0x2));
> + return mcf_read16(host->ioaddr + (reg ^ 0x2));
> }
>
> static u32 esdhc_mcf_readl_be(struct sdhci_host *host, int reg)
> {
> u32 val;
>
> - val = readl(host->ioaddr + reg);
> + val = mcf_read32(host->ioaddr + reg);
>
> /*
> * RM (25.3.9) sd pin clock must never exceed 25Mhz.
> @@ -245,7 +245,7 @@ static void esdhc_mcf_pltfm_set_clock(struct sdhci_host *host,
> * fvco = fsys * outdvi1 + 1
> * fshdc = fvco / outdiv3 + 1
> */
> - temp = readl(pll_dr);
> + temp = mcf_read32(pll_dr);
> fsys = pltfm_host->clock;
> fvco = fsys * ((temp & 0x1f) + 1);
> fesdhc = fvco / (((temp >> 10) & 0x1f) + 1);
^ permalink raw reply
* Re: [PATCH net-next v7 08/11] udp: Set length in UDP header to 0 for big GSO packets
From: Alice Mikityanska @ 2026-07-03 16:28 UTC (permalink / raw)
To: Paolo Abeni, Daniel Borkmann, David S. Miller, Eric Dumazet,
Jakub Kicinski, Xin Long, Willem de Bruijn, Willem de Bruijn,
David Ahern, Nikolay Aleksandrov
Cc: Shuah Khan, Stanislav Fomichev, Andrew Lunn, Simon Horman,
Florian Westphal, netdev, Alice Mikityanska
In-Reply-To: <617cfbfe-0b42-4ce8-a283-5c99da26bb10@redhat.com>
On Sun, Jun 14, 2026, at 16:19, Paolo Abeni wrote:
> On 6/11/26 9:29 PM, Alice Mikityanska wrote:
>> diff --git a/net/ipv6/ip6_udp_tunnel.c b/net/ipv6/ip6_udp_tunnel.c
>> index dcff7fb16ff6..32525a051a6f 100644
>> --- a/net/ipv6/ip6_udp_tunnel.c
>> +++ b/net/ipv6/ip6_udp_tunnel.c
>> @@ -93,7 +93,7 @@ void udp_tunnel6_xmit_skb(struct dst_entry *dst, struct sock *sk,
>> uh->dest = dst_port;
>> uh->source = src_port;
>>
>> - udp_set_len_short(uh, skb->len);
>> + udp_set_len(uh, skb->len);
>
> Both Sashikos noted the above breaks GSO csum, as the following
> udp_set_csum() will use skb->len to compute the csum partial.
I think the existing convention is to actually use skb->len even when
it's bigger than 64k. For example, see [1]. In order to keep this
working, I kept using skb->len for the pseudoheader checksum. I think I
made some fixups in one of previous iterations, because some places
missed using skb->len.
Regarding Sashiko's comment, I've already replied to it when it
commented the same thing on v3. These packets don't do to
__udp_gso_segment, they go to skb_udp_tunnel_segment, which calls
__skb_udp_tunnel_segment and adjusts the checksum with skb->len [1].
Please correct me if I'm missing some cases, but it looks correct
to me as is.
[1]: https://elixir.bootlin.com/linux/v7.1.2/source/net/ipv4/udp_offload.c#L192-L202
> I think it would be useful to consolidate udp_set_len() and
> udp_set_csum() in a single helper - say udp_set_csum_len():
>
> void udp_set_csum_len(bool nocheck, struct sk_buff *skb,
> __be32 saddr, __be32 daddr, int len)
> {
> struct udphdr *uh = udp_hdr(skb);
>
>
> uh->len = htons(len);
> if (nocheck) {
> uh->check = 0;
> } else if (skb_is_gso(skb)) {
> uh->len = len < GRO_LEGACY_MAX_SIZE ? htons(len) : 0;
> uh->check = ~udp_v4_check(len, saddr, daddr, 0);
> } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
> uh->check = 0;
> uh->check = udp_v4_check(len, saddr, daddr,
> // ...
>
> so that csum and len are always consistent, the 'set' logic is symmetric
> with udp_get_len(), and no duplicate checks are needed.
>
> /P
^ permalink raw reply
* Re: [RFC] connectat()/bindat() or an alternative design
From: John Ericson @ 2026-07-03 16:17 UTC (permalink / raw)
To: Christian Brauner
Cc: Cong Wang, Li Chen, Andy Lutomirski, Jens Axboe, network dev,
linux-fsdevel, Sergei Zimmerman
In-Reply-To: <20260703-teamgeist-ganoven-kundig-eff19aa92e38@brauner>
On Fri, Jul 3, 2026, at 9:35 AM, Christian Brauner wrote:
> Please stop sending a bunch of disparate patch series that all do
> slightly related or overlapping things and point back at each other.
>
> It's completely impossible to follow for anyone what's going on without
> chasing down discussion state across multiple subsystems. The net people
> have zero insight onto the fs struct discussions and it's completely
> pointless to try and design all of this based on thin air. Nothing is
> locked-in yet. This is not how this goes.
>
> This frantic pushing of various features doesn't scale. It is requesting
> costly review time for multiple RFC series
I'm sorry for the confusion and the demands on your review time from
concurrently spreading my various Capsicum-like ideas across too many
threads. I can hereafter make things more single-threaded, as I'll
propose below. I hope that helps.
Just so we are all on the same page, at the moment I believe I have
created two RFC discussion threads, and submitted one RFC patch series:
- discussion thread: [RFC] Null Namespaces
URL: https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/
Current status:
- You (Christian) are writing nullfs/failfs FDs.
- I am submitting nothing else (e.g. the actual null namespaces)
until that is done.
- discussion thread: [RFC] connectat()/bindat() or an alternative design
(this one)
URL: https://lore.kernel.org/all/b1af80fc-a57c-408d-bdfe-fa6bae26eaca@app.fastmail.com/
Current status: Working on one patch:
- Patch Series: [RFC PATCH 0/3] coredump, net: fix layer violation
with direct connection
URL: https://lore.kernel.org/all/20260703073948.2541875-1-John.Ericson@Obsidian.Systems/
- I am not submitting any UAPI changes until that is done.
(Note: This thread had some code in the first message, but I never
meant for that to be a formal submission, just a discussion aid, and
the conversation moved on from that original design anyways.)
To make things maximally single-threaded, I could pause working on
"coredump, net: fix layer violation" (i.e. preparing a v2 based on what
you requested in your review) until you are done implementing
nullfs/failfs FDs. I am actually quite happy to do that if you want; I
should spend less time on the computer the next few days anyways, so the
timing is very good for that.
Either way, I can also henceforth not refer to yet-unwritten and
-unmerged patches like nullfs/failfs FDs in the motivation for other
things.
John
P.S. There is also my non-RFC bugfix series:
[PATCH net] af_unix: fix listen() succeeding on sockets in the wrong state
URL: https://lore.kernel.org/all/20260703081416.2583118-1-John.Ericson@Obsidian.Systems/
but I don't believe you were referring to that one, since I think
bugfixes are supposed to be submitted separately and immediately. Do
correct me if I am wrong.
^ permalink raw reply
* bpf, sockmap: FIONREAD returns 0 for TCP sockets in a sockmap without a verdict program
From: Mattia Meleleo @ 2026-07-03 16:10 UTC (permalink / raw)
To: bpf; +Cc: netdev, john.fastabend@gmail.com, jakub@cloudflare.com,
jiayuan.chen
Hi,
in OpenTelemetry eBPF instrumentation we use a sockhash to track
outgoing TCP sockets for trace context propagation. Sockets are added
from a sock_ops program, and the map only has an sk_msg program
attached on the egress side - there is no ingress verdict program.
Since commit 929e30f93125 ("bpf, sockmap: Fix FIONREAD for sockmap"),
ioctl(FIONREAD) returns 0 for these sockets even though read() returns
data. tcp_bpf_ioctl() answers from psock->msg_tot_len, which only
accounts for bytes in ingress_msg. Without a verdict program, data
never lands there: it stays in sk_receive_queue and is read through
the tcp_bpf_recvmsg() fallback, so FIONREAD always reports 0.
The commit message explains that sk_receive_queue is intentionally not
counted because a verdict program may redirect or drop its contents.
Without a verdict program, however, all of that data is readable, and
applications that use FIONREAD to size their reads (nginx, Java, .NET)
hang or truncate transfers once their sockets are in the map.
Observed on mainline and on 6.12.75+, 6.6.128+, 6.18.14+.
Reproducer: https://github.com/mmat11/fionread-repro
pre-insert FIONREAD=4096 (expect 4096) OK
in-sockhash FIONREAD=0 (expect 4096) BROKEN
post-delete FIONREAD=4096 (expect 4096) OK
Is this intended for psocks without a verdict program? If not, would
falling back to tcp_inq() (plus msg_tot_len) in that case be an
acceptable fix? Happy to send a patch and test it.
Thanks,
Mattia
^ permalink raw reply
* Re: [PATCH net] gve: fix Rx queue stall on alloc failure
From: Maciej Fijalkowski @ 2026-07-03 16:05 UTC (permalink / raw)
To: Eddie Phillips
Cc: Harshitha Ramamurthy, netdev, joshwash, andrew+netdev, davem,
edumazet, kuba, pabeni, ast, daniel, hawk, john.fastabend, bpf,
sdf, willemb, jordanrhee, nktgrg, maolson, jacob.e.keller,
thostet, csully, bcf, linux-kernel, stable
In-Reply-To: <CAPBb8HmE6q0VPa5PooFP3VFF27GU3B4622Xww6MHRT-9i4zTxA@mail.gmail.com>
On Fri, Jul 03, 2026 at 01:03:20AM -0700, Eddie Phillips wrote:
> > I think this deserves to be pulled out of the timer logic?
>
> If by this you mean pull the stats into a separate patch, I agree.
Hi Eddie,
instead of forming a response at the top of the mail, please have your
answers inlined; it is preferred way of communication on mailing lists.
>
> > - couldn't you detect this case within napi poll loop?
>
> It can only be detected after attempting to refill the queue and finding
> that we are still below the critical threshold.
>
> > - if not, does it have to be per-q timer? wouldn't one global per pf timer
> > satisfy your needs?
>
> There are a few ways a global timer could be implemented,
> - The global timer could queue napi for *all* queues, which would
> result in a lot of unnecessary work.
> - The global timer could iterate over each queue and try to detect
> the critical low buffer condition, however this would require
> introducing synchronization between the timer and the napis, which
> would introduce expensive locking into the hot path.
> - The global timer could be paired with a bitmap that stores which
> queues need to be serviced.
bitmap would probably do the job but i won't insist here tho.
One more question/idea:
Before arming the starvation timer, could we first try to make a smaller batch
of already-posted buffers visible to HW?
It seems the HW can accept RX buffer tail doorbell updates at a granularity
lower than the normal `GVE_RX_BUF_THRESH_DQO` batching threshold, apparently as
low as 8 descriptors. If that is the case, could we first use this as an
emergency low-watermark path: when refill posts at least 8 descriptors but does
not reach the normal 32-descriptor threshold, ring the doorbell immediately and
only arm the starvation timer if even that lower threshold cannot be reached?
>
> A `struct timer_list` is only 40 bytes, so the current implemention is
> not expensive. Though a global timer is valid, it's not strictly better.
>
> That said, I agree that we can clean up the structure—I will move the
> timer state from the individual RX rings to the `gve_priv` structure.
>
> On Wed, Jul 1, 2026 at 6:22 AM Maciej Fijalkowski
> <maciej.fijalkowski@intel.com> wrote:
> >
> > On Wed, Jul 01, 2026 at 12:53:41AM +0000, Harshitha Ramamurthy wrote:
> > > From: Eddie Phillips <eddiephillips@google.com>
> > >
> > > When the system is under extreme memory pressure, page allocations can
> > > fail during the Rx buffer refill loop. If the number of buffers posted
> > > to hardware falls below a critical low threshold and the refill loop
> > > exits due to allocation failures, the queue can stall:
> > >
> > > 1. The device drops incoming packets because there are no descriptors.
> > > 2. Since no packets are processed, no Rx completions are generated.
> > > 3. Because no completions occur, NAPI is never scheduled, preventing
> > > the refill loop from running again even after memory is freed.
> > >
> > > This results in a permanent queue stall.
> > >
> > > Resolve this by introducing a starvation recovery timer for each Rx queue.
> > > If the number of buffers posted to hardware falls below a critical low
> > > threshold, start a timer to periodically reschedule NAPI. Once NAPI runs
> > > and successfully refills the queue above the threshold, the timer is
> > > not rescheduled.
> > >
> > > Also add a new ethtool statistic "rx_critical_low_bufs" to track the
> > > number of times the starvation recovery timer is triggered.
> >
> > I think this deserves to be pulled out of the timer logic?
> >
> > Two questions tho:
> > - couldn't you detect this case within napi poll loop?
> > - if not, does it have to be per-q timer? wouldn't one global per pf timer
> > satisfy your needs?
> >
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path")
> > > Reviewed-by: Jordan Rhee <jordanrhee@google.com>
> > > Signed-off-by: Eddie Phillips <eddiephillips@google.com>
> > > Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > > ---
> > > drivers/net/ethernet/google/gve/gve.h | 4 ++++
> > > drivers/net/ethernet/google/gve/gve_ethtool.c | 14 +++++++++++++-
> > > drivers/net/ethernet/google/gve/gve_rx_dqo.c | 32 ++++++++++++++++++++++++++++++++
> > > 3 files changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h
> > > index 2f7bd330..8378bef2 100644
> > > --- a/drivers/net/ethernet/google/gve/gve.h
> > > +++ b/drivers/net/ethernet/google/gve/gve.h
> > > @@ -13,6 +13,7 @@
> > > #include <linux/netdevice.h>
> > > #include <linux/net_tstamp.h>
> > > #include <linux/pci.h>
> > > +#include <linux/timer.h>
> > > #include <linux/ptp_clock_kernel.h>
> > > #include <linux/u64_stats_sync.h>
> > > #include <net/page_pool/helpers.h>
> > > @@ -41,6 +42,7 @@
> > >
> > > /* Interval to schedule a stats report update, 20000ms. */
> > > #define GVE_STATS_REPORT_TIMER_PERIOD 20000
> > > +#define GVE_RX_NAPI_RESCHED_MS 20 /* msecs */
> > >
> > > /* Numbers of NIC tx/rx stats in stats report. */
> > > #define NIC_TX_STATS_REPORT_NUM 0
> > > @@ -318,6 +320,7 @@ struct gve_rx_ring {
> > > u64 rx_copied_pkt; /* free-running total number of copied packets */
> > > u64 rx_skb_alloc_fail; /* free-running count of skb alloc fails */
> > > u64 rx_buf_alloc_fail; /* free-running count of buffer alloc fails */
> > > + u64 rx_critical_low_bufs; /* count of critical low buffer events */
> > > u64 rx_desc_err_dropped_pkt; /* free-running count of packets dropped by descriptor error */
> > > /* free-running count of unsplit packets due to header buffer overflow or hdr_len is 0 */
> > > u64 rx_hsplit_unsplit_pkt;
> > > @@ -334,6 +337,7 @@ struct gve_rx_ring {
> > > struct gve_queue_resources *q_resources; /* head and tail pointer idx */
> > > dma_addr_t q_resources_bus; /* dma address for the queue resources */
> > > struct u64_stats_sync statss; /* sync stats for 32bit archs */
> > > + struct timer_list starvation_timer; /* for queue starvation recovery */
> > >
> > > struct gve_rx_ctx ctx; /* Info for packet currently being processed in this ring. */
> > >
> > > diff --git a/drivers/net/ethernet/google/gve/gve_ethtool.c b/drivers/net/ethernet/google/gve/gve_ethtool.c
> > > index a0e0472b..71b6efbf 100644
> > > --- a/drivers/net/ethernet/google/gve/gve_ethtool.c
> > > +++ b/drivers/net/ethernet/google/gve/gve_ethtool.c
> > > @@ -46,6 +46,7 @@ static const char gve_gstrings_main_stats[][ETH_GSTRING_LEN] = {
> > > "rx_hsplit_unsplit_pkt",
> > > "interface_up_cnt", "interface_down_cnt", "reset_cnt",
> > > "page_alloc_fail", "dma_mapping_error", "stats_report_trigger_cnt",
> > > + "rx_critical_low_bufs",
> > > };
> > >
> > > static const char gve_gstrings_rx_stats[][ETH_GSTRING_LEN] = {
> > > @@ -58,6 +59,7 @@ static const char gve_gstrings_rx_stats[][ETH_GSTRING_LEN] = {
> > > "rx_xdp_aborted[%u]", "rx_xdp_drop[%u]", "rx_xdp_pass[%u]",
> > > "rx_xdp_tx[%u]", "rx_xdp_redirect[%u]",
> > > "rx_xdp_tx_errors[%u]", "rx_xdp_redirect_errors[%u]", "rx_xdp_alloc_fails[%u]",
> > > + "rx_critical_low_bufs[%u]",
> > > };
> > >
> > > static const char gve_gstrings_tx_stats[][ETH_GSTRING_LEN] = {
> > > @@ -151,12 +153,14 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > > {
> > > u64 tmp_rx_pkts, tmp_rx_hsplit_pkt, tmp_rx_bytes, tmp_rx_hsplit_bytes,
> > > tmp_rx_skb_alloc_fail, tmp_rx_buf_alloc_fail,
> > > + tmp_rx_critical_low_bufs,
> > > tmp_rx_desc_err_dropped_pkt, tmp_rx_hsplit_unsplit_pkt,
> > > tmp_tx_pkts, tmp_tx_bytes,
> > > tmp_xdp_tx_errors, tmp_xdp_redirect_errors;
> > > u64 rx_buf_alloc_fail, rx_desc_err_dropped_pkt, rx_hsplit_unsplit_pkt,
> > > rx_pkts, rx_hsplit_pkt, rx_skb_alloc_fail, rx_bytes, tx_pkts, tx_bytes,
> > > - tx_dropped, xdp_tx_errors, xdp_redirect_errors;
> > > + rx_critical_low_bufs, tx_dropped, xdp_tx_errors,
> > > + xdp_redirect_errors;
> > > int rx_base_stats_idx, max_rx_stats_idx, max_tx_stats_idx;
> > > int stats_idx, stats_region_len, nic_stats_len;
> > > struct stats *report_stats;
> > > @@ -197,6 +201,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > >
> > > for (rx_pkts = 0, rx_bytes = 0, rx_hsplit_pkt = 0,
> > > rx_skb_alloc_fail = 0, rx_buf_alloc_fail = 0,
> > > + rx_critical_low_bufs = 0,
> > > rx_desc_err_dropped_pkt = 0, rx_hsplit_unsplit_pkt = 0,
> > > xdp_tx_errors = 0, xdp_redirect_errors = 0,
> > > ring = 0;
> > > @@ -212,6 +217,8 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > > tmp_rx_bytes = rx->rbytes;
> > > tmp_rx_skb_alloc_fail = rx->rx_skb_alloc_fail;
> > > tmp_rx_buf_alloc_fail = rx->rx_buf_alloc_fail;
> > > + tmp_rx_critical_low_bufs =
> > > + rx->rx_critical_low_bufs;
> > > tmp_rx_desc_err_dropped_pkt =
> > > rx->rx_desc_err_dropped_pkt;
> > > tmp_rx_hsplit_unsplit_pkt =
> > > @@ -226,6 +233,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > > rx_bytes += tmp_rx_bytes;
> > > rx_skb_alloc_fail += tmp_rx_skb_alloc_fail;
> > > rx_buf_alloc_fail += tmp_rx_buf_alloc_fail;
> > > + rx_critical_low_bufs += tmp_rx_critical_low_bufs;
> > > rx_desc_err_dropped_pkt += tmp_rx_desc_err_dropped_pkt;
> > > rx_hsplit_unsplit_pkt += tmp_rx_hsplit_unsplit_pkt;
> > > xdp_tx_errors += tmp_xdp_tx_errors;
> > > @@ -269,6 +277,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > > data[i++] = priv->page_alloc_fail;
> > > data[i++] = priv->dma_mapping_error;
> > > data[i++] = priv->stats_report_trigger_cnt;
> > > + data[i++] = rx_critical_low_bufs;
> > > i = GVE_MAIN_STATS_LEN;
> > >
> > > rx_base_stats_idx = 0;
> > > @@ -337,6 +346,8 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > > tmp_rx_hsplit_bytes = rx->rx_hsplit_bytes;
> > > tmp_rx_skb_alloc_fail = rx->rx_skb_alloc_fail;
> > > tmp_rx_buf_alloc_fail = rx->rx_buf_alloc_fail;
> > > + tmp_rx_critical_low_bufs =
> > > + rx->rx_critical_low_bufs;
> > > tmp_rx_desc_err_dropped_pkt =
> > > rx->rx_desc_err_dropped_pkt;
> > > tmp_xdp_tx_errors = rx->xdp_tx_errors;
> > > @@ -381,6 +392,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
> > > } while (u64_stats_fetch_retry(&priv->rx[ring].statss,
> > > start));
> > > i += GVE_XDP_ACTIONS + 3; /* XDP rx counters */
> > > + data[i++] = tmp_rx_critical_low_bufs;
> > > }
> > > } else {
> > > i += priv->rx_cfg.num_queues * NUM_GVE_RX_CNTS;
> > > diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> > > index 02cba280..303db4fa 100644
> > > --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> > > +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
> > > @@ -18,6 +18,16 @@
> > > #include <net/tcp.h>
> > > #include <net/xdp_sock_drv.h>
> > >
> > > +static void gve_rx_starvation_timer(struct timer_list *t)
> > > +{
> > > + struct gve_rx_ring *rx = timer_container_of(rx, t, starvation_timer);
> > > + struct gve_priv *priv = rx->gve;
> > > + struct gve_notify_block *block;
> > > +
> > > + block = &priv->ntfy_blocks[rx->ntfy_id];
> > > + napi_schedule(&block->napi);
> > > +}
> > > +
> > > static void gve_rx_free_hdr_bufs(struct gve_priv *priv, struct gve_rx_ring *rx)
> > > {
> > > struct device *hdev = &priv->pdev->dev;
> > > @@ -120,6 +130,7 @@ void gve_rx_stop_ring_dqo(struct gve_priv *priv, int idx)
> > >
> > > if (rx->dqo.page_pool)
> > > page_pool_disable_direct_recycling(rx->dqo.page_pool);
> > > + timer_delete_sync(&rx->starvation_timer);
> > > gve_remove_napi(priv, ntfy_idx);
> > > gve_rx_remove_from_block(priv, idx);
> > > gve_rx_reset_ring_dqo(priv, idx);
> > > @@ -136,6 +147,8 @@ void gve_rx_free_ring_dqo(struct gve_priv *priv, struct gve_rx_ring *rx,
> > > u32 qpl_id;
> > > int i;
> > >
> > > + timer_shutdown_sync(&rx->starvation_timer);
> > > +
> > > completion_queue_slots = rx->dqo.complq.mask + 1;
> > > buffer_queue_slots = rx->dqo.bufq.mask + 1;
> > >
> > > @@ -232,6 +245,7 @@ int gve_rx_alloc_ring_dqo(struct gve_priv *priv,
> > > rx->gve = priv;
> > > rx->q_num = idx;
> > > rx->packet_buffer_size = cfg->packet_buffer_size;
> > > + timer_setup(&rx->starvation_timer, gve_rx_starvation_timer, 0);
> > >
> > > if (cfg->xdp) {
> > > rx->packet_buffer_truesize = GVE_XDP_RX_BUFFER_SIZE_DQO;
> > > @@ -365,6 +379,7 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
> > > struct gve_rx_compl_queue_dqo *complq = &rx->dqo.complq;
> > > struct gve_rx_buf_queue_dqo *bufq = &rx->dqo.bufq;
> > > struct gve_priv *priv = rx->gve;
> > > + u32 num_bufs_avail_to_hw;
> > > u32 num_avail_slots;
> > > u32 num_full_slots;
> > > u32 num_posted = 0;
> > > @@ -400,6 +415,23 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
> > > }
> > >
> > > rx->fill_cnt += num_posted;
> > > +
> > > + /* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
> > > + * visible to the hardware, and no doorbell was written, the hardware
> > > + * is in danger of starving and cannot trigger interrupts. Start the
> > > + * timer to periodically reschedule NAPI and recover from starvation.
> > > + */
> > > + num_bufs_avail_to_hw =
> > > + ((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
> > > + bufq->head) & bufq->mask;
> > > +
> > > + if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
> > > + u64_stats_update_begin(&rx->statss);
> > > + rx->rx_critical_low_bufs++;
> > > + u64_stats_update_end(&rx->statss);
> > > + mod_timer(&rx->starvation_timer,
> > > + jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
> > > + }
> > > }
> > >
> > > static void gve_rx_skb_csum(struct sk_buff *skb,
> > > --
> > > 2.55.0.rc2.803.g1fd1e6609c-goog
> > >
> > >
^ permalink raw reply
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Guillaume Nault @ 2026-07-03 16:05 UTC (permalink / raw)
To: Qingfang Deng
Cc: Norbert Szetei, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Sebastian Andrzej Siewior,
Breno Leitao, Taegu Ha, Kees Cook, linux-ppp, linux-kernel,
netdev
In-Reply-To: <166370f4-0b8c-4af4-9fb7-6967828a99bc@linux.dev>
On Thu, Jul 02, 2026 at 04:19:02PM +0800, Qingfang Deng wrote:
> Add: Guillaume
>
> On 2026/7/2 at 2:12, Norbert Szetei wrote:
> > pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path:
> >
> > l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv()
> > -> ppp_input(&po->chan)
Hi Qingfang,
Thanks for Cc-ing me. I haven't had time to look at this problem yet,
and I'll be offline next week. So not sure if I'll get the possibility
to provide any feedback to this patch in time.
> > It runs under rcu_read_lock() holding only an l2tp_session reference and
> > takes NO reference on the internal PPP channel (struct channel,
> > chan->ppp) that ppp_input() dereferences.
> >
> > The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel
> > are RCU-safe. But the internal struct channel is a separate allocation
> > that ppp_release_channel() frees with a plain kfree():
> >
> > close(data socket) -> pppol2tp_release() -> pppox_unbind_sock()
> > -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch)
> >
> > For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit
> > (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips
> > both ppp_disconnect_channel()'s synchronize_net() and
> > ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace
> > period. rcu_read_lock() in pppol2tp_recv() does not protect against a
> > plain kfree(), so an in-flight ppp_input() on one CPU can dereference
> > the channel just freed by close() on another CPU.
> >
> > The bug is reachable by an unprivileged user.
> >
> > Defer the channel free to an RCU callback via call_rcu() so the grace
> > period fences any in-flight ppp_input(). The disconnect and unbridge
> > teardown paths already fence with synchronize_net()/synchronize_rcu();
> > call_rcu() does the same here without stalling the close() path.
> >
> > Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU")
> > Assisted-by: Claude:claude-opus-4-8
> > Signed-off-by: Norbert Szetei <norbert@doyensec.com>
> > ---
> > v2:
> > - Moved skb_queue_purge() to a dedicated RCU callback to prevent leaking
> > skbs added by an in-flight ppp_input() during the grace period (Sebastian).
> > - Retained call_rcu() to avoid introducing synchronous multi-millisecond
> > latency into the teardown path.
> > v1: https://lore.kernel.org/netdev/C954A7EA-AA98-4E3C-80B5-42C34B3183A3@doyensec.com/
> >
> > drivers/net/ppp/ppp_generic.c | 17 ++++++++++++++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> > index 57c68efa5ff8..2d57de77780f 100644
> > --- a/drivers/net/ppp/ppp_generic.c
> > +++ b/drivers/net/ppp/ppp_generic.c
> > @@ -184,6 +184,7 @@ struct channel {
> > struct list_head clist; /* link in list of channels per unit */
> > spinlock_t upl; /* protects `ppp' and 'bridge' */
> > struct channel __rcu *bridge; /* "bridged" ppp channel */
> > + struct rcu_head rcu; /* for RCU-deferred free of the channel */
> > #ifdef CONFIG_PPP_MULTILINK
> > u8 avail; /* flag used in multilink stuff */
> > u8 had_frag; /* >= 1 fragments have been sent */
> > @@ -3562,6 +3563,18 @@ ppp_disconnect_channel(struct channel *pch)
> > return err;
> > }
> > +/* Purge after the grace period: a late ppp_input() may still queue an
> > + * skb on pch->file.rq before the last RCU reader drains.
> > + */
> > +static void ppp_release_channel_free(struct rcu_head *rcu)
> > +{
> > + struct channel *pch = container_of(rcu, struct channel, rcu);
> > +
> > + skb_queue_purge(&pch->file.xq);
> > + skb_queue_purge(&pch->file.rq);
> > + kfree(pch);
> > +}
> > +
> > /*
> > * Drop a reference to a ppp channel and free its memory if the refcount reaches
> > * zero.
> > @@ -3581,9 +3594,7 @@ static void ppp_release_channel(struct channel *pch)
> > pr_err("ppp: destroying undead channel %p !\n", pch);
> > return;
> > }
> > - skb_queue_purge(&pch->file.xq);
> > - skb_queue_purge(&pch->file.rq);
> > - kfree(pch);
> > + call_rcu(&pch->rcu, ppp_release_channel_free);
> > }
> > static void __exit ppp_cleanup(void)
>
> Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev>
>
> FYI, I attempted to merge the two channel structs and AI-review found a UAF
> [1], so this patch addresses the issue.
>
> [1] https://lore.kernel.org/netdev/590d7931-02b0-45d6-8f43-ef909c9bde89@redhat.com/
>
> Best regards,
>
> Qingfang
>
>
^ permalink raw reply
* Re: [PATCH net-next] tun: no longer rely on RTNL in tun_fill_info()
From: Willem de Bruijn @ 2026-07-03 15:43 UTC (permalink / raw)
To: Kuniyuki Iwashima, Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Andrew Lunn, netdev, eric.dumazet
In-Reply-To: <CAAVpQUC1UKqqUdQaP+ud_uGkhByxooMvCs1H7i7q=OzQFP7trA@mail.gmail.com>
Kuniyuki Iwashima wrote:
> On Wed, Jul 1, 2026 at 5:51 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > Update tun_fill_info() to read device configuration fields (flags, owner,
> > group, numqueues, numdisabled) locklessly using READ_ONCE().
> >
> > Annotate all writes to these fields in the control paths with WRITE_ONCE()
> > to prevent data races, as these fields can be modified concurrently via
> > ioctls (TUNSETPERSIST, TUNSETOWNER, TUNSETGROUP, TUNSETIFF) or queue
> > attaching/detaching.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: embedded PTP timestamp support
From: Maxime Chevallier @ 2026-07-03 15:41 UTC (permalink / raw)
To: Luke Howard, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vivien Didelot, Gregory CLEMENT,
Andrew Lunn, Richard Cochran
Cc: Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260703-mv88e6xxx-ptp-fixes-v1-2-0138581889a9@padl.com>
Hi Luke,
On 7/3/26 08:41, Luke Howard wrote:
> mv88e6xxx switches can support embedding PTP timestamps directly
> in the frame, either as a trailer or at a configurable offset
> (typically the reserved bytes in the PTP header).
>
> Add support for this on the 88E6341 and 88E6352 switches, being
> those on which I was able to verify this. Other switch chips may
> also work. The arrival timestamp offsets are relative to the PTP
> common header and will work for both L2 and L3 PTP packets; the
> respective headers are skipped by the number of bytes set in the
> ETJump and IPJump registers, which are initialized to sensible
> defaults and are VLAN tag-aware.
>
> (Note: the 6352 datasheet incorrectly states that ETJump and
> IPJump are initialized to zero. They are initialized to 12 and
> 2 respectively; this is corrected in the 6341 data sheet.)
>
> Signed-off-by: Luke Howard <lukeh@padl.com>
[...]
> +static bool parse_embedded_ts(unsigned int arr_ts_mode,
> + struct sk_buff *skb, u64 *ns)
> +{
> + struct ptp_header *hdr;
> +
> + *ns = 0;
> +
> + /* APPEND means the switch appended the time stamp as a 4-byte trailer
> + * (not all switches support this). Any other non-zero value is the byte
> + * offset past the start of the PTP common header at which the switch
> + * overwrote the time stamp in place (e.g. the reserved header bytes).
> + */
> + if (arr_ts_mode == MV88E6XXX_PTP_ARR_TS_MODE_APPEND && skb->len >= 4) {
> + *ns = (u64)get_unaligned_be32(&skb->data[skb->len - 4]);
One thing is that you need to make sure you're dealing with a linear skb
when accessing the trailer, which can be done by calling skb_linearize(skb).
Then you should use skb_tail_pointer(skb) to get to the trailer.
You can take as examples the DSA taggers that pull the tag from the tail, such as
the tag_trailer [1], tag_ksz, tag_rtl8_4, etc.
And finally you may have to use the chksum variants of the skb_trim such as
pskb_trim_rcsum(), like done in the above-mentionned taggers.
[1] : https://elixir.bootlin.com/linux/v7.1.2/source/net/dsa/tag_trailer.c#L28
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: use direct ATU hash on 88E6141/6341
From: Andrew Lunn @ 2026-07-03 15:40 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Cedric Jehasse,
Kieran Tyrrell, Max Holtmann, Max Hunter, Christoph Mellauner,
Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260703-mv88e6x41-fixes-v1-2-fbd3a1bf8965@padl.com>
On Fri, Jul 03, 2026 at 04:42:56PM +1000, Luke Howard wrote:
> The default 88E6341/88E6141 ATU hash algorithm appears to result
> in frequent collisions, evicting permanent registrations (including
> the broadcast address) out of the ATU.
Is there any documentation about how the 88E6341/88E6141 hashing
algorithm is different to all the other chips? How is it special?
> This workaround disables hasing in the ATU control register. It may
hashing.
> have a performance impact (the data sheet notes this is for testing
> only), but it also enables correctness, at least in local testing.
How do you define correctness? Are you using a well defined test?
Why is the devlink parameter not sufficient.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: write the ATU FID register on 88E6141/88E6341
From: Andrew Lunn @ 2026-07-03 15:31 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Cedric Jehasse,
Kieran Tyrrell, Max Holtmann, Max Hunter, Christoph Mellauner,
Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260703-mv88e6x41-fixes-v1-1-fbd3a1bf8965@padl.com>
On Fri, Jul 03, 2026 at 04:42:55PM +1000, Luke Howard wrote:
> The existing code assumed the 88E6141/88E6341 did not have a dedicated
> ATU FID register because of its database count (256), instead taking
> the legacy path which resulted in the FID register never being set.
>
> This resulted in every FDB entry being loaded into FID 0, breaking
> VLAN aware bridging.
>
> Fixes: a75961d0ebfd ("net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341")
Please submit fixes to the net tree.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> @@ -131,6 +131,7 @@ struct mv88e6xxx_info {
> u16 prod_num;
> const char *name;
> unsigned int num_databases;
> + bool atu_fid_reg;
> unsigned int num_macs;
> unsigned int num_ports;
> unsigned int num_internal_phys;
Please think about padding. The current structure layout is not great,
invalid_port_mask should be somewhere else, but please don't make it
worse. Also, this structure has some reasonable comments. You have the
chance to comment that the number of FIBs does not imply if there is a
dedicated register, there are examples with 255 and a dedicated
register.
> diff --git a/drivers/net/dsa/mv88e6xxx/global1_atu.c b/drivers/net/dsa/mv88e6xxx/global1_atu.c
> index c47f068f56b32..aa5adc78607ca 100644
> --- a/drivers/net/dsa/mv88e6xxx/global1_atu.c
> +++ b/drivers/net/dsa/mv88e6xxx/global1_atu.c
> @@ -135,7 +135,7 @@ static int mv88e6xxx_g1_atu_op(struct mv88e6xxx_chip *chip, u16 fid, u16 op)
> int err;
>
> /* FID bits are dispatched all around gradually as more are supported */
> - if (mv88e6xxx_num_databases(chip) > 256) {
> + if (mv88e6xxx_num_databases(chip) > 256 || chip->info->atu_fid_reg) {
So currently, > 256 implies a dedicated register. But do we need both
> 255 and chip->info->atu_fid_reg? I would probably set atu_fid_reg
true for all devices which have a dedicated register.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: use ARRIVAL1 counter for all peer delay messages
From: Andrew Lunn @ 2026-07-03 15:14 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Richard Cochran,
Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260703-mv88e6xxx-ptp-fixes-v1-1-0138581889a9@padl.com>
On Fri, Jul 03, 2026 at 04:41:58PM +1000, Luke Howard wrote:
> mv88e6xxx switches have two arrival timestamp counters for timestamping
> PTP event messages. This permits more than one arriving event message's
> timestamp to be captured. This is useful for the case where event
> messages from a grandmaster arrive at the same time as PDelayReq/PDelayResp
> messages from a peer.
>
> Previously only PDelayResp messages were assigned to the second arrival
> counter; this patch does so for PDelayReq messages as well.
>
> Signed-off-by: Luke Howard <lukeh@padl.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: embedded PTP timestamp support
From: Andrew Lunn @ 2026-07-03 15:13 UTC (permalink / raw)
To: Luke Howard
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Richard Cochran,
Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260703-mv88e6xxx-ptp-fixes-v1-2-0138581889a9@padl.com>
> + /* Arrival Time Stamp Mode (ArrTSMode); see the ArrTSMode encoding in
> + * hwtstamp.h. Zero (the default) leaves arrival time stamps in the
> + * switch registers; non-zero embeds them in the frame, either appended
> + * as a trailer or overwritten at that byte offset past the start of the
> + * PTP common header.
So how do you indicate trailer?
> +++ b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
> @@ -8,6 +8,8 @@
> * Erik Hons <erik.hons@ni.com>
> * Brandon Streiff <brandon.streiff@ni.com>
> * Dane Wagner <dane.wagner@ni.com>
> + *
> + * Copyright (c) 2025 PADL Software Pty Ltd
It is unusual to add a copyright for the passed.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
From: Mieczyslaw Nalewaj @ 2026-07-03 15:12 UTC (permalink / raw)
To: Johan Alvarado, linusw, alsi, andrew, olteanv, kuba, davem,
edumazet, pabeni, linux
Cc: luizluca, maxime.chevallier, netdev, linux-kernel
In-Reply-To: <0100019f24962e49-10163ad6-22fd-4528-b8f3-75703cfd80dc-000000@email.amazonses.com>
On 7/2/2026 10:47 PM, Johan Alvarado wrote:
> In addition to SGMII, the RTL8367S SerDes also supports HSGMII, which
> carries 2.5 Gbps with the same signaling as SGMII at 2.5x clock rate.
> The chip info table already declares HSGMII as a supported interface
> mode for external interface 1.
>
> Extend the SerDes PCS to handle HSGMII, which phylink represents as
> 2500base-x:
>
> - Select the HSGMII SerDes tuning parameters and external interface
> mode, and mux the SerDes to MAC8 in HSGMII mode, from pcs_config()
> according to the interface. The parameters are again lifted from the
> GPL-licensed Realtek rtl8367c vendor driver, and again only cover
> the tuning variant for a non-zero chip option, so the mode is gated
> on the option probed at setup.
[...]
> @@ -1264,6 +1279,16 @@ static int rtl8365mb_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
> if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED)
> return -EOPNOTSUPP;
>
> + if (interface == PHY_INTERFACE_MODE_2500BASEX) {
> + sds_jam = rtl8365mb_sds_jam_hsgmii;
> + sds_jam_size = ARRAY_SIZE(rtl8365mb_sds_jam_hsgmii);
> + mode = RTL8365MB_EXT_PORT_MODE_HSGMII;
> + } else {
> + sds_jam = rtl8365mb_sds_jam_sgmii;
> + sds_jam_size = ARRAY_SIZE(rtl8365mb_sds_jam_sgmii);
> + mode = RTL8365MB_EXT_PORT_MODE_SGMII;
> + }
> +
Johan, looks like you forgot to include the scheduler bandwidth bits for the CPU port. Without this, HSGMII will still be capped at the old SGMII rate limits. Something like:
#define RTL8365MB_REG_INGRESSBW_PORT6_RATE_CTRL1 0x00d0
#define RTL8365MB_INGRESSBW_PORT6_RATE_CTRL1_INGRESSBW_RATE16_MASK GENMASK(2, 0)
#define RTL8365MB_REG_PORT6_EGRESSBW_CTRL1 0x0399
#define RTL8365MB_PORT6_EGRESSBW_CTRL1_MASK GENMASK(2, 0)
#define RTL8365MB_REG_LINE_RATE_HSG_H 0x03fa
#define RTL8365MB_LINE_RATE_HSG_H_MASK GENMASK(2, 0)
[...]
/* Allow full 2.5G on HSGMII CPU port: set scheduler
* bandwidth limits to max (0x7). Fixed-link init-only;
* no runtime SGMII reconfiguration is expected here.
*/
ret = regmap_write(priv->map,
RTL8365MB_REG_INGRESSBW_PORT6_RATE_CTRL1,
FIELD_PREP(RTL8365MB_INGRESSBW_PORT6_RATE_CTRL1_INGRESSBW_RATE16_MASK,
7));
if (ret)
return ret;
ret = regmap_write(priv->map,
RTL8365MB_REG_PORT6_EGRESSBW_CTRL1,
FIELD_PREP(RTL8365MB_PORT6_EGRESSBW_CTRL1_MASK,
7));
if (ret)
return ret;
ret = regmap_write(priv->map,
RTL8365MB_REG_LINE_RATE_HSG_H,
FIELD_PREP(RTL8365MB_LINE_RATE_HSG_H_MASK,
7));
if (ret)
return ret;
One more thing while we're on this: I checked the equivalent registers for RGMII on the RTL8367S, and they come out to 1, 1, 7 respectively (INGRESSBW_PORT6_RATE_CTRL1, PORT6_EGRESSBW_CTRL1, LINE_RATE_HSG_H). For correctness these should be set to those values in the RGMII path as well, rather than left at whatever reset/default state they're currently in.
^ permalink raw reply
* Re: [PATCH v9 01/14] firmware: qcom: Add a generic PAS service
From: Konrad Dybcio @ 2026-07-03 15:06 UTC (permalink / raw)
To: Sumit Garg, andersson, konradybcio
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
bod, mchehab, elder, andrew+netdev, davem, edumazet, kuba, pabeni,
jjohnson, mathieu.poirier, trilokkumar.soni, mukesh.ojha,
pavan.kondeti, jorge.ramirez, tonyh, vignesh.viswanathan,
srinivas.kandagatla, amirreza.zarrabi, jenswi, op-tee, apurupa,
skare, linux-kernel, Sumit Garg, Harshal Dev
In-Reply-To: <20260702115835.167602-2-sumit.garg@kernel.org>
On 7/2/26 1:58 PM, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: usb: move exported code to usbnet
From: Andrew Lunn @ 2026-07-03 14:59 UTC (permalink / raw)
To: Oliver Neukum
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, shaoxul, netdev,
linux-usb, linux-kernel
In-Reply-To: <c3d3c7a0-5d47-4e73-a46b-2fd610f4cd59@suse.com>
On Fri, Jul 03, 2026 at 12:16:20PM +0200, Oliver Neukum wrote:
> On 02.07.26 20:15, Andrew Lunn wrote:
> > On Thu, Jul 02, 2026 at 04:25:29PM +0200, Oliver Neukum wrote:
> > > Some drivers are reusing common code originating in other drivers.
> > > This means that two drivers need to be loaded for one device.
> >
> > Maybe consider using 'framework' or 'library', rather than driver,
> > when referring to the shared code?
> >
> > I tend to think of a driver as the leaf node which probes based on
> > enumeration of a bus. But usbnet.c itself is never probed.
>
> Yes, I also think of a leaf node when a "driver" is referred to.
> That is the very point. Currently you need _two_ drivers and
> usbnet for some devices.
> Should I reformulate? If so, how exactly?
Maybe give examples? List the two drivers used for one device?
cdc_ether.c is being used both as a driver and a library? The
EXPORT_SYMBOL_GPL() make this clear, a driver would normally not need
exports. The patchset starts to make cdc_ether.c a pure driver, moving
some of the shared code into the usbnet library.
Just to be clear, i think what you are doing is correct, i just had
problems understanding the commit message.
Andrew
^ permalink raw reply
* [PATCH] net: qed: Fix spelling typo in qed_dcbx.c comment
From: Praveen Rajendran @ 2026-07-03 14:31 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni
Cc: netdev, linux-kernel, Praveen Rajendran
Correct a minor spelling error inside a comment block of the QLogic
Core module where "successfully" was misspelled as "successfuly".
Signed-off-by: Praveen Rajendran <praveenrajendran2009@gmail.com>
---
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
index 3a5c25026858..19c2b870feed 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dcbx.c
@@ -639,7 +639,7 @@ qed_dcbx_get_operational_params(struct qed_hwfn *p_hwfn,
flags = p_hwfn->p_dcbx_info->operational.flags;
/* If DCBx version is non zero, then negotiation
- * was successfuly performed
+ * was successfully performed
*/
p_operational = ¶ms->operational;
enabled = !!(QED_MFW_GET_FIELD(flags, DCBX_CONFIG_VERSION) !=
--
2.50.1
^ permalink raw reply related
* [PATCH ipsec] xfrm: espintcp: fix UAF during close
From: Sabrina Dubroca @ 2026-07-03 14:21 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Herbert Xu, Sabrina Dubroca, stable,
zdi-disclosures
ZDI reported and analyzed a race condition during close for espintcp
sockets:
espintcp_close() frees emsg->skb via kfree_skb() without holding
any socket lock. Concurrently, the xfrm_trans_reinject work queue
invokes esp_output_tcp_finish() -> espintcp_push_skb() ->
espintcp_push_msgs() -> skb_send_sock_locked(), which reads the
same skb as a data source.
Fix this by adding a synchronize_rcu() call after resetting sk_prot,
since esp_output_tcp_finish() runs under RCU and won't use a socket
with sk_prot == &tcp_prot. Simply taking the socket lock in
espintcp_close() could lead to leaks, if esp_output_tcp_finish()
re-adds an skb in the slot we just freed.
Cc: stable@vger.kernel.org
Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
Reported-by: zdi-disclosures@trendmicro.com
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
net/xfrm/espintcp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/xfrm/espintcp.c b/net/xfrm/espintcp.c
index 374e1b964438..f09b5dd85db8 100644
--- a/net/xfrm/espintcp.c
+++ b/net/xfrm/espintcp.c
@@ -517,6 +517,8 @@ static void espintcp_close(struct sock *sk, long timeout)
sk->sk_prot = &tcp_prot;
barrier();
+ synchronize_rcu();
+
disable_work_sync(&ctx->work);
strp_done(&ctx->strp);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net v2] mac802154: remove interfaces with RCU list deletion
From: patchwork-bot+netdevbpf @ 2026-07-03 14:20 UTC (permalink / raw)
To: Yousef Alhouseen
Cc: alex.aring, stefan, miquel.raynal, davem, edumazet, kuba, pabeni,
horms, marcel, kuniyu, linux-wpan, netdev, linux-kernel, stable,
syzbot+36256deb69a588e9290e
In-Reply-To: <20260701164222.9094-1-alhouseenyousef@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 1 Jul 2026 18:42:22 +0200 you wrote:
> Queue wake, stop, and disable paths walk local->interfaces under RCU.
> The bulk hardware teardown path removes entries with list_del(), so an
> asynchronous transmit completion can follow a poisoned list node in
> ieee802154_wake_queue().
>
> Use list_del_rcu() as in the single-interface removal path. The following
> unregister_netdevice() waits for in-flight RCU readers before freeing the
> netdevice, so no separate grace-period wait is needed.
>
> [...]
Here is the summary with links:
- [net,v2] mac802154: remove interfaces with RCU list deletion
https://git.kernel.org/netdev/net/c/539dfcf69105
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Michael S. Tsirkin @ 2026-07-03 14:19 UTC (permalink / raw)
To: Brett Sheffield
Cc: Simon Schippers, regressions, netdev, Jakub Kicinski, Tim Gebauer,
Willem de Bruijn, Jason Wang, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel
In-Reply-To: <akfDnfkgorxJ_Q6G@karahi.librecast.net>
On Fri, Jul 03, 2026 at 04:13:49PM +0200, Brett Sheffield wrote:
> On 2026-07-02 18:55, Michael S. Tsirkin wrote:
> > On Thu, Jul 02, 2026 at 01:07:47PM +0200, Brett Sheffield wrote:
> > > On 2026-07-02 09:24, Simon Schippers wrote:
> > > > On 7/1/26 22:56, Michael S. Tsirkin wrote:
> > > > > - does it help to increase the tun queue size?
> > > >
> > > > I agree, this would be great to know.
>
> I tried adding a queue (qdisc pfifo limit 500) on both host and guest - no
> apparent difference in drops or performance.
>
> If there's any other setting you want me to try, let me know.
>
> > Maybe it's the supposedly rare case? Does this change anything
> > for you?
>
> I also tried both patches, but again, no noticable difference.
>
Thank you. Simon pointed out issues with the patches but he also said his
intuition is strongly that it's not the way to go.
Let's wait for him to post the backpressure patch, we'll see.
--
MST
^ permalink raw reply
* [RESEND PATCH] net/mlx5: Fix L3 tunnel entropy refcount leak
From: lirongqing @ 2026-07-03 14:14 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Li RongQing, Simon Horman, Eli Britstein, Roi Dayan,
Eli Cohen, netdev, linux-rdma, linux-kernel
From: Li RongQing <lirongqing@baidu.com>
mlx5_tun_entropy_refcount_inc() counts both VXLAN and L2-to-L3
tunnel reformat entries as entropy-enabling users. The matching
decrement path only handled VXLAN, leaving L2-to-L3 tunnel entries
counted after release.
Handle MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL in
mlx5_tun_entropy_refcount_dec() as well so the enabling entry
refcount remains balanced.
Fixes: f828ca6a2fb6 ("net/mlx5e: Add support for hw encapsulation of MPLS over UDP")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c
index 4571c56..97f6097 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/port_tun.c
@@ -176,7 +176,8 @@ void mlx5_tun_entropy_refcount_dec(struct mlx5_tun_entropy *tun_entropy,
int reformat_type)
{
mutex_lock(&tun_entropy->lock);
- if (reformat_type == MLX5_REFORMAT_TYPE_L2_TO_VXLAN)
+ if (reformat_type == MLX5_REFORMAT_TYPE_L2_TO_VXLAN ||
+ reformat_type == MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL)
tun_entropy->num_enabling_entries--;
else if (reformat_type == MLX5_REFORMAT_TYPE_L2_TO_NVGRE &&
--tun_entropy->num_disabling_entries == 0)
--
2.9.4
^ permalink raw reply related
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Brett Sheffield @ 2026-07-03 14:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Schippers, regressions, netdev, Jakub Kicinski, Tim Gebauer,
Willem de Bruijn, Jason Wang, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel
In-Reply-To: <20260702185420-mutt-send-email-mst@kernel.org>
On 2026-07-02 18:55, Michael S. Tsirkin wrote:
> On Thu, Jul 02, 2026 at 01:07:47PM +0200, Brett Sheffield wrote:
> > On 2026-07-02 09:24, Simon Schippers wrote:
> > > On 7/1/26 22:56, Michael S. Tsirkin wrote:
> > > > - does it help to increase the tun queue size?
> > >
> > > I agree, this would be great to know.
I tried adding a queue (qdisc pfifo limit 500) on both host and guest - no
apparent difference in drops or performance.
If there's any other setting you want me to try, let me know.
> Maybe it's the supposedly rare case? Does this change anything
> for you?
I also tried both patches, but again, no noticable difference.
--
Brett Sheffield (he/him)
Librecast - Decentralising the Internet with Multicast
https://librecast.net/
https://blog.brettsheffield.com/
^ permalink raw reply
* Re: [PATCH net] bnx2x: fix null pointer dereference in bnx2x_free_mem_bp()
From: Paolo Abeni @ 2026-07-03 14:12 UTC (permalink / raw)
To: Abdun Nihaal, skalluru
Cc: manishc, andrew+netdev, davem, edumazet, kuba, netdev,
linux-kernel, horms, stable
In-Reply-To: <20260701065030.381836-1-nihaal@cse.iitm.ac.in>
On 7/1/26 8:50 AM, Abdun Nihaal wrote:
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> index 5b2640bd31c3..25ee45cb7f3f 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> @@ -4712,8 +4712,9 @@ void bnx2x_free_mem_bp(struct bnx2x *bp)
> {
> int i;
>
> - for (i = 0; i < bp->fp_array_size; i++)
> - kfree(bp->fp[i].tpa_info);
> + if (bp->fp)
> + for (i = 0; i < bp->fp_array_size; i++)
> + kfree(bp->fp[i].tpa_info);
I think that a cleaner fix would be moving bp->fp_array_size
initialization after bp->fp.
/P
^ permalink raw reply
* [PATCH nf-next v4 6/6] selftests: netfilter: nft_flowtable.sh: Add SIT flowtable selftest
From: Lorenzo Bianconi @ 2026-07-03 14:10 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, David Ahern,
Ido Schimmel, Pablo Neira Ayuso, Florian Westphal, Phil Sutter,
Shuah Khan, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev, netfilter-devel,
coreteam, linux-kselftest
In-Reply-To: <20260703-b4-flowtable-sw-accel-ip6ip-v4-0-00398cd12382@kernel.org>
Similar to IPIP, IP6IP6 and IPv4 over IPv6, introduce specific selftest
for SIT flowtable sw acceleration in nft_flowtable.sh
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
tools/testing/selftests/net/netfilter/config | 1 +
.../selftests/net/netfilter/nft_flowtable.sh | 45 ++++++++++++++++++++++
2 files changed, 46 insertions(+)
diff --git a/tools/testing/selftests/net/netfilter/config b/tools/testing/selftests/net/netfilter/config
index c3c121b6f300..a212b9edbcd9 100644
--- a/tools/testing/selftests/net/netfilter/config
+++ b/tools/testing/selftests/net/netfilter/config
@@ -35,6 +35,7 @@ CONFIG_IP_SCTP=m
CONFIG_IPV6=y
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_TUNNEL=m
+CONFIG_IPV6_SIT=m
CONFIG_IP_VS=m
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_RR=m
diff --git a/tools/testing/selftests/net/netfilter/nft_flowtable.sh b/tools/testing/selftests/net/netfilter/nft_flowtable.sh
index b14c80c6e372..46bd080108be 100755
--- a/tools/testing/selftests/net/netfilter/nft_flowtable.sh
+++ b/tools/testing/selftests/net/netfilter/nft_flowtable.sh
@@ -597,6 +597,10 @@ ip -net "$nsr1" addr add 192.168.210.1/24 dev tun6
ip -net "$nsr1" addr add fee1:3::1/64 dev tun6 nodad
ip netns exec "$nsr1" sysctl net.ipv4.conf.tun6.forwarding=1 > /dev/null
+ip -net "$nsr1" link add name sit1 type sit local 192.168.10.1 remote 192.168.10.2 ttl 255
+ip -net "$nsr1" link set sit1 up
+ip -net "$nsr1" addr add fe01:3::1/64 dev sit1 nodad
+
ip -net "$nsr2" link add name tun0 type ipip local 192.168.10.2 remote 192.168.10.1
ip -net "$nsr2" link set tun0 up
ip -net "$nsr2" addr add 192.168.100.2/24 dev tun0
@@ -608,6 +612,10 @@ ip -net "$nsr2" addr add 192.168.210.2/24 dev tun6
ip -net "$nsr2" addr add fee1:3::2/64 dev tun6 nodad
ip netns exec "$nsr2" sysctl net.ipv4.conf.tun6.forwarding=1 > /dev/null
+ip -net "$nsr2" link add name sit1 type sit local 192.168.10.2 remote 192.168.10.1 ttl 255
+ip -net "$nsr2" link set sit1 up
+ip -net "$nsr2" addr add fe01:3::2/64 dev sit1 nodad
+
ip -net "$nsr1" route change default via 192.168.100.2
ip -net "$nsr2" route change default via 192.168.100.1
@@ -622,6 +630,7 @@ ip -6 -net "$ns2" route add default via dead:2::1
ip netns exec "$nsr1" nft -a insert rule inet filter forward 'meta oif tun0 accept'
ip netns exec "$nsr1" nft -a insert rule inet filter forward 'meta oif tun6 accept'
+ip netns exec "$nsr1" nft -a insert rule inet filter forward 'meta oif sit1 accept'
ip netns exec "$nsr1" nft -a insert rule inet filter forward \
'meta oif "veth0" tcp sport 12345 ct mark set 1 flow add @f1 counter name routed_repl accept'
@@ -648,6 +657,19 @@ if ! test_tcp_forwarding_nat "$ns1" "$ns2" 1 "IP4IP6 tunnel"; then
ret=1
fi
+ip -6 -net "$nsr1" route delete default
+ip -6 -net "$nsr1" route add default via fe01:3::2
+ip -6 -net "$nsr2" route delete default
+ip -6 -net "$nsr2" route add default via fe01:3::1
+
+if test_tcp_forwarding "$ns1" "$ns2" 1 6 "[dead:2::99]" 12345; then
+ echo "PASS: flow offload for ns1/ns2 SIT tunnel"
+else
+ echo "FAIL: flow offload for ns1/ns2 with SIT tunnel" 1>&2
+ ip netns exec "$nsr1" nft list ruleset
+ ret=1
+fi
+
# Create vlan tagged devices for IPIP traffic.
ip -net "$nsr1" link add link veth1 name veth1.10 type vlan id 10
ip -net "$nsr1" link set veth1.10 up
@@ -672,6 +694,11 @@ ip -6 -net "$nsr1" route delete default
ip -6 -net "$nsr1" route add default via fee1:5::2
ip netns exec "$nsr1" nft -a insert rule inet filter forward 'meta oif tun6.10 accept'
+ip -net "$nsr1" link add name sit1.10 type sit local 192.168.20.1 remote 192.168.20.2 ttl 255
+ip -net "$nsr1" link set sit1.10 up
+ip -net "$nsr1" addr add fe01:5::1/64 dev sit1.10 nodad
+ip netns exec "$nsr1" nft -a insert rule inet filter forward 'meta oif sit1.10 accept'
+
ip -net "$nsr2" link add link veth0 name veth0.10 type vlan id 10
ip -net "$nsr2" link set veth0.10 up
ip -net "$nsr2" addr add 192.168.20.2/24 dev veth0.10
@@ -689,6 +716,11 @@ ip -net "$nsr2" link set tun6.10 up
ip -net "$nsr2" addr add 192.168.220.2/24 dev tun6.10
ip -net "$nsr2" addr add fee1:5::2/64 dev tun6.10 nodad
ip netns exec "$nsr2" sysctl net.ipv4.conf.tun6/10.forwarding=1 > /dev/null
+
+ip -net "$nsr2" link add name sit1.10 type sit local 192.168.20.2 remote 192.168.20.1 ttl 255
+ip -net "$nsr2" link set sit1.10 up
+ip -net "$nsr2" addr add fe01:5::2/64 dev sit1.10 nodad
+
ip -6 -net "$nsr2" route delete default
ip -6 -net "$nsr2" route add default via fee1:5::1
@@ -715,6 +747,19 @@ if ! test_tcp_forwarding_nat "$ns1" "$ns2" 1 "IP4IP6 tunnel over vlan"; then
ret=1
fi
+ip -6 -net "$nsr1" route delete default
+ip -6 -net "$nsr1" route add default via fe01:5::2
+ip -6 -net "$nsr2" route delete default
+ip -6 -net "$nsr2" route add default via fe01:5::1
+
+if test_tcp_forwarding "$ns1" "$ns2" 1 6 "[dead:2::99]" 12345; then
+ echo "PASS: flow offload for ns1/ns2 SIT tunnel over vlan"
+else
+ echo "FAIL: flow offload for ns1/ns2 with SIT tunnel over vlan" 1>&2
+ ip netns exec "$nsr1" nft list ruleset
+ ret=1
+fi
+
# Restore the previous configuration
ip -net "$nsr1" route change default via 192.168.10.2
ip -net "$nsr2" route change default via 192.168.10.1
--
2.55.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