* Re: [PATCH net-next 0/2] net: remove the orphaned IBM eHEA driver
From: patchwork-bot+netdevbpf @ 2026-07-02 8:50 UTC (permalink / raw)
To: David Christensen
Cc: davem, edumazet, kuba, pabeni, mpe, npiggin, christophe.leroy,
netdev, linuxppc-dev, linux-kernel
In-Reply-To: <20260629211343.3712775-1-drc@linux.ibm.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 29 Jun 2026 16:13:41 -0500 you wrote:
> The IBM eHEA (Ethernet Host Ethernet Adapter) driver has been orphaned
> since April 2024 with no active maintainer stepping forward. This series
> removes the driver and associated references from the kernel tree.
>
> The driver was marked as an Orphan on April 18, 2024:
>
> commit 97ec32b583bb ("MAINTAINERS: eth: mark IBM eHEA as an Orphan")
>
> [...]
Here is the summary with links:
- [net-next,1/2] ehea: remove the ehea driver
https://git.kernel.org/netdev/net-next/c/eb56577ae9a5
- [net-next,2/2] powerpc: remove ehea driver references
https://git.kernel.org/netdev/net-next/c/4bbb6f594070
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3 2/3] ptp: Add driver for R-Car Gen4
From: Niklas Söderlund @ 2026-07-02 8:46 UTC (permalink / raw)
To: Vadim Fedorenko
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-renesas-soc, devicetree, linux-kernel, netdev
In-Reply-To: <89720193-e8ad-4bb3-b6d2-3253413b18ab@linux.dev>
Hi Vadim,
Thanks for your feedback.
On 2026-07-01 22:47:16 +0100, Vadim Fedorenko wrote:
> On 01/07/2026 10:06, Niklas Söderlund wrote:
> > Add driver for the gPTP timer found on R-Car Gen4 devices. The timer is
> > system-wide and shared by different Ethernet devices on each Gen4
> > platform. The operation of the timer is however not completely in
> > depended of the systems Ethernet devices.
> >
> > - On R-Car S4 is gated by the RSWITCH Ethernet module clock.
> >
> > - On R-Car V4H is gated by the RTSN Ethernet module clock.
> >
> > - On R-Car V4M is gated by its own module clock, the system have
> > neither RTSN or RSWITCH device. But the module clock is the same as
> > RTSN on V4H and the documentation referees to it as tsn (EtherTSN).
> >
> > The gPTP device do have its own register space on all three platforms.
> > But on S4 and V4H it will share its clock and reset property with
> > RSWITCH or RTSN, respectively.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> [...]
>
> > +static int ptp_rcar_gen4_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> > +{
> > + struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
> > + s64 addend = priv->default_addend;
> > + bool neg_adj = scaled_ppm < 0;
> > + unsigned long flags;
> > + s64 diff;
> > +
> > + if (neg_adj)
> > + scaled_ppm = -scaled_ppm;
> > + diff = div_s64(addend * scaled_ppm_to_ppb(scaled_ppm), NSEC_PER_SEC);
> > + addend = neg_adj ? addend - diff : addend + diff;
> > +
> > + spin_lock_irqsave(&priv->lock, flags);
> > + iowrite32(addend, priv->base + PTPTIVC0_REG);
>
> how are you so sure that addend will always fit into s32? It looks like
> it may go over in some cases, no?
Indeed, if the adjustment is more then 32ns per tick it will go over.
The register is defined as,
/* Default timer increment in ns.
* bit[31:27] - integer
* bit[26:0] - decimal
I will add a check for this clamping the value before writing it to the
register.
>
> > + spin_unlock_irqrestore(&priv->lock, flags);
> > +
> > + return 0;
> > +}
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH net-next 01/15] batman-adv: create hardif only for netdevs that are part of a mesh
From: patchwork-bot+netdevbpf @ 2026-07-02 8:40 UTC (permalink / raw)
To: Simon Wunderlich
Cc: netdev, davem, edumazet, kuba, pabeni, horms, b.a.t.m.a.n,
neocturne, sven
In-Reply-To: <20260630140623.88431-2-sw@simonwunderlich.de>
Hello:
This series was applied to netdev/net-next.git (main)
by Sven Eckelmann <sven@narfation.org>:
On Tue, 30 Jun 2026 16:06:09 +0200 you wrote:
> From: Nora Schiffer <neocturne@universe-factory.net>
>
> batman-adv is using netdev notifiers to create a hard_iface struct for
> every Ethernet-like netdev in the system. These hardifs are tracked in a
> global linked list, which results in a few performance issues:
>
> Lookups in this list are O(n) in the total number of netdevs. As a
> hardif is looked up when a netdev is removed, this also takes O(n) in
> the number of netdevs, and removing n netdevs may take O(n^2). This
> slowdown will always happen when the batman-adv module is loaded, no
> mesh needs to be active.
>
> [...]
Here is the summary with links:
- [net-next,01/15] batman-adv: create hardif only for netdevs that are part of a mesh
https://git.kernel.org/netdev/net-next/c/fcba102e0e4a
- [net-next,02/15] batman-adv: remove global hardif list
https://git.kernel.org/netdev/net-next/c/49e9de6e124f
- [net-next,03/15] batman-adv: make hard_iface->mesh_iface immutable
https://git.kernel.org/netdev/net-next/c/f846e779532e
- [net-next,04/15] batman-adv: remove BATADV_IF_NOT_IN_USE hardif state
https://git.kernel.org/netdev/net-next/c/48ea7b6b7b94
- [net-next,05/15] batman-adv: move hardif generation counter into batadv_priv
https://git.kernel.org/netdev/net-next/c/cbda6a6cf2a5
- [net-next,06/15] batman-adv: drop unneeded goto and initialization from batadv_hardif_disable_interface()
https://git.kernel.org/netdev/net-next/c/2b429dbc50b4
- [net-next,07/15] batman-adv: drop NULL check for immutable hardif->mesh_iface
https://git.kernel.org/netdev/net-next/c/b58c36b804f4
- [net-next,08/15] Revert "batman-adv: v: stop OGMv2 on disabled interface"
https://git.kernel.org/netdev/net-next/c/5fa5f64fc018
- [net-next,09/15] batman-adv: iv: drop migration check for batadv_hard_iface
https://git.kernel.org/netdev/net-next/c/ba2d97e8736e
- [net-next,10/15] batman-adv: tvlv: extract tvlv header iterator
https://git.kernel.org/netdev/net-next/c/278e5890704c
- [net-next,11/15] batman-adv: tp_meter: simplify unordered ack calculation
https://git.kernel.org/netdev/net-next/c/71b7987ec001
- [net-next,12/15] batman-adv: tp_meter: combine adjacent/overlapping unacked entries
https://git.kernel.org/netdev/net-next/c/936a1c10cece
- [net-next,13/15] batman-adv: tp_meter: keep unacked list for receivers
https://git.kernel.org/netdev/net-next/c/3bbb8b94217a
- [net-next,14/15] batman-adv: tp_meter: adjust name of receiver lock
https://git.kernel.org/netdev/net-next/c/6cd45ef4dfa5
- [net-next,15/15] batman-adv: tp_meter: delay allocation of unacked entry
https://git.kernel.org/netdev/net-next/c/247691642fd4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/6] batman-adv: retrieve ethhdr after potential skb realloc on RX
From: patchwork-bot+netdevbpf @ 2026-07-02 8:40 UTC (permalink / raw)
To: Simon Wunderlich
Cc: netdev, davem, edumazet, kuba, pabeni, horms, b.a.t.m.a.n, sven,
stable, sashiko-bot
In-Reply-To: <20260630134430.85786-2-sw@simonwunderlich.de>
Hello:
This series was applied to netdev/net.git (main)
by Sven Eckelmann <sven@narfation.org>:
On Tue, 30 Jun 2026 15:44:25 +0200 you wrote:
> From: Sven Eckelmann <sven@narfation.org>
>
> pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind
> the skb. Variables which were pointing to the old buffer need to be
> reassigned to avoid an use-after-free.
>
> This was done correctly for the VLAN header but missed for the ethernet
> header which is later used for the TT and AP isolation handling.
>
> [...]
Here is the summary with links:
- [net,1/6] batman-adv: retrieve ethhdr after potential skb realloc on RX
https://git.kernel.org/netdev/net/c/035e1fed892d
- [net,2/6] batman-adv: access unicast_ttvn skb->data only after skb realloc
https://git.kernel.org/netdev/net/c/7141990add3f
- [net,3/6] batman-adv: gw: acquire ethernet header only after skb realloc
https://git.kernel.org/netdev/net/c/77880a3be88d
- [net,4/6] batman-adv: dat: acquire ARP hw source only after skb realloc
https://git.kernel.org/netdev/net/c/48067b2ae450
- [net,5/6] batman-adv: bla: reacquire gw address after skb realloc
https://git.kernel.org/netdev/net/c/cdf3b5af2bc4
- [net,6/6] batman-adv: dat: ensure accessible eth_hdr proto field
https://git.kernel.org/netdev/net/c/26560c4a03dc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] selftests: drv-net: toeplitz: cap the Rx queue count
From: patchwork-bot+netdevbpf @ 2026-07-02 8:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
willemb, noren, gal, linux-kselftest
In-Reply-To: <20260629234354.2154541-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 29 Jun 2026 16:43:53 -0700 you wrote:
> The RPS test needs a free CPU within the first RPS_MAX_CPUS (16)
> cores. This is easily violated if the NIC or env allocates the
> IRQs to cores linearly.
>
> Cap the Rx queues at 8, we don't need more. This makes the test
> pass on CX7 in NIPA.
>
> [...]
Here is the summary with links:
- [net-next] selftests: drv-net: toeplitz: cap the Rx queue count
https://git.kernel.org/netdev/net-next/c/07d3aaa046ce
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v3 2/7] net: wwan: t9xx: Add control plane transaction layer
From: Wu. JackBB (GSM) @ 2026-07-02 8:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <92b1e341-31a1-4f60-80d5-ccf8f742a38a@lunn.ch>
Hi Andrew,
> > mtk_dev_alloc/mtk_dev_free are paired wrappers so the caller
> > doesn't need to know the underlying allocation mechanism.
> > The devm_kfree is still called inside mtk_dev_free.
>
> Two different issues here:
>
> 1) If you don't want to use devm_, don't use devm_ from the
> beginning. A patch should not change how a previous patch works, since
> you are wasting reviewer time reviewing code which you later change.
>
> 2) Do you understand what devm_ actually does? Since you use
> devm_free() i don't think you actually understand what devm_ is all
> about.
Thank you for the explanation. You are right.
we will remove the mtk_dev_alloc/mtk_dev_free wrappers and use
devm_kzalloc directly from the beginning.
We will also remove all unnecessary devm_kfree() calls from probe
error paths and remove paths, keeping them only where resources
are freed and re-allocated at runtime (e.g., CLDMA queue lifecycle
during modem reset cycles).
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH net] net/smc: avoid recursive sk_callback_lock in listen data_ready
From: Runyu Xiao @ 2026-07-02 7:51 UTC (permalink / raw)
To: Sidraya Jayagond
Cc: D. Wythe, Dust Li, Wenjia Zhang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Mahanta Jambigi, Tony Lu, Wen Gu,
Simon Horman, Karsten Graul, linux-rdma, linux-s390, netdev,
linux-kernel, jianhao.xu
In-Reply-To: <17c1cbac-de30-4372-8c24-2acd755f503e@linux.ibm.com>
Hi Sidraya,
On Thu, Jun 25, 2026 at 02:02:25PM +0530, Sidraya Jayagond wrote:
> In smc_close_active(), the TCP socket remains in TCP_LISTEN state while
> holding write_lock_bh(&smc->clcsock->sk->sk_callback_lock);. The patch's
> state check would pass during this window, not preventing the recursive
> lock scenario.
> It's unclear whether it fully prevents the recursive locking scenario
> described in the commit message for the specific code path in
> smc_close_active().
> Could you come up with exact deadlock scenario and how the patch
> addresses it?
You are right. I do not have a confirmed current mainline call chain where
the callback is invoked under sk_callback_lock, and the TCP_LISTEN check
does not cover the smc_close_active() window you pointed out.
I will drop this patch for now. Thanks for reviewing it.
Runyu
^ permalink raw reply
* Re: [PATCH net-next] net: phylink: Drop references to the .validate() method in comments
From: patchwork-bot+netdevbpf @ 2026-07-02 8:20 UTC (permalink / raw)
To: Maxime Chevallier
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux, hkallweit1,
netdev, linux-kernel, thomas.petazzoni
In-Reply-To: <20260630083700.2041915-1-maxime.chevallier@bootlin.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 30 Jun 2026 10:37:00 +0200 you wrote:
> The phylink_mac_ops '.validate()' has been removed in:
>
> commit da5f6b80ad64 ("net: phylink: remove .validate() method")
>
> There are still a few comments around in phylink that references that,
> related to the ports fields as well as the Pause configuration. Let's
> drop these references and update the comments related to Pause handling.
>
> [...]
Here is the summary with links:
- [net-next] net: phylink: Drop references to the .validate() method in comments
https://git.kernel.org/netdev/net-next/c/7693eadcbb8c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Qingfang Deng @ 2026-07-02 8:19 UTC (permalink / raw)
To: Norbert Szetei
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Sebastian Andrzej Siewior, Breno Leitao, Taegu Ha,
Kees Cook, linux-ppp, linux-kernel, Guillaume Nault, netdev
In-Reply-To: <D9C0245B-608B-4884-8A09-F55BA4A9F948@doyensec.com>
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)
>
> 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 v2 2/2] pds_core: fix use-after-free on workqueue during remove
From: Paolo Abeni @ 2026-07-02 8:13 UTC (permalink / raw)
To: Nikhil P. Rao, netdev
Cc: kuba, brett.creeley, eric.joyner, andrew+netdev, davem, edumazet
In-Reply-To: <20260629200358.2626129-3-nikhil.rao@amd.com>
On 6/29/26 10:03 PM, Nikhil P. Rao wrote:
> In pdsc_remove(), the workqueue is destroyed before pdsc_teardown()
> is called. This ordering allows two paths to queue work on the
> destroyed workqueue:
>
> 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error
> path in pdsc_devcmd_locked() queues health_work.
>
> 2. A NotifyQ event can trigger the ISR and queue work before free_irq()
> is called in pdsc_teardown().
I think this should be 2 separate patches.
> @@ -121,10 +122,16 @@ void pdsc_process_adminq(struct pdsc_qcq *qcq)
> qcq->accum_work += aq_work;
>
> credits:
> - /* Return the interrupt credits, one for each completion */
> - pds_core_intr_credits(&pdsc->intr_ctrl[qcq->intx],
> - nq_work + aq_work,
> - PDS_CORE_INTR_CRED_REARM);
> + /* Return the interrupt credits, one for each completion.
> + * Use READ_ONCE to get a single consistent copy of intx since it can
> + * be set to PDS_CORE_INTR_INDEX_NOT_ASSIGNED concurrently during
> + * teardown, and skip the credits if so.
> + */
> + intx = READ_ONCE(qcq->intx);
> + if (intx != PDS_CORE_INTR_INDEX_NOT_ASSIGNED)
> + pds_core_intr_credits(&pdsc->intr_ctrl[intx],
> + nq_work + aq_work,
> + PDS_CORE_INTR_CRED_REARM);
AFAICS this does not look safe.
A concurrent pdsc_qcq_free()/pdsc_qcq_intr_free() may free
`pdsc->intr_ctrl` before setting PDS_CORE_INTR_INDEX_NOT_ASSIGNED.
I think the teardown should:
- disable the IRQ
- cancel the work
- free the structs
in the above sequence.
/P
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: ipv6: report multicast group user count
From: Ido Schimmel @ 2026-07-02 8:12 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Andrew Lunn, David Ahern, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Shuah Khan,
Simon Horman, linux-kernel, linux-kselftest, netdev
In-Reply-To: <20260630110207.37841-3-sigefriedhyy@gmail.com>
On Tue, Jun 30, 2026 at 08:02:06PM +0900, Yuyang Huang wrote:
> The previous patch added IFA_MC_USERS and emits it for IPv4 multicast
> groups. Add the same snapshot attribute to IPv6 RTM_GETMULTICAST
> replies and entry-lifecycle notifications, carrying
> ifmcaddr6::mca_users.
>
> This makes the multicast rtnetlink ABI symmetric across IPv4 and IPv6
> and gives userspace the same user count that /proc/net/igmp6 exposes.
>
> Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: ipv4: report multicast group user count
From: Ido Schimmel @ 2026-07-02 8:11 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Andrew Lunn, David Ahern, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Shuah Khan,
Simon Horman, linux-kernel, linux-kselftest, netdev
In-Reply-To: <20260630110207.37841-2-sigefriedhyy@gmail.com>
On Tue, Jun 30, 2026 at 08:02:05PM +0900, Yuyang Huang wrote:
> RTM_GETMULTICAST has been part of the rtnetlink ABI for a long time
> and already reports IPv4 multicast group membership through
> IFA_MULTICAST and IFA_CACHEINFO. It does not report how many consumers
> hold each membership, so userspace still has to parse /proc/net/igmp to
> get the Users column.
>
> Add IFA_MC_USERS as a u32 attribute carrying ip_mc_list::users in
> RTM_GETMULTICAST replies and entry-lifecycle notifications.
>
> This gives iproute2 enough information to migrate the IPv4 part of
> "ip maddr show" from procfs parsing to rtnetlink.
>
> Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Simon Schippers @ 2026-07-02 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Brett Sheffield, 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: <20260702034152-mutt-send-email-mst@kernel.org>
On 7/2/26 09:42, Michael S. Tsirkin wrote:
> On Thu, Jul 02, 2026 at 09:24:59AM +0200, Simon Schippers wrote:
>> On 7/1/26 22:56, Michael S. Tsirkin wrote:
>>> On Wed, Jul 01, 2026 at 09:16:48PM +0200, Brett Sheffield wrote:
>>>> TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
>>>> significant performance regressions with TAP interfaces and multithreaded
>>>> network code. Please revert.
>>>>
>>>>
>>>> Librecast is an IPv6 multicast library. One of the tests (0055) fails under
>>>> Linux 7.2-rc1. The test performs data synchronization over IPv6 multicast using a TAP
>>>> interface. This test has run successfully on every stable, LTS and mainline RC
>>>> released in the past year. Every kernel with my Tested-by has run this test.
>>>>
>>>> There have been a bunch of changes to MLDv2 so I started bisecting there, but
>>>> the culprit is actually 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 "tun/tap &
>>>> vhost-net: avoid ptr_ring tail-drop when a qdisc is present"
>>>>
>>>> Reverting this commit fixes the test.
>>>>
>>>> To eliminate my code and any multicast weirdness, I ran tests with iperf3
>>>> comparing the same host running 7.2-rc1 both with and without 1d6e569b7d0
>>>> reverted.
>>
>> Thank you very much for your bisect!
>>
>> As the author, I am sorry for that regression!
>>
>>>
>>> Thanks a lot for the bisect! Reverting is not out of question, but
>>> just before we do, it is worth analyzing the situation.
>>>
>>> Could you pls tell us
>>> - do you see packet drops?
>>
>> iperf3 shows no TCP retransmissions, so there were never packet drops
>> when the patch was enabled.
>> It is the number after the sender data rate (example: threads 1,
>> reverted has 368 retransmissions/drops).
>>
>>> - does it help to increase the tun queue size?
>>
>> I agree, this would be great to know.
>>
>> However, even then we must act. I am considering IFF_BACKPRESSURE
>> as a feature flag, defaulting to off. It would just enable/disable
>> the stopping logic in tun_net_xmit() and the waking logic
>> in __tun_wake_queue(). If disabled, it would result in the same logic
>> as before.
>>
>> I could provide such a patch as [net] material.
>>
>> Thanks again!
>
> Or BQL? I quickly wrote a prototype of that and it seems to work well -
> could you help test maybe?
BQL won't fix it I think.
A bigger TUN queue would probably fix it but BQL can only just adjust
to a smaller queue than 500 packets.
Unless you don't take the ptr_ring size as an upper limit for BQL and
resize the ptr_ring on the fly? I don't think this is viable.
I am currently working with others to get BQL working for veth.
TLDR: The issue with software interfaces is that there is no *periodic*
completion process [2]. For hardware there is.
I applied the same veth approach for TUN and it showed to fix
bufferbloat... But again won't fix the issue here I think.
[1] Link: https://lore.kernel.org/netdev/20260612083530.1650245-1-hawk@kernel.org/T/#u
[2] Link: https://lwn.net/Articles/469651/
>
>
>>>
>>> Thanks a lot!
>>>
>>>
>>>> CPU: AMD Ryzen 9 9950X
This processor has 2 CCDs. This probably makes the issue worse then it
was for me. My (older) Ryzen 5 5600X only has a single CCD.
Thanks.
>>>>
>>>> [ host ] - [ bridge ] - [ tap ] - [ guest (qemu) ]
>>>>
>>>> Running matching kernels on host and guest, I started iperf3 in server mode on
>>>> the guest and tested from the host so traffic passes through the tap interface.
>>>>
>>>> iperf3 -s -V # server
>>>> iperf3 -c guest -P nthreads # client
>>>>
>>>> 7.2.0-rc1 (threads 1):
>>>>
>>>> [ 5] 0.00-10.00 sec 20.2 GBytes 17.4 Gbits/sec 0 sender
>>>> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 1, reverted):
>>>>
>>>> [ 5] 0.00-10.00 sec 15.3 GBytes 13.1 Gbits/sec 368 sender
>>>> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 2):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 2, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 15.9 GBytes 13.7 Gbits/sec 1567 sender
>>>> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 4):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 4, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 16.5 GBytes 14.1 Gbits/sec 6701 sender
>>>> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 8):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.7 GBytes 9.15 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.01 sec 10.6 GBytes 9.13 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 8, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 16.2 GBytes 14.0 Gbits/sec 19319 sender
>>>> [SUM] 0.00-10.00 sec 15.7 GBytes 13.5 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 16):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.35 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.01 sec 10.9 GBytes 9.32 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 16, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec 43593 sender
>>>> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec receiver
>>>>
>>>>
>>>> As you can see, the new code works for single threaded, but for all other cases
>>>> there's a significant performance drop. I see this trade-off is mentioned in the
>>>> commit, but the performance drop off is much worse than suggested with the
>>>> current patch.
>>>>
>>>> In our multicast use case data is sent by multiple threads to multiple groups
>>>> simultaneously, this just breaks things to the extent that a <2 second test
>>>> times out after 5 minutes.
>>>>
>>>>
>>>> git bisect start
>>>> # status: waiting for both good and bad commits
>>>> # bad: [dc59e4fea9d83f03bad6bddf3fa2e52491777482] Linux 7.2-rc1
>>>> git bisect bad dc59e4fea9d83f03bad6bddf3fa2e52491777482
>>>> # status: waiting for good commit(s), bad commit known
>>>> # good: [36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
>>>> git bisect good 36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1
>>>> # good: [db314398f618a3a23315f73c87f7d318eaf06c1b] Merge branch 'net-bridge-mcast-support-exponential-field-encoding'
>>>> git bisect good db314398f618a3a23315f73c87f7d318eaf06c1b
>>>> # bad: [079a028d6327e68cfa5d38b36123637b321c19a7] string: Remove strncpy() from the kernel
>>>> git bisect bad 079a028d6327e68cfa5d38b36123637b321c19a7
>>>> # bad: [f396f4005180928cd9e15e352a6512865d3bc908] Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
>>>> git bisect bad f396f4005180928cd9e15e352a6512865d3bc908
>>>> # bad: [ec1806a730a1c0b3d68a7f9afe81514fb0dd7991] netfilter: x_tables: disable 32bit compat interface in user namespaces
>>>> git bisect bad ec1806a730a1c0b3d68a7f9afe81514fb0dd7991
>>>> # good: [50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85] mptcp: do not drop partial packets
>>>> git bisect good 50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85
>>>> # good: [68993ced0f618e36cf33388f1e50223e5e6e78cc] Merge tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>>>> git bisect good 68993ced0f618e36cf33388f1e50223e5e6e78cc
>>>> # good: [34c78dff59a25110a4ce50c208e42a91490fe615] Merge branch 'net-use-ip_outnoroutes-drop-reason'
>>>> git bisect good 34c78dff59a25110a4ce50c208e42a91490fe615
>>>> # bad: [9587ed8137fb83d93f84b858337412f4500b21e9] Merge branch 'gve-add-support-for-ptp-gettimex64'
>>>> git bisect bad 9587ed8137fb83d93f84b858337412f4500b21e9
>>>> # bad: [83ea7fd73b11dd8cbf4416507a5eac3890b49fb0] net: dsa: microchip: remove unused phylink_mac_link_up() callback
>>>> git bisect bad 83ea7fd73b11dd8cbf4416507a5eac3890b49fb0
>>>> # bad: [f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a] net: make is_skb_wmem() available to modules
>>>> git bisect bad f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a
>>>> # bad: [c411baa463e85a779a7e68a00ba6298770b58c4c] netconsole: move push_ipv6() from netpoll
>>>> git bisect bad c411baa463e85a779a7e68a00ba6298770b58c4c
>>>> # good: [fba362c17d9d9211fc51f272156bb84fc23bdf98] ptr_ring: move free-space check into separate helper
>>>> git bisect good fba362c17d9d9211fc51f272156bb84fc23bdf98
>>>> # bad: [d0273dbe8be1640e597552f81faf1d6c9997d3e3] ipvlan: use netif_receive_skb() in ipvlan_process_multicast()
>>>> git bisect bad d0273dbe8be1640e597552f81faf1d6c9997d3e3
>>>> # bad: [3803065cd6b0630d4161d86aa04e2d1db0f3a0b5] Merge branch 'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops'
>>>> git bisect bad 3803065cd6b0630d4161d86aa04e2d1db0f3a0b5
>>>> # bad: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
>>>> git bisect bad 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3
>>>> # first bad commit: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
>>>>
>>>> --
>>>> Brett Sheffield (he/him)
>>>> Librecast - Decentralising the Internet with Multicast
>>>> https://librecast.net/
>>>> https://blog.brettsheffield.com/
>>>
>
^ permalink raw reply
* Re: [PATCH net-next v4 15/15] bnxt_en: Add kTLS retransmission support
From: Paolo Abeni @ 2026-07-02 7:55 UTC (permalink / raw)
To: Michael Chan, davem
Cc: netdev, edumazet, kuba, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260629184921.3496727-16-michael.chan@broadcom.com>
On 6/29/26 8:49 PM, Michael Chan wrote:
> int bnxt_ktls_alloc_tx_ring_stats(struct bnxt *bp, struct bnxt_tx_ring_info *txr)
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h
> index 1c935e0d413d..40b94bbf5a38 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h
> @@ -43,6 +43,8 @@ struct bnxt_ktls_offload_ctx_tx {
> u32 next_tcp_seq_no;/* staged tcp seq no */
> u32 kid;
> u32 pending_bytes; /* staged payload bytes */
> + u32 pending_fwd:1;
> + u32 pending_ooo:1;
Minor nit: AFAICS the above field are touched in fastpath. Using a
`bool` type will likely yield better code.
/P
^ permalink raw reply
* Re: [PATCH net-next v4 09/15] bnxt_en: Add infrastructure for crypto key context IDs
From: Paolo Abeni @ 2026-07-02 7:53 UTC (permalink / raw)
To: Michael Chan, davem
Cc: netdev, edumazet, kuba, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260629184921.3496727-10-michael.chan@broadcom.com>
On 6/29/26 8:49 PM, Michael Chan wrote:
> +/**
> + * bnxt_clear_crypto - Clear all crypto key contexts
> + * @bp: pointer to bnxt device
> + *
> + * Clears all key context allocations during shutdown or firmware reset.
> + * Frees all key info structures and bitmaps, and increments the epoch
> + * counter to invalidate any outstanding key references.
> + *
> + * This function assumes serialization (called during shutdown) and does
> + * not use locking.
> + *
> + * Context: Process context during shutdown/reset
> + */
> +void bnxt_clear_crypto(struct bnxt *bp)
> +{
> + struct bnxt_crypto_info *crypto = bp->crypto_info;
> + struct bnxt_kid_info *kid, *tmp;
> + struct bnxt_kctx *kctx;
> + int i;
> +
> + if (!crypto)
> + return;
> +
> + /* Only called when shutting down or FW reset with BNXT_STATE_OPEN
> + * cleared, so no concurrent access. No protection needed.
> + */
> + for (i = 0; i < BNXT_MAX_CRYPTO_KEY_TYPE; i++) {
> + kctx = &crypto->kctx[i];
> + list_for_each_entry_safe(kid, tmp, &kctx->list, list) {
> + list_del(&kid->list);
> + kfree(kid);
Sashiko still complains about RCU rules violation here, and the complain
looks legit to me.
Note that to streamline patch processing you are expected to reply to
sashiko comments outline why they are (not) legit.
/P
^ permalink raw reply
* RE: [PATCH] net/sched: cake: reject overhead values that underflow length
From: Jagielski, Jedrzej @ 2026-07-02 7:52 UTC (permalink / raw)
To: Samuel Moelius, Toke Høiland-Jørgensen
Cc: Hadi Salim, Jamal, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman,
moderated list:CAKE QDISC, open list:TC subsystem, open list
In-Reply-To: <20260701235656.296208.68e320e0746d.cake-overhead-underflow@trailofbits.com>
From: Samuel Moelius <sam.moelius@trailofbits.com>
Sent: Thursday, July 2, 2026 1:57 AM
>CAKE accepts signed overhead values and stores them in an s16, but the
>adjusted packet length calculation uses unsigned arithmetic. A negative
>effective length can therefore wrap to a large value.
>
>Such configurations make rate accounting depend on integer wraparound
>rather than on the packet size userspace intended to model. A static
>netlink lower bound is not enough because packets reaching CAKE can be
>smaller than any reasonable manual-overhead allowance.
>
>Fold the signed overhead adjustment into the existing datapath MPU clamp
>so negative adjusted lengths are clamped before link-layer framing
>adjustments.
>
>Fixes: a729b7f0bd5b ("sch_cake: Add overhead compensation support to the rate shaper")
>Assisted-by: Codex:gpt-5.5-cyber-preview
>Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
>---
>Changes in v3:
> - Adjust how check is performed
>Changes in v2:
> - Add fixes tag
Hi,
just for the future - please mention the revision number in the
mail subject
^ permalink raw reply
* Re: [PATCH net-next V4 4/6] devlink: Apply eswitch mode boot defaults
From: Jiri Pirko @ 2026-07-02 7:52 UTC (permalink / raw)
To: Mark Bloch
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Lunn,
Jonathan Corbet, Shuah Khan, netdev, linux-rdma, linux-doc
In-Reply-To: <ecaeeef0-c463-4f10-885a-02ad2d648be0@nvidia.com>
Wed, Jul 01, 2026 at 07:42:57PM +0200, mbloch@nvidia.com wrote:
>
>
>On 01/07/2026 17:09, Jiri Pirko wrote:
>> Wed, Jul 01, 2026 at 02:57:21PM +0200, mbloch@nvidia.com wrote:
>>>
>>>
>>> On 01/07/2026 12:48, Jiri Pirko wrote:
>>>> Mon, Jun 29, 2026 at 08:20:59PM +0200, mbloch@nvidia.com wrote:
>>>>> Apply parsed devlink_eswitch_mode= defaults after devlink registration
>>>>> and after successful reload.
>>>>>
>>>>> devl_register() may still be called before the device is ready for an
>>>>
>>>> How so? I would assume that driver calls devl_register only after
>>>> everything is up and running and ready. If not, isn't it a bug?
>>>>
>>>
>>> You would think so :)
>>>
>>> Some drivers, mlx5 included, call devl_register() while holding the
>>> devlink instance lock and then finish setting up state before releasing
>>> the lock.
>>>
>>> In v3 I tried to enforce exactly that model, move devl_register() to
>>> be the last thing the driver does. Jakub pushed back on making that a
>>> general rule. So in v4 I changed the approach. devl_register() only
>>> schedules the work, and the actual eswitch mode change can run only
>>> after the driver releases the devlink lock.
>>
>> Wouldn't it make sense to use a completion instead of loop-reschedule of
>> delayed work?
>
>Just to make sure I understand the suggestion, this would mean that the
>work waits until the devlink lock holder drops the lock, and devl_unlock()
>would signal it, something like:
>
>void devl_unlock(struct devlink *devlink)
>{
> ool complete_apply = devlink->default_esw_mode_apply_pending;
>
> mutex_unlock(&devlink->lock);
>
> if (complete_apply)
> complete(&devlink->default_esw_mode_apply_ready);
>}
>
>That would avoid the retry loop, but it also means the queued work
>sleeps until the driver drops devl_lock. It does keep one worker
>blocked per pending instance and adds this default-esw-mode signalling to
>the generic devl_unlock() path.
>
>The delayed retry was meant to avoid a sleeping worker and keep the
>instances independent. If one devlink instance is still locked, we just
>try it again later while other instances can progress.
>
>If you prefer the completion approach I can switch to it, but I don't see
>it as simpler overall.
Yeah, I don't have preference. I was just wondering. Feel free to leave
it as is.
Maybe, instead of "complete", you can schedule with "0" delay in
devl_unlock? Well, it does not really need to be delayed work, right?
The only single schedule may be done from devl_unlock. That would help
to eliminate the rescheduling. Am I missing something?
>
>Mark
>
>>
>>>
>>> Mark
>>>
>>>>
>>>>> eswitch mode change, so keep a per-devlink delayed work item and pending
>>>>> flag for the registration path. Registration queues the work, and the
>>>>> worker tries to take the devlink instance lock.
>>>>>
>>>>> If the lock is busy, the worker requeues itself with a delay.
>>>>>
>>>>> For successful reloads that performed DRIVER_REINIT, devlink_reload()
>>>>> already holds the devlink instance lock and the driver has completed
>>>>> reload_up(). Clear pending work and apply the default directly from the
>>>>> reload path instead of queueing work.
>>>>>
>>>>> If a user sets eswitch mode through netlink before the pending
>>>>> registration work runs, clear the pending flag so the queued default does
>>>>> not override that user request. Cancel pending default apply work when
>>>>> freeing the devlink instance.
>>>>
>>>> These AI generated code descriptive messages are generally not very
>>>> useful :(
>>>>
>>>
>
^ permalink raw reply
* [PATCH net-next v4] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Minxi Hou @ 2026-07-02 7:50 UTC (permalink / raw)
To: netdev
Cc: Minxi Hou, aconole, echaudro, i.maximets, davem, edumazet, kuba,
pabeni, horms, shuah, dev, linux-kselftest
Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that
icmpv6(type=...) can be used in flow specifications. Without this
registration the parser silently drops the token and the kernel
rejects the flow with EINVAL because the expected ICMPv6 key
attribute is missing.
While here, add convert_int() to the ovs_key_ipv6 and ovs_key_icmp
fields_map entries so that specifying a field value produces the
correct wildcard mask. The IPv6 flow label uses convert_int(20) to
produce a 20-bit mask (0x000FFFFF), matching the kernel constraint in
flow_netlink.c that rejects masks with bits 20-31 set; byte-wide
fields use convert_int(8). The ipv4 counterpart already does this via
convert_int(); the ipv6 and icmp classes were simply missing the fifth
tuple element. Existing callers that pass empty parentheses are
unaffected because convert_int("") returns (0, 0).
Add test_icmpv6 exercising the ICMPv6 echo flow key. The test uses
static neighbour entries with nud permanent to prevent racy NDP, then
verifies in three steps: install icmpv6(type=128) and
icmpv6(type=129) flows and confirm ping works, remove the flows and
confirm ping fails, reinstall and confirm recovery.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
.../selftests/net/openvswitch/openvswitch.sh | 70 +++++++++++++++++++
.../selftests/net/openvswitch/ovs-dpctl.py | 26 +++++--
2 files changed, 89 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index 2954245129a2..f88cefa71559 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -32,6 +32,7 @@ tests="
dec_ttl ttl: dec_ttl decrements IP TTL
flow_set flow-set: Flow modify
action_set set: SET action rewrites fields
+ icmpv6 icmpv6: ICMPv6 echo type match
psample psample: Sampling packets with psample"
info() {
@@ -443,6 +444,75 @@ test_action_set() {
return 0
}
+# icmpv6 test
+# - static neighbours to bypass NDP (nud permanent)
+# - icmpv6(type=128) echo request, icmpv6(type=129) echo reply
+# - remove flows and verify ping fails, reinstall and recover
+test_icmpv6() {
+ local t="test_icmpv6"
+ local v6="eth_type(0x86dd),ipv6(proto=58)"
+
+ sbx_add "$t" || return $?
+ ovs_add_dp "$t" icmpv6 || return 1
+
+ info "create namespaces"
+ for ns in client server; do
+ ovs_add_netns_and_veths "$t" "icmpv6" \
+ "$ns" "${ns:0:1}0" "${ns:0:1}1" || return 1
+ done
+
+ ip netns exec client ip addr add fd00::1/64 dev c1 nodad
+ ip netns exec client ip link set c1 up
+ ip netns exec server ip addr add fd00::2/64 dev s1 nodad
+ ip netns exec server ip link set s1 up
+
+ local cl_mac sl_mac
+ cl_mac=$(ip netns exec client ip link show c1 \
+ | awk '/link\/ether/ {print $2}')
+ [ -z "$cl_mac" ] && \
+ { info "failed to get c1 hwaddr"; return 1; }
+ sl_mac=$(ip netns exec server ip link show s1 \
+ | awk '/link\/ether/ {print $2}')
+ [ -z "$sl_mac" ] && \
+ { info "failed to get s1 hwaddr"; return 1; }
+ ip netns exec client ip -6 neigh add fd00::2 \
+ lladdr "$sl_mac" nud permanent dev c1 || return 1
+ ip netns exec server ip -6 neigh add fd00::1 \
+ lladdr "$cl_mac" nud permanent dev s1 || return 1
+
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(1),eth(),$v6,icmpv6(type=128)" \
+ '2' || return 1
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(2),eth(),$v6,icmpv6(type=129)" \
+ '1' || return 1
+
+ info "verify ICMPv6 echo with type-specific flows"
+ ovs_sbx "$t" ip netns exec client \
+ ping -6 -c 1 -W 2 fd00::2 || return 1
+
+ ovs_del_flows "$t" icmpv6
+
+ info "verify ping fails without echo flows"
+ ovs_sbx "$t" ip netns exec client \
+ ping -6 -c 1 -W 2 fd00::2 >/dev/null 2>&1 \
+ && { info "ping should fail without flows"
+ return 1; }
+
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(1),eth(),$v6,icmpv6(type=128)" \
+ '2' || return 1
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(2),eth(),$v6,icmpv6(type=129)" \
+ '1' || return 1
+
+ info "verify connectivity restored"
+ ovs_sbx "$t" ip netns exec client \
+ ping -6 -c 1 -W 2 fd00::2 || return 1
+
+ return 0
+}
+
# psample test
# - use psample to observe packets
test_psample() {
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
index e1ecfad2c03e..f3edd198223f 100644
--- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
+++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
@@ -1255,11 +1255,16 @@ class ovskey(nla):
lambda x: ipaddress.IPv6Address(x).packed if x else 0,
convert_ipv6,
),
- ("label", "label", "%d", lambda x: int(x) if x else 0),
- ("proto", "proto", "%d", lambda x: int(x) if x else 0),
- ("tclass", "tclass", "%d", lambda x: int(x) if x else 0),
- ("hlimit", "hlimit", "%d", lambda x: int(x) if x else 0),
- ("frag", "frag", "%d", lambda x: int(x) if x else 0),
+ ("label", "label", "%d", lambda x: int(x) if x else 0,
+ convert_int(20)),
+ ("proto", "proto", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("tclass", "tclass", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("hlimit", "hlimit", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("frag", "frag", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
)
def __init__(
@@ -1344,8 +1349,10 @@ class ovskey(nla):
)
fields_map = (
- ("type", "type", "%d", lambda x: int(x) if x else 0),
- ("code", "code", "%d", lambda x: int(x) if x else 0),
+ ("type", "type", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("code", "code", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
)
def __init__(
@@ -1982,6 +1989,11 @@ class ovskey(nla):
"icmp",
ovskey.ovs_key_icmp,
),
+ (
+ "OVS_KEY_ATTR_ICMPV6",
+ "icmpv6",
+ ovskey.ovs_key_icmpv6,
+ ),
(
"OVS_KEY_ATTR_TCP_FLAGS",
"tcp_flags",
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v3] selftests/net/openvswitch: add output truncation test
From: Minxi Hou @ 2026-07-02 7:49 UTC (permalink / raw)
To: netdev
Cc: Minxi Hou, aconole, echaudro, i.maximets, davem, edumazet, kuba,
pabeni, horms, shuah, dev, linux-kselftest
Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test
verifies truncation limits in four steps: reject trunc(1) and
trunc(13) which are below ETH_HLEN, confirm normal forwarding works,
apply trunc(14) which truncates packets to the Ethernet header and
verify ping fails, then restore normal forwarding and verify recovery.
The kernel requires max_len >= ETH_HLEN (14 bytes). trunc(14) sets
OVS_CB(skb)->cutlen so pskb_trim strips the IP payload at output
time; the receiver drops the runt frame and no echo reply is
generated.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
.../selftests/net/openvswitch/openvswitch.sh | 87 +++++++++++++++++++
1 file changed, 87 insertions(+)
diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index 2954245129a2..f75ee723415a 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -32,6 +32,7 @@ tests="
dec_ttl ttl: dec_ttl decrements IP TTL
flow_set flow-set: Flow modify
action_set set: SET action rewrites fields
+ trunc trunc: output truncation
psample psample: Sampling packets with psample"
info() {
@@ -443,6 +444,92 @@ test_action_set() {
return 0
}
+# trunc test
+# - trunc(14): truncate to ETH_HLEN, strips IP payload, ping fails
+# - trunc(1) and trunc(13): kernel rejects below ETH_HLEN (EINVAL)
+# - restore normal forwarding and verify recovery
+test_trunc() {
+ sbx_add "test_trunc" || return $?
+ ovs_add_dp "test_trunc" trunctest || return 1
+
+ info "create namespaces"
+ for ns in client server; do
+ ovs_add_netns_and_veths "test_trunc" "trunctest" \
+ "$ns" "${ns:0:1}0" "${ns:0:1}1" || return 1
+ done
+
+ ip netns exec client ip addr add 10.0.0.1/24 dev c1
+ ip netns exec client ip link set c1 up
+ ip netns exec server ip addr add 10.0.0.2/24 dev s1
+ ip netns exec server ip link set s1 up
+
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4()' \
+ '1' || return 1
+
+ info "verify connectivity without truncation"
+ ovs_sbx "test_trunc" ip netns exec client \
+ ping -c 1 -W 2 10.0.0.2 || return 1
+
+ # trunc below ETH_HLEN must be rejected by the kernel
+ info "verify trunc(1) is rejected"
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ 'trunc(1),2' &> /dev/null \
+ && { info "trunc(1) should be rejected"; return 1; }
+
+ info "verify trunc(13) is rejected"
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ 'trunc(13),2' &> /dev/null \
+ && { info "trunc(13) should be rejected"; return 1; }
+
+ ovs_del_flows "test_trunc" trunctest
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+
+ info "add trunc(14) forwarding flow"
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ 'trunc(14),2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4()' \
+ '1' || return 1
+
+ info "verify ping fails with trunc(14)"
+ ovs_sbx "test_trunc" ip netns exec client \
+ ping -c 1 -W 2 10.0.0.2 >/dev/null 2>&1 \
+ && { info "ping should fail with trunc(14)"
+ return 1; }
+
+ ovs_del_flows "test_trunc" trunctest
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4()' \
+ '1' || return 1
+
+ info "verify connectivity restored"
+ ovs_sbx "test_trunc" ip netns exec client \
+ ping -c 1 -W 2 10.0.0.2 || return 1
+
+ return 0
+}
+
# psample test
# - use psample to observe packets
test_psample() {
--
2.54.0
^ permalink raw reply related
* [syzbot ci] Re: net: Support per-netns device unregistration
From: syzbot ci @ 2026-07-02 7:45 UTC (permalink / raw)
To: andrew, davem, edumazet, horms, kuba, kuni1840, kuniyu, netdev,
pabeni
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260701214334.266991-1-kuniyu@google.com>
syzbot ci has tested the following series
[v1] net: Support per-netns device unregistration
https://lore.kernel.org/all/20260701214334.266991-1-kuniyu@google.com
* [PATCH v1 net-next 01/14] rtnetlink: Lock sock_net(skb->sk) in rtnl_newlink().
* [PATCH v1 net-next 02/14] rtnetlink: Call unregister_netdevice_many() only once in rtnl_link_unregister().
* [PATCH v1 net-next 03/14] rtnetlink: Add per-netns rtnl_work.
* [PATCH v1 net-next 04/14] net: Wrap default_device_exit_net() with __rtnl_net_lock().
* [PATCH v1 net-next 05/14] net: Hold __rtnl_net_lock() in netdev_wait_allrefs_any().
* [PATCH v1 net-next 06/14] net: Add per-netns netdev unregistration infra.
* [PATCH v1 net-next 07/14] net: Call unregister_netdevice_many() per netns.
* [PATCH v1 net-next 08/14] veth: Support per-netns device unregistration.
* [PATCH v1 net-next 09/14] bareudp: Protect bareudp_list with mutex.
* [PATCH v1 net-next 10/14] bareudp: Support per-netns netdev unregistration.
* [PATCH v1 net-next 11/14] ipvlan: Convert ipvl_port.count to refcount_t.
* [PATCH v1 net-next 12/14] ipvlan: Synchronise ipvlan_init() and ipvlan_uninit() for the same lower dev.
* [PATCH v1 net-next 13/14] ipvlan: Protect ipvl_port.ipvlans with mutex.
* [PATCH v1 net-next 14/14] ipvlan: Support per-netns netdev unregistration.
and found the following issue:
possible deadlock in __dev_change_net_namespace
Full report is available here:
https://ci.syzbot.org/series/a744b257-d741-4780-8a53-f156b2a7afc9
***
possible deadlock in __dev_change_net_namespace
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: d6e81529749190123aa0040626c7e5dbc20fdc9a
arch: amd64
compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config: https://ci.syzbot.org/builds/243cd0ec-28f9-4d21-8f16-3d2fbad8388d/config
syz repro: https://ci.syzbot.org/findings/a8a0740d-fdec-4a20-9aa5-7cb955707913/syz_repro
veth0_macvtap: left promiscuous mode
============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
syz.1.18/5814 is trying to acquire lock:
ffffffff9a9b0418 (&net->dev_unreg_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
ffffffff9a9b0418 (&net->dev_unreg_lock){+.+.}-{3:3}, at: unregister_netdevice_move_net net/core/dev.c:-1 [inline]
ffffffff9a9b0418 (&net->dev_unreg_lock){+.+.}-{3:3}, at: __dev_change_net_namespace+0x1479/0x2200 net/core/dev.c:12768
but task is already holding lock:
ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: unregister_netdevice_move_net net/core/dev.c:-1 [inline]
ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: __dev_change_net_namespace+0x146a/0x2200 net/core/dev.c:12768
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&net->dev_unreg_lock);
lock(&net->dev_unreg_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by syz.1.18/5814:
#0: ffffffff8fdeb0c0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#0: ffffffff8fdeb0c0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x2a/0x2b0 net/core/rtnetlink.c:366
#1: ffffffff9a9b0380 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x76/0x2b0 net/core/rtnetlink.c:369
#2: ffff88810b6cf840 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0xbf/0x2b0 net/core/rtnetlink.c:369
#3: ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
#3: ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: unregister_netdevice_move_net net/core/dev.c:-1 [inline]
#3: ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: __dev_change_net_namespace+0x146a/0x2200 net/core/dev.c:12768
stack backtrace:
CPU: 0 UID: 0 PID: 5814 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_deadlock_bug+0x279/0x290 kernel/locking/lockdep.c:3041
check_deadlock kernel/locking/lockdep.c:3093 [inline]
validate_chain kernel/locking/lockdep.c:3895 [inline]
__lock_acquire+0x24df/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
__raw_spin_lock include/linux/spinlock_api_smp.h:158 [inline]
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:158
spin_lock include/linux/spinlock.h:342 [inline]
unregister_netdevice_move_net net/core/dev.c:-1 [inline]
__dev_change_net_namespace+0x1479/0x2200 net/core/dev.c:12768
do_setlink+0x2d1/0x4670 net/core/rtnetlink.c:3148
rtnl_changelink net/core/rtnetlink.c:3880 [inline]
__rtnl_newlink net/core/rtnetlink.c:4053 [inline]
rtnl_newlink+0x1612/0x1b50 net/core/rtnetlink.c:4192
rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7109
netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x7bb/0x940 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec+0x13a/0x180 net/socket.c:775
__sock_sendmsg net/socket.c:790 [inline]
____sys_sendmsg+0x54e/0x850 net/socket.c:2684
___sys_sendmsg+0x2a5/0x360 net/socket.c:2738
__sys_sendmsg net/socket.c:2770 [inline]
__do_sys_sendmsg net/socket.c:2775 [inline]
__se_sys_sendmsg net/socket.c:2773 [inline]
__x64_sys_sendmsg+0x1b1/0x290 net/socket.c:2773
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbdc639ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fbdc59fe028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fbdc6615fa0 RCX: 00007fbdc639ce59
RDX: 0000000000000000 RSI: 0000200000000740 RDI: 0000000000000003
RBP: 00007fbdc6432e6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbdc6616038 R14: 00007fbdc6615fa0 R15: 00007ffd94dcb1f8
</TASK>
syz.1.18 (5814) used greatest stack depth: 19864 bytes left
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Michael S. Tsirkin @ 2026-07-02 7:42 UTC (permalink / raw)
To: Simon Schippers
Cc: Brett Sheffield, 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: <ef33f0a7-f0b7-4bc4-9263-10d2b480d717@tu-dortmund.de>
On Thu, Jul 02, 2026 at 09:24:59AM +0200, Simon Schippers wrote:
> On 7/1/26 22:56, Michael S. Tsirkin wrote:
> > On Wed, Jul 01, 2026 at 09:16:48PM +0200, Brett Sheffield wrote:
> >> TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
> >> significant performance regressions with TAP interfaces and multithreaded
> >> network code. Please revert.
> >>
> >>
> >> Librecast is an IPv6 multicast library. One of the tests (0055) fails under
> >> Linux 7.2-rc1. The test performs data synchronization over IPv6 multicast using a TAP
> >> interface. This test has run successfully on every stable, LTS and mainline RC
> >> released in the past year. Every kernel with my Tested-by has run this test.
> >>
> >> There have been a bunch of changes to MLDv2 so I started bisecting there, but
> >> the culprit is actually 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 "tun/tap &
> >> vhost-net: avoid ptr_ring tail-drop when a qdisc is present"
> >>
> >> Reverting this commit fixes the test.
> >>
> >> To eliminate my code and any multicast weirdness, I ran tests with iperf3
> >> comparing the same host running 7.2-rc1 both with and without 1d6e569b7d0
> >> reverted.
>
> Thank you very much for your bisect!
>
> As the author, I am sorry for that regression!
>
> >
> > Thanks a lot for the bisect! Reverting is not out of question, but
> > just before we do, it is worth analyzing the situation.
> >
> > Could you pls tell us
> > - do you see packet drops?
>
> iperf3 shows no TCP retransmissions, so there were never packet drops
> when the patch was enabled.
> It is the number after the sender data rate (example: threads 1,
> reverted has 368 retransmissions/drops).
>
> > - does it help to increase the tun queue size?
>
> I agree, this would be great to know.
>
> However, even then we must act. I am considering IFF_BACKPRESSURE
> as a feature flag, defaulting to off. It would just enable/disable
> the stopping logic in tun_net_xmit() and the waking logic
> in __tun_wake_queue(). If disabled, it would result in the same logic
> as before.
>
> I could provide such a patch as [net] material.
>
> Thanks again!
Or BQL? I quickly wrote a prototype of that and it seems to work well -
could you help test maybe?
> >
> > Thanks a lot!
> >
> >
> >> CPU: AMD Ryzen 9 9950X
> >>
> >> [ host ] - [ bridge ] - [ tap ] - [ guest (qemu) ]
> >>
> >> Running matching kernels on host and guest, I started iperf3 in server mode on
> >> the guest and tested from the host so traffic passes through the tap interface.
> >>
> >> iperf3 -s -V # server
> >> iperf3 -c guest -P nthreads # client
> >>
> >> 7.2.0-rc1 (threads 1):
> >>
> >> [ 5] 0.00-10.00 sec 20.2 GBytes 17.4 Gbits/sec 0 sender
> >> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 1, reverted):
> >>
> >> [ 5] 0.00-10.00 sec 15.3 GBytes 13.1 Gbits/sec 368 sender
> >> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 2):
> >>
> >> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
> >> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 2, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 15.9 GBytes 13.7 Gbits/sec 1567 sender
> >> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 4):
> >>
> >> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
> >> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 4, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 16.5 GBytes 14.1 Gbits/sec 6701 sender
> >> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 8):
> >>
> >> [SUM] 0.00-10.00 sec 10.7 GBytes 9.15 Gbits/sec 0 sender
> >> [SUM] 0.00-10.01 sec 10.6 GBytes 9.13 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 8, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 16.2 GBytes 14.0 Gbits/sec 19319 sender
> >> [SUM] 0.00-10.00 sec 15.7 GBytes 13.5 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 16):
> >>
> >> [SUM] 0.00-10.00 sec 10.9 GBytes 9.35 Gbits/sec 0 sender
> >> [SUM] 0.00-10.01 sec 10.9 GBytes 9.32 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 16, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec 43593 sender
> >> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec receiver
> >>
> >>
> >> As you can see, the new code works for single threaded, but for all other cases
> >> there's a significant performance drop. I see this trade-off is mentioned in the
> >> commit, but the performance drop off is much worse than suggested with the
> >> current patch.
> >>
> >> In our multicast use case data is sent by multiple threads to multiple groups
> >> simultaneously, this just breaks things to the extent that a <2 second test
> >> times out after 5 minutes.
> >>
> >>
> >> git bisect start
> >> # status: waiting for both good and bad commits
> >> # bad: [dc59e4fea9d83f03bad6bddf3fa2e52491777482] Linux 7.2-rc1
> >> git bisect bad dc59e4fea9d83f03bad6bddf3fa2e52491777482
> >> # status: waiting for good commit(s), bad commit known
> >> # good: [36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
> >> git bisect good 36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1
> >> # good: [db314398f618a3a23315f73c87f7d318eaf06c1b] Merge branch 'net-bridge-mcast-support-exponential-field-encoding'
> >> git bisect good db314398f618a3a23315f73c87f7d318eaf06c1b
> >> # bad: [079a028d6327e68cfa5d38b36123637b321c19a7] string: Remove strncpy() from the kernel
> >> git bisect bad 079a028d6327e68cfa5d38b36123637b321c19a7
> >> # bad: [f396f4005180928cd9e15e352a6512865d3bc908] Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
> >> git bisect bad f396f4005180928cd9e15e352a6512865d3bc908
> >> # bad: [ec1806a730a1c0b3d68a7f9afe81514fb0dd7991] netfilter: x_tables: disable 32bit compat interface in user namespaces
> >> git bisect bad ec1806a730a1c0b3d68a7f9afe81514fb0dd7991
> >> # good: [50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85] mptcp: do not drop partial packets
> >> git bisect good 50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85
> >> # good: [68993ced0f618e36cf33388f1e50223e5e6e78cc] Merge tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> >> git bisect good 68993ced0f618e36cf33388f1e50223e5e6e78cc
> >> # good: [34c78dff59a25110a4ce50c208e42a91490fe615] Merge branch 'net-use-ip_outnoroutes-drop-reason'
> >> git bisect good 34c78dff59a25110a4ce50c208e42a91490fe615
> >> # bad: [9587ed8137fb83d93f84b858337412f4500b21e9] Merge branch 'gve-add-support-for-ptp-gettimex64'
> >> git bisect bad 9587ed8137fb83d93f84b858337412f4500b21e9
> >> # bad: [83ea7fd73b11dd8cbf4416507a5eac3890b49fb0] net: dsa: microchip: remove unused phylink_mac_link_up() callback
> >> git bisect bad 83ea7fd73b11dd8cbf4416507a5eac3890b49fb0
> >> # bad: [f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a] net: make is_skb_wmem() available to modules
> >> git bisect bad f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a
> >> # bad: [c411baa463e85a779a7e68a00ba6298770b58c4c] netconsole: move push_ipv6() from netpoll
> >> git bisect bad c411baa463e85a779a7e68a00ba6298770b58c4c
> >> # good: [fba362c17d9d9211fc51f272156bb84fc23bdf98] ptr_ring: move free-space check into separate helper
> >> git bisect good fba362c17d9d9211fc51f272156bb84fc23bdf98
> >> # bad: [d0273dbe8be1640e597552f81faf1d6c9997d3e3] ipvlan: use netif_receive_skb() in ipvlan_process_multicast()
> >> git bisect bad d0273dbe8be1640e597552f81faf1d6c9997d3e3
> >> # bad: [3803065cd6b0630d4161d86aa04e2d1db0f3a0b5] Merge branch 'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops'
> >> git bisect bad 3803065cd6b0630d4161d86aa04e2d1db0f3a0b5
> >> # bad: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
> >> git bisect bad 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3
> >> # first bad commit: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
> >>
> >> --
> >> Brett Sheffield (he/him)
> >> Librecast - Decentralising the Internet with Multicast
> >> https://librecast.net/
> >> https://blog.brettsheffield.com/
> >
^ permalink raw reply
* Re: [PATCH net-next V4 4/6] devlink: Apply eswitch mode boot defaults
From: Paolo Abeni @ 2026-07-02 7:41 UTC (permalink / raw)
To: Mark Bloch, Jiri Pirko, Eric Dumazet, Jakub Kicinski,
Simon Horman
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Lunn,
Jonathan Corbet, Shuah Khan, netdev, linux-rdma, linux-doc
In-Reply-To: <20260629182102.245150-5-mbloch@nvidia.com>
On 6/29/26 8:20 PM, Mark Bloch wrote:
> Apply parsed devlink_eswitch_mode= defaults after devlink registration
> and after successful reload.
>
> devl_register() may still be called before the device is ready for an
> eswitch mode change, so keep a per-devlink delayed work item and pending
> flag for the registration path. Registration queues the work, and the
> worker tries to take the devlink instance lock.
>
> If the lock is busy, the worker requeues itself with a delay.
>
> For successful reloads that performed DRIVER_REINIT, devlink_reload()
> already holds the devlink instance lock and the driver has completed
> reload_up(). Clear pending work and apply the default directly from the
> reload path instead of queueing work.
>
> If a user sets eswitch mode through netlink before the pending
> registration work runs, clear the pending flag so the queued default does
> not override that user request. Cancel pending default apply work when
> freeing the devlink instance.
>
> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> ---
> net/devlink/core.c | 198 +++++++++++++++++++++++++++++++-----
> net/devlink/dev.c | 6 ++
> net/devlink/devl_internal.h | 5 +
> 3 files changed, 182 insertions(+), 27 deletions(-)
>
> diff --git a/net/devlink/core.c b/net/devlink/core.c
> index 5126509a9c4e..998e4ffd5dce 100644
> --- a/net/devlink/core.c
> +++ b/net/devlink/core.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/init.h>
> +#include <linux/jiffies.h>
> #include <linux/list.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> @@ -22,8 +23,12 @@ DEFINE_XARRAY_FLAGS(devlinks, XA_FLAGS_ALLOC);
>
> static char *devlink_default_esw_mode_param;
> static bool devlink_default_esw_mode_match_all;
> +static bool devlink_default_esw_mode_enabled;
> static enum devlink_eswitch_mode devlink_default_esw_mode;
> static LIST_HEAD(devlink_default_esw_mode_nodes);
> +static struct workqueue_struct *devlink_default_esw_mode_wq;
> +
> +#define DEVLINK_DEFAULT_ESW_MODE_APPLY_DELAY msecs_to_jiffies(100)
>
> struct devlink_default_esw_mode_node {
> struct list_head list;
> @@ -166,6 +171,7 @@ static void __init devlink_default_esw_mode_nodes_clear(void)
> }
>
> devlink_default_esw_mode_match_all = false;
> + devlink_default_esw_mode_enabled = false;
> }
>
> static int __init devlink_default_esw_mode_parse(char *str)
> @@ -192,14 +198,113 @@ static int __init devlink_default_esw_mode_parse(char *str)
> return err;
>
> err = devlink_default_esw_mode_handles_parse(handles);
> - if (err)
> + if (err) {
> devlink_default_esw_mode_nodes_clear();
> - else
> + } else {
> devlink_default_esw_mode = esw_mode;
> + devlink_default_esw_mode_enabled = true;
> + }
>
> return err;
> }
>
> +static bool devlink_default_esw_mode_match(struct devlink *devlink)
> +{
> + const char *bus_name = devlink_bus_name(devlink);
> + const char *dev_name = devlink_dev_name(devlink);
> + struct devlink_default_esw_mode_node *node;
> +
> + if (devlink_default_esw_mode_match_all)
> + return true;
> +
> + node = devlink_default_esw_mode_node_find(bus_name, dev_name);
> + return !!node;
> +}
> +
> +void devlink_default_esw_mode_apply(struct devlink *devlink)
> +{
> + const struct devlink_ops *ops = devlink->ops;
> + int err;
> +
> + devl_assert_locked(devlink);
> +
> + if (!devlink_default_esw_mode_match(devlink))
> + return;
> +
> + if (!ops->eswitch_mode_set) {
> + if (!devlink_default_esw_mode_match_all)
> + devl_warn(devlink,
> + "devlink_eswitch_mode= selected this device but eswitch mode setting is not supported\n");
Not a very strong opinion on my side, but I *think* it would be more
consistent to emit this warning even for devlink_default_esw_mode_match_all
/P
^ permalink raw reply
* Re: [PATCH net] net/mlx5: HWS, fix matcher leak on resize target setup failure
From: patchwork-bot+netdevbpf @ 2026-07-02 7:40 UTC (permalink / raw)
To: Dawei Feng
Cc: saeedm, leon, tariqt, mbloch, andrew+netdev, davem, edumazet,
kuba, pabeni, kliteyn, vdogaru, horms, kees, stable, netdev,
linux-rdma, linux-kernel, jianhao.xu, zilin
In-Reply-To: <20260629064049.3852759-1-dawei.feng@seu.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 29 Jun 2026 14:40:49 +0800 you wrote:
> hws_bwc_matcher_move() allocates a replacement matcher before setting it
> as the resize target. If mlx5hws_matcher_resize_set_target() fails, the
> replacement matcher is not attached anywhere and is leaked.
>
> Fix the leak by destroying the replacement matcher before returning from
> the resize-target failure path.
>
> [...]
Here is the summary with links:
- [net] net/mlx5: HWS, fix matcher leak on resize target setup failure
https://git.kernel.org/netdev/net/c/bb09d0e64eca
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [PATCH net v2] cxgb4: flower: fix 802.1ad VLAN TPID matching in tc flower filters
From: Jagielski, Jedrzej @ 2026-07-02 7:35 UTC (permalink / raw)
To: Harsha M, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch, bharat@chelsio.com
In-Reply-To: <20260702044955.20119-1-h.mahadeva@chelsio.com>
From: Harsha M <h.mahadeva@chelsio.com>
Sent: Thursday, July 2, 2026 6:49 AM
>The cxgb4 driver does not correctly handle tc flower filters that
>match on an 802.1ad (Q-in-Q) outer VLAN tag. While the VLAN VID is
>processed, the specified 802.1ad TPID is not programmed into the
>adapter's outer VLAN matching configuration, resulting in incorrect
>filter matches.
>
>Fix this by configuring the port-specific OVLAN register with the
>requested TPID value, enabling OVLAN matching through the RX control
>register, and populating the filter specification with the outer VLAN
>VID and valid-bit match fields when an 802.1ad TPID is requested.This
>restores correct matching for tc flower filters that specify an 802.1ad
>outer VLAN tag
>
Hi
would be nice to have fixes tag
>Signed-off-by: Harsha M <h.mahadeva@chelsio.com>
>Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
>---
>v2:
>- Compare vlan_tpid with 'cpu_to_be16(ETH_P_8021AD)'
>- Program the OVLAN register using the ETH_P_8021AD constant
> and TPID mask as 0xffff instead of deriving the value from the
> filter key and mask
>v1:
>https://lore.kernel.org/all/20260629184417.31b21223@kernel.org/
>---
> .../ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 61 +++++++++++++------
> drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 3 +
> 2 files changed, 46 insertions(+), 18 deletions(-)
>
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>index 3307e5042681..8c5cfa6982e7 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>@@ -40,6 +40,7 @@
> #include "cxgb4.h"
> #include "cxgb4_filter.h"
> #include "cxgb4_tc_flower.h"
>+#include "t4_regs.h"
>
> #define STATS_CHECK_PERIOD (HZ / 2)
>
>@@ -266,24 +267,48 @@ static void cxgb4_process_flow_match(struct net_device *dev,
> VLAN_PRIO_SHIFT);
> vlan_tci_mask = match.mask->vlan_id | (match.mask->vlan_priority <<
> VLAN_PRIO_SHIFT);
>- fs->val.ivlan = vlan_tci;
>- fs->mask.ivlan = vlan_tci_mask;
>-
>- fs->val.ivlan_vld = 1;
>- fs->mask.ivlan_vld = 1;
>-
>- /* Chelsio adapters use ivlan_vld bit to match vlan packets
>- * as 802.1Q. Also, when vlan tag is present in packets,
>- * ethtype match is used then to match on ethtype of inner
>- * header ie. the header following the vlan header.
>- * So, set the ivlan_vld based on ethtype info supplied by
>- * TC for vlan packets if its 802.1Q. And then reset the
>- * ethtype value else, hw will try to match the supplied
>- * ethtype value with ethtype of inner header.
>- */
>- if (fs->val.ethtype == ETH_P_8021Q) {
>- fs->val.ethtype = 0;
>- fs->mask.ethtype = 0;
>+
>+ if (match.key->vlan_tpid == cpu_to_be16(ETH_P_8021AD)) {
>+ struct adapter *adap = netdev2adap(dev);
>+ u32 ovlan_reg, ctl_reg, val, port_id;
>+
>+ if (!adap) {
is such scenario really even possible?
>+ netdev_err(dev, "%s: adap not found\n", __func__);
>+ return;
>+ }
>+
>+ val = (0xffff << 16) | ETH_P_8021AD;
>+ port_id = netdev2pinfo(dev)->port_id;
>+ fs->val.ovlan = vlan_tci;
>+ fs->mask.ovlan = vlan_tci_mask;
>+ fs->val.ovlan_vld = 1;
>+ fs->mask.ovlan_vld = 1;
>+ ovlan_reg = PORT_REG(port_id, MPS_PORT_RX_OVLAN0_A);
>+ ctl_reg = PORT_REG(port_id, MPS_PORT_RX_CTL_A);
>+ t4_write_reg(adap, ovlan_reg, val);
>+ val = t4_read_reg(adap, ctl_reg);
>+ t4_write_reg(adap, ctl_reg, val | 1);
>+ t4_tp_wr_bits_indirect(adap, TP_INGRESS_CONFIG_A, 1U << 9, 0);
>+ } else {
>+ fs->val.ivlan = vlan_tci;
>+ fs->mask.ivlan = vlan_tci_mask;
>+ fs->val.ivlan_vld = 1;
>+ fs->mask.ivlan_vld = 1;
>+
>+ /* Chelsio adapters use ivlan_vld bit to match vlan packets
>+ * as 802.1Q. Also, when vlan tag is present in packets,
>+ * ethtype match is used then to match on ethtype of inner
>+ * header ie. the header following the vlan header.
>+ * So, set the ivlan_vld based on ethtype info supplied by
>+ * TC for vlan packets if its 802.1Q. And then reset the
>+ * ethtype value else, hw will try to match the supplied
>+ * ethtype value with ethtype of inner header.
>+ */
>+
isn't this already fs->val.ethtype != ETH_P_8021Q branch and fs has not
been modified since entering?
>+ if (fs->val.ethtype == ETH_P_8021Q) {
>+ fs->val.ethtype = 0;
>+ fs->mask.ethtype = 0;
>+ }
> }
> }
>
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
>index 695916ba0405..38c585f3b1ad 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
>+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
>@@ -1921,6 +1921,9 @@
> #define MAC_PORT_PTP_SUM_LO_A 0x990
> #define MAC_PORT_PTP_SUM_HI_A 0x994
>
>+#define MPS_PORT_RX_OVLAN0_A 0x120
>+#define MPS_PORT_RX_CTL_A 0X100
>+
> #define MPS_CMN_CTL_A 0x9000
>
> #define COUNTPAUSEMCRX_S 5
>--
>2.43.5
^ permalink raw reply
* [PATCH net v2] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
From: Yizhou Zhao @ 2026-07-02 7:34 UTC (permalink / raw)
To: netdev
Cc: Yizhou Zhao, Simon Horman, Julian Anastasov, Pablo Neira Ayuso,
Florian Westphal, Phil Sutter, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, lvs-devel, netfilter-devel, coreteam,
linux-kernel, stable, Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li,
Ke Xu
When an ICMP Fragmentation Needed error is received for a tunneled IPVS
connection, ip_vs_in_icmp() recomputes the MTU that the original packet
can use by subtracting the tunnel overhead from the reported next-hop
MTU.
The current code always subtracts sizeof(struct iphdr), which is only
the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and
ipvs_gre_decap() already compute the additional tunnel header length,
but that value is scoped to the decapsulation block and is lost before
the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to
the client advertises an MTU that is too large, so PMTUD can fail to
converge for GUE/GRE-tunneled real servers.
With a reported next-hop MTU of 1400, a GUE tunnel currently returns
1380 to the client. The correct value is 1368:
1400 - sizeof(struct iphdr) - sizeof(struct udphdr) -
sizeof(struct guehdr)
Hoist the tunnel header length into the main ip_vs_in_icmp() scope and
subtract sizeof(struct iphdr) + ulen in the Fragmentation Needed path.
The IPIP path keeps ulen as 0, so its existing 1400 - 20 = 1380 result
is unchanged.
Fixes: 508f744c0de3 ("ipvs: strip udp tunnel headers from icmp errors")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
Changes in v2:
- Use the short first hunk context so patch applies without fuzz.
- Adjust Assisted-by to checkpatch's agent-name format.
- Suggested by Julian.
- Link to v1: https://lore.kernel.org/netdev/20260701065941.46249-1-zhaoyz24@mails.tsinghua.edu.cn/
---
net/netfilter/ipvs/ip_vs_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d40b404c1bf6..906f2c361676 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1767,6 +1767,7 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
bool tunnel, new_cp = false;
union nf_inet_addr *raddr;
char *outer_proto = "IPIP";
+ int ulen = 0;
*related = 1;
@@ -1831,7 +1832,6 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
/* Error for our tunnel must arrive at LOCAL_IN */
(skb_rtable(skb)->rt_flags & RTCF_LOCAL)) {
__u8 iproto;
- int ulen;
/* Non-first fragment has no UDP/GRE header */
if (unlikely(cih->frag_off & htons(IP_OFFSET)))
@@ -1936,8 +1936,8 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
if (dest_dst)
mtu = dst_mtu(dest_dst->dst_cache);
}
- if (mtu > 68 + sizeof(struct iphdr))
- mtu -= sizeof(struct iphdr);
+ if (mtu > 68 + sizeof(struct iphdr) + ulen)
+ mtu -= sizeof(struct iphdr) + ulen;
info = htonl(mtu);
}
/* Strip outer IP, ICMP and IPIP/UDP/GRE, go to IP header of
^ 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