* Re: [PATCH net-next v2 10/11] net: airoha: Do not stop GDM port if it is shared
From: Lorenzo Bianconi @ 2026-04-03 10:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260403011229.1785808-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: airoha: Do not stop GDM port if it is shared
>
> This patch introduces a port->users reference counter to prevent setting
> the GDM port forward configuration to FE_PSE_PORT_DROP if another net_device
> is still using the shared GDM port.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index 0780fb8aacfb..3f9bce8c5370 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> [ ... ]
> > @@ -1681,9 +1682,6 @@ static int airoha_dev_stop(struct net_device *netdev)
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> > netdev_tx_reset_subqueue(netdev, i);
> >
> > - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> > - FE_PSE_PORT_DROP);
> > -
> > if (atomic_dec_and_test(&qdma->users)) {
> > airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> > GLOBAL_CFG_TX_DMA_EN_MASK |
>
> While this patch aims to support shared GDM ports, does the remaining
> unconditional call to airoha_set_vip_for_gdm_port(dev, false) at the start
> of airoha_dev_stop() break other active devices sharing the port?
>
> static int airoha_dev_stop(struct net_device *netdev)
> {
> ...
> err = airoha_set_vip_for_gdm_port(dev, false);
> ...
> }
>
> This appears to clear the REG_FE_VIP_PORT_EN and REG_FE_IFC_PORT_EN hardware
> bits for the physical port, which might instantly kill traffic for any other
> active interface using the shared port.
>
> Similarly, in airoha_dev_open() and airoha_dev_change_mtu(), the
> REG_GDM_LEN_CFG (MTU) is overwritten unconditionally. If a device with a
> smaller MTU is brought up, will it overwrite the shared port's MTU limit
> and cause the hardware to silently drop larger packets for the other device?
ack, I will fix it in v3.
>
> [ ... ]
> > @@ -1697,6 +1695,11 @@ static int airoha_dev_stop(struct net_device *netdev)
> > }
> > }
> >
> > + if (atomic_dec_and_test(&port->users))
> > + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> > + REG_GDM_FWD_CFG(port->id),
> > + FE_PSE_PORT_DROP);
> > +
> > return 0;
> > }
>
> Does moving this FE_PSE_PORT_DROP configuration to the end of airoha_dev_stop()
> cause a race condition when stopping the device?
>
> In airoha_dev_open(), the driver correctly enables the QDMA engine before
> configuring the GDM port to forward packets. A safe teardown typically
> mirrors this by first stopping the packet source (setting FE_PSE_PORT_DROP)
> and then disabling the destination DMA engine.
>
> By moving airoha_set_gdm_port_fwd_cfg() after the airoha_qdma_clear() block,
> when both qdma->users and port->users reach zero, the QDMA engine and its
> queues are shut down while the GDM port is still actively forwarding packets.
>
> Could incoming packets be forwarded to a disabled DMA engine during this
> window, risking hardware lockups or buffer leaks?
ack, I will fix it in v3.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 5/5] selftests: net: bridge: add tests for igmpv3 MRC and QQIC validation
From: Ido Schimmel @ 2026-04-03 10:19 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <CAE2MWkn3gPc1kBwy2p7r5bx6QozMStM0N6oEutT7g7GnJrKteA@mail.gmail.com>
On Fri, Apr 03, 2026 at 01:20:49PM +0530, Ujjal Roy wrote:
> On Tue, Mar 31, 2026 at 7:44 PM Ido Schimmel <idosch@nvidia.com> wrote:
> >
> > On Mon, Mar 30, 2026 at 07:16:11PM +0000, Ujjal Roy wrote:
> > > Add bridge selftests that configure IGMPv3 parameters and validate the
> > > resulting Query packet fields for Max Resp Code (MRC) and Querier Query
> > > Interval Code (QQIC).
> > >
> > > This also adds helper binary to encode floating-point exponential fields.
> > >
> > > Future extensions may cover corresponding IPv6 cases.
> >
> > Please cover both IGMPv3 and MLDv2 since the patchset touches both. You
> > can add the MLDv2 tests in bridge_mld.sh.
> >
> > Also, I think you can simplify the test by simply matching on the
> > expected values of MRC and QQIC using tc-u32.
> >
> > For both IGMPv3 and MLDv2 please test both:
> >
> > * MRC and QQIC in linear range.
> > * MRC and QQIC in non-linear range.
> >
> > And please make sure the new test cases don't add new shellcheck
> > warnings / errors or it will fail in the CI. You can ignore existing
> > ones.
>
> I will upgrade the existing test cases in file bridge_vlan_mcast.sh
> instead of the previous file (bridge_igmp/mld.sh).
Is there a reason to place them in bridge_vlan_mcast.sh given they are
not specific to the per-VLAN multicast context? bridge_{igmp,mld}.sh
looks like a better fit.
>
> I have some doubts on test case logs reporting. Below are the logs
> without my patchset. API used vlmc_query_intvl_test() and
> vlmc_query_response_intvl_test().
> TEST: Vlan mcast_query_interval global option default value [ OK ]
> TEST: Vlan 10 mcast_query_interval option changed to 200 [ OK ]
> TEST: Vlan mcast_query_response_interval global option default value [ OK ]
> TEST: Vlan 10 mcast_query_response_interval option changed to 200 [ OK ]
>
> I am expecting some suggestions from the logs below. And are these
> covers both IGMPv3 and MLDv2 for QQIC and MRC?
> Actually mcast_query_interval=QQIC and
> mcast_query_response_interval=MRC we already know.
Not sure what you are asking. My request was to have test cases for both
MRC and QQIC, for both IGMPv3 and MLDv2.
>
> TEST: Vlan mcast_query_interval global option default value [ OK ]
> TEST: Vlan 10 mcast_query_interval option changed to 200 [ OK ]
> TEST: Vlan 10 mcast_query_interval number of IGMPv2 general query [
> OK ] -> old case added log
> TEST: Vlan 10 mcast_query_interval option changed to 6000 [ OK ]
> TEST: Vlan 10 mcast_query_interval in IGMPv3 is 60 [ OK ]
> TEST: Vlan 10 mcast_query_interval in MLDv2 is 60 [ OK ]
> TEST: Vlan 10 mcast_query_interval option changed to 16000 [ OK ]
> TEST: Vlan 10 mcast_query_interval in IGMPv3 is 160 [ OK ]
> TEST: Vlan 10 mcast_query_interval in MLDv2 is 160 [ OK ]
> TEST: Vlan mcast_query_response_interval global option default value [ OK ]
> TEST: Vlan 10 mcast_query_response_interval option changed to 600 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval in IGMPv3 is 60 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval option changed to 1600 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval in IGMPv3 is 160 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval option changed to 3000 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval in MLDv2 is 30000 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval option changed to 6000 [ OK ]
> TEST: Vlan 10 mcast_query_response_interval in MLDv2 is 60000 [ OK ]
>
> Or is it better to name them properly instead of mcast option names, like below?
>
> Vlan 10 mcast_query_interval:
> TEST: Number of tagged IGMPv2 general query [ OK ]
> TEST: IGMPv3 QQIC linear value 60 [ OK ]
> TEST: IGMPv3 QQIC non linear value 160 [ OK ]
> TEST: MLDv2 QQIC linear value 60 [ OK ]
> TEST: MLDv2 QQIC non linear value 160 [ OK ]
I find the latter clearer.
^ permalink raw reply
* [PATCH iproute2-next] ss: add support for TCP delack timers
From: Eric Dumazet @ 2026-04-03 10:23 UTC (permalink / raw)
To: David Ahern, Stephen Hemminger
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Neal Cardwell,
Kuniyuki Iwashima, netdev, eric.dumazet, Eric Dumazet
Kernel commit c698f5cc940d ("inet_diag: report delayed ack timer information")
added a new enum for idiag_timer values and support for delayed ack timers.
Change tcp_timer_print() to use the new enum and display "delack"
instead of "unknown":
tt -to
...
ESTAB 10 0 [2002:a05:6830:1f86::]:12875 [2002:a05:6830:1f85::]:50438
timer:(delack,003ms,0) ino:152178 sk:3004 cgroup:unreachable:189 <->
skmem:(r1344,rb12780520,t0,tb262144,f2752,w0,o250,bl0,d0) ts usec_ts
...
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
misc/ss.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index b3566f6b6b81427609829720496e80bea7cfeef7..1ea804ad549e23f767633e07efdd9adf1277af18 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2765,21 +2765,23 @@ static void tcp_stats_print(struct tcpstat *s)
static void tcp_timer_print(struct tcpstat *s)
{
static const char * const tmr_name[] = {
- "off",
- "on",
- "keepalive",
- "timewait",
- "persist",
- "unknown"
+ [IDIAG_TIMER_OFF] = "off",
+ [IDIAG_TIMER_ON] = "on",
+ [IDIAG_TIMER_KEEPALIVE] = "keepalive",
+ [IDIAG_TIMER_TIMEWAIT] = "timewait",
+ [IDIAG_TIMER_PROBE0] = "persist",
+ [IDIAG_TIMER_DELACK] = "delack",
};
if (s->timer) {
- if (s->timer > 4)
- s->timer = 5;
- out(" timer:(%s,%s,%d)",
- tmr_name[s->timer],
- print_ms_timer(s->timeout),
- s->retrans);
+ const char *name;
+
+ if (s->timer >= ARRAY_SIZE(tmr_name))
+ name = "unknown";
+ else
+ name = tmr_name[s->timer];
+ out(" timer:(%s,%s,%d)", name,
+ print_ms_timer(s->timeout), s->retrans);
}
}
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH net-next] psp: add missing device stats to get-stats reply attributes
From: Daniel Zahka @ 2026-04-03 10:26 UTC (permalink / raw)
To: Jakub Kicinski, Willem de Bruijn, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Donald Hunter
Cc: netdev, linux-kernel
Commit f05d26198cf2 ("psp: add stats from psp spec to driver facing
api") added device statistics (rx-packets, rx-bytes, rx-auth-fail,
rx-error, rx-bad, tx-packets, tx-bytes, tx-error) to the stats
attribute-set but did not add them to the get-stats operation reply
attributes. The kernel reports these attributes in the reply, so
list them in the spec to match.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
---
This is a small fix to add the rest of the PSP hw stats from Commit
f05d26198cf2 ("psp: add stats from psp spec to driver facing api") to
the get-stats reply attributes.
The pyynl cli tool does not use these attributes for parsing
responses, but other tools, like the ynl-cpp tool, do.
---
Documentation/netlink/specs/psp.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/netlink/specs/psp.yaml b/Documentation/netlink/specs/psp.yaml
index f3a57782d2cf..100c36cda8e5 100644
--- a/Documentation/netlink/specs/psp.yaml
+++ b/Documentation/netlink/specs/psp.yaml
@@ -267,6 +267,14 @@ operations:
- dev-id
- key-rotations
- stale-events
+ - rx-packets
+ - rx-bytes
+ - rx-auth-fail
+ - rx-error
+ - rx-bad
+ - tx-packets
+ - tx-bytes
+ - tx-error
pre: psp-device-get-locked
post: psp-device-unlock
dump:
---
base-commit: 269389ba539834ec80e4d55583fca2cd70e4dc9c
change-id: 20260402-psp-yaml-fix-20661f0af865
Best regards,
--
Daniel Zahka <daniel.zahka@gmail.com>
^ permalink raw reply related
* Re: [PATCH net-next v2 5/5] selftests: net: bridge: add tests for igmpv3 MRC and QQIC validation
From: Ujjal Roy @ 2026-04-03 10:31 UTC (permalink / raw)
To: Ido Schimmel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260403101944.GA66518@shredder>
On Fri, Apr 3, 2026 at 3:49 PM Ido Schimmel <idosch@nvidia.com> wrote:
>
[...]
>
> Is there a reason to place them in bridge_vlan_mcast.sh given they are
> not specific to the per-VLAN multicast context? bridge_{igmp,mld}.sh
> looks like a better fit.
I could see the framework is ready to validate using
bridge_vlan_mcast.sh script. Just had to apply a new tc rule to
validate QEURY+MRC/QQIC fields. Something like this.
tc filter add dev $dev egress pref 10 prot 802.1Q \
flower vlan_id 10 vlan_ethtype ipv4 dst_ip
224.0.0.1 ip_proto 2 \
+ action continue
+ # AND Type 0x11 (Query) at offset 24 after IP
+ # IP (20 byte IP + 4 bytes Option)
+ tc filter add dev $dev egress pref 20 prot 802.1Q u32 \
+ match u8 0x11 0xff at 24 $intvl_match \
action pass
And writing a few lines will validate the test for IGMPv3 QQIC non
linear value of 160s.
+ RET=0
+ bridge vlan global set vid 10 dev br0 mcast_snooping 1
mcast_query_interval 16000
+ check_err $? "Could not set mcast_query_interval in vlan 10"
+ log_test "Vlan 10 mcast_query_interval option changed to 16000"
+ # 1 is sent immediately, IGMPv3 QQIC should match with non
linear value 160s
+ vlmc_check_query igmp 3 $swp1 1 1 160
+ check_err $? "Wrong QQIC in sent tagged IGMPv3 general queries"
+ log_test "Vlan 10 mcast_query_interval in IGMPv3 is 160"
>
[...]
> > Vlan 10 mcast_query_interval:
> > TEST: Number of tagged IGMPv2 general query [ OK ]
> > TEST: IGMPv3 QQIC linear value 60 [ OK ]
> > TEST: IGMPv3 QQIC non linear value 160 [ OK ]
> > TEST: MLDv2 QQIC linear value 60 [ OK ]
> > TEST: MLDv2 QQIC non linear value 160 [ OK ]
>
> I find the latter clearer.
I thought so, hence asked which would be a better version of log.
Thanks for clearing it.
^ permalink raw reply
* [PATCH] net: use get_random_u32() for net_namespace hash_mix initialization
From: David Carlier @ 2026-04-03 10:36 UTC (permalink / raw)
To: 'David S . Miller', Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Christian Brauner, Kuniyuki Iwashima,
Jan Kara, Jeff Layton, Qiliang Yuan
Cc: netdev, David Carlier
Use get_random_u32() instead of get_random_bytes() to initialize
net->hash_mix. This is the preferred API for obtaining a single
random u32 value, as it returns the value directly rather than
writing through a pointer, and requires no size parameter.
Signed-off-by: David Carlier <devnexen@gmail.com>
---
net/core/net_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 1057d16d5dd2..deb8b2ec5674 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -411,7 +411,7 @@ static __net_init int preinit_net(struct net *net, struct user_namespace *user_n
ref_tracker_dir_init(&net->refcnt_tracker, 128, "net_refcnt");
ref_tracker_dir_init(&net->notrefcnt_tracker, 128, "net_notrefcnt");
- get_random_bytes(&net->hash_mix, sizeof(u32));
+ net->hash_mix = get_random_u32();
net->dev_base_seq = 1;
net->user_ns = user_ns;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Umang Chheda @ 2026-04-03 10:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel, netdev
In-Reply-To: <7baeajhlqv6ujiqzmknjw3h6qr4mdw6qdywhaczm3c42pzjiue@nsgcbd4jsba5>
Hello Dmitry,
On 4/1/2026 5:06 PM, Dmitry Baryshkov wrote:
> On Wed, Apr 01, 2026 at 12:14:42AM +0530, Umang Chheda wrote:
>> Introduce bindings for the monaco-evk-ac IoT board, which is
>> based on the monaco-ac (QCS8300-AC) SoC variant.
>
> If it is a different SoC SKU, should it be reflected in the SoC compat
> strings?
Monaco‑AC does not introduce any S/W differences compared to Monaco SoC
-- All IP blocks and bindings remain identical from S/W PoV, Hence
haven't included the SoC SKU in the SoC compat strings.
Hope this is okay ? Your view on this ?
>
>>
>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>> index ca880c105f3b..c76365a89687 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>> @@ -918,6 +918,7 @@ properties:
>> - enum:
>> - arduino,monza
>> - qcom,monaco-evk
>> + - qcom,monaco-evk-ac
>> - qcom,qcs8300-ride
>> - const: qcom,qcs8300
>>
>>
>> --
>> 2.34.1
>>
>
Thanks,
Umang
^ permalink raw reply
* Re: [PATCH net-next] inet: remove leftover EXPORT_SYMBOL()
From: Fernando Fernandez Mancera @ 2026-04-03 10:49 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, netdev, eric.dumazet
In-Reply-To: <20260402174430.2462800-1-edumazet@google.com>
On 4/2/26 7:44 PM, Eric Dumazet wrote:
> IPv6 is no longer a module, we no longer need to export these symbols.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/icmp.c | 4 ----
> net/ipv4/ipmr_base.c | 13 -------------
> net/ipv4/udp_offload.c | 4 ----
> 3 files changed, 21 deletions(-)
>
Thank you and sorry for missing this.
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
^ permalink raw reply
* Re: [PATCH net-next] inet: remove leftover EXPORT_SYMBOL()
From: Eric Dumazet @ 2026-04-03 10:59 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, netdev, eric.dumazet
In-Reply-To: <4677d96d-3509-4bf3-855d-b3e0bd956722@suse.de>
On Fri, Apr 3, 2026 at 3:49 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> On 4/2/26 7:44 PM, Eric Dumazet wrote:
> > IPv6 is no longer a module, we no longer need to export these symbols.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > ---
> > net/ipv4/icmp.c | 4 ----
> > net/ipv4/ipmr_base.c | 13 -------------
> > net/ipv4/udp_offload.c | 4 ----
> > 3 files changed, 21 deletions(-)
> >
> Thank you and sorry for missing this.
>
> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
No worries, these were not using EXPORT_IPV6_MOD[_GPL]() yet.
Thanks !
^ permalink raw reply
* [PATCH] net/sched: act_nat: fix inner IP header checksum in ICMP error packets
From: David Carlier @ 2026-04-03 11:02 UTC (permalink / raw)
To: 'David S . Miller', Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Herbert Xu
Cc: netdev, David Carlier, stable
Update the inner IP header checksum when rewriting addresses
inside ICMP error payloads, matching netfilter's nf_nat_ipv4_manip_pkt()
behavior.
Fixes: b4219952356b ("[PKT_SCHED]: Add stateless NAT")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
net/sched/act_nat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
index abb332dee836..cd1d299da57c 100644
--- a/net/sched/act_nat.c
+++ b/net/sched/act_nat.c
@@ -242,7 +242,9 @@ TC_INDIRECT_SCOPE int tcf_nat_act(struct sk_buff *skb,
new_addr &= mask;
new_addr |= addr & ~mask;
- /* XXX Fix up the inner checksums. */
+ /* Update inner IP header checksum after address rewrite */
+ csum_replace4(&iph->check, addr, new_addr);
+
if (egress)
iph->daddr = new_addr;
else
--
2.53.0
^ permalink raw reply related
* Re: commit 0c4f1c02d27a880b cause a deadlock issue
From: He, Guocai (CN) @ 2026-04-03 11:08 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: miriam.rachel.korenblit@intel.com, johannes.berg@intel.com,
Friend, Linux kernel regressions list
In-Reply-To: <14d65103-8809-4a1b-b115-bf5f8d7110ea@leemhuis.info>
No, The mainline have no this issue.
The changes of 0c4f1c02d27a880b is not in mainline.
Thanks
Guocai
________________________________________
From: Thorsten Leemhuis <regressions@leemhuis.info>
Sent: Thursday, April 2, 2026 4:56 PM
To: He, Guocai (CN)
Cc: miriam.rachel.korenblit@intel.com; johannes.berg@intel.com; Friend; Linux kernel regressions list
Subject: Re: commit 0c4f1c02d27a880b cause a deadlock issue
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.
On 4/1/26 04:28, He, Guocai (CN) wrote:
> Johannes and Miriam and all:
>
> when we test on kernel 6.1.166, find a deadlock caused by commit
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c4f1c02d27a880b10b58c63f574f13bed4f711d
Does this problem happen with 6.19/7.0-rc6 as well? That is an important
detail to know if this is a general problem (that needs to be fixed in
mainline) or something the backport caused (which mainline developers
might not care about, as that is the domain of the stable team).
Ciao, Thorsten
> test by command "rtcwake -m mem -s 10"
> It will hang (detail please see the attached test.log file )
>
> I revert this commit and it works.
>
> #my analysis:
>
> This creates the following call chain:
> wiphy_suspend()
> cfg80211_leave_all()
> cfg80211_leave() # takes wdev->mtx <- LOCK #1
> __cfg80211_leave()
> cfg80211_stop_p2p_device() # <- NEW from 0c4f1c02d27a
> ieee80211_stop_p2p_device() # mac80211 callback
> ieee80211_sdata_stop()
> ieee80211_do_stop()
> sdata_lock(sdata) # = mutex_lock(&sdata->wdev.mtx)
> <- LOCK #2, SAME mutex!
> DEADLOCK
>
>
> In 6.1.x:
> cfg80211_leave define as:
> wdev_lock(wdev);
> __cfg80211_leave(rdev, wdev);
> wdev_unlock(wdev);
>
> but upstream, __cfg80211_leave is renamed to cfg80211_leave.
> call cfg80211_leave directly. so have no this issue.
>
> Do anybody meets this issue too?
>
>
> Thanks very much.
>
> Guocai
^ permalink raw reply
* [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Ovidiu Panait @ 2026-04-03 11:17 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni,
biju.das.jz
Cc: netdev, linux-kernel, linux-renesas-soc, Ovidiu Panait
During system suspend, phy_suspend() puts the PHY into Software Power-Down
(SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to the KSZ9131
datasheet, MMD register access is restricted during SPD:
- Only access to the standard registers (0 through 31) is supported.
- Access to MMD address spaces other than MMD address space 1 is
possible if the spd_clock_gate_override bit is set.
- Access to MMD address space 1 is not possible.
However, ksz9131_resume() calls ksz9131_config_rgmii_delay() before
kszphy_resume() clears BMCR_PDOWN. This means MMD registers are accessed
while the PHY is still in SPD, contrary to the datasheet.
Additionally, on platforms where the PHY loses power during suspend
(e.g. RZ/G3E), all settings from ksz9131_config_init(), not just the
RGMII delays, are lost and need to be restored. When the MAC driver
sets mac_managed_pm (e.g. stmmac), mdio_bus_phy_resume() is skipped,
so phy_init_hw() (which calls config_init to restore all PHY settings)
is never invoked during resume.
Fix this by replacing the RGMII delay restoration with a call to
phy_init_hw(), which takes the PHY out of SPD and performs full
reinitialization.
Fixes: f25a7eaa897f ("net: phy: micrel: Add ksz9131_resume()")
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
---
drivers/net/phy/micrel.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 2aa1dedd21b8..4236dbf4ad6b 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -6016,8 +6016,13 @@ static int lan8841_suspend(struct phy_device *phydev)
static int ksz9131_resume(struct phy_device *phydev)
{
- if (phydev->suspended && phy_interface_is_rgmii(phydev))
- ksz9131_config_rgmii_delay(phydev);
+ int ret;
+
+ if (phydev->suspended) {
+ ret = phy_init_hw(phydev);
+ if (ret)
+ return ret;
+ }
return kszphy_resume(phydev);
}
--
2.51.0
^ permalink raw reply related
* Re: commit 0c4f1c02d27a880b cause a deadlock issue
From: Greg KH @ 2026-04-03 11:27 UTC (permalink / raw)
To: He, Guocai (CN)
Cc: Thorsten Leemhuis, miriam.rachel.korenblit@intel.com,
johannes.berg@intel.com, Friend, Linux kernel regressions list
In-Reply-To: <CO6PR11MB5586DF3964BAB4E6131A86CDCD5EA@CO6PR11MB5586.namprd11.prod.outlook.com>
On Fri, Apr 03, 2026 at 11:08:46AM +0000, He, Guocai (CN) wrote:
> No, The mainline have no this issue.
> The changes of 0c4f1c02d27a880b is not in mainline.
That does not make sense, that commit is really commit e1696c8bd005
("wifi: cfg80211: stop NAN and P2P in cfg80211_leave") which is in all
of the following releases:
5.10.252 5.15.202 6.1.165 6.6.128 6.12.75 6.18.14 6.19.4 7.0-rc1
confused,
greg k-h
^ permalink raw reply
* [PATCH net-next 0/5] mptcp: support MSG_EOR and small cleanups
From: Matthieu Baerts (NGI0) @ 2026-04-03 11:29 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Gang Yan,
Neal Cardwell, Kuniyuki Iwashima, David Ahern, Shuah Khan,
linux-kselftest, Geliang Tang
This series contains various unrelated patches:
- Patches 1 & 2: support MSG_EOR instead of ignoring it.
- Patch 3: avoid duplicated code in TCP and MPTCP by using a new helper.
- Patch 4: remove duplicated condition.
- Patch 5: adapt test to reproduce bug and increase code coverage.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Gang Yan (2):
mptcp: reduce 'overhead' from u16 to u8
mptcp: preserve MSG_EOR semantics in sendmsg path
Geliang Tang (1):
tcp: add recv_should_stop helper
Matthieu Baerts (NGI0) (2):
mptcp: pm: in-kernel: remove mptcp_pm_has_addr_attr_id
selftests: mptcp: join: recreate signal endp with same ID
include/net/tcp.h | 8 +++++
net/ipv4/tcp.c | 9 ++----
net/mptcp/pm_kernel.c | 24 +++------------
net/mptcp/protocol.c | 41 ++++++++++++++++++-------
net/mptcp/protocol.h | 3 +-
tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 +--
6 files changed, 49 insertions(+), 40 deletions(-)
---
base-commit: 8b0e64d6c9e7feec5ba5643b4fa8b7fd54464778
change-id: 20260403-net-next-mptcp-msg_eor-misc-6b4567dd37dc
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* [PATCH net-next 1/5] mptcp: reduce 'overhead' from u16 to u8
From: Matthieu Baerts (NGI0) @ 2026-04-03 11:29 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Gang Yan
In-Reply-To: <20260403-net-next-mptcp-msg_eor-misc-v1-0-b0b33bea3fed@kernel.org>
From: Gang Yan <yangang@kylinos.cn>
The 'overhead' in struct mptcp_data_frag can safely use u8, as it
represents 'alignment + sizeof(mptcp_data_frag)'. With a maximum
alignment of 7('ALIGN(1, sizeof(long)) - 1'), the overhead is at most
47, well below U8_MAX and validated with BUILD_BUG_ON().
This patch also adds a field named 'unused' for further extensions.
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.c | 6 ++++++
net/mptcp/protocol.h | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 239fb9e75c7c..79315e575d07 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -4616,6 +4616,12 @@ void __init mptcp_proto_init(void)
inet_register_protosw(&mptcp_protosw);
BUILD_BUG_ON(sizeof(struct mptcp_skb_cb) > sizeof_field(struct sk_buff, cb));
+
+ /* struct mptcp_data_frag: 'overhead' corresponds to the alignment
+ * (ALIGN(1, sizeof(long)) - 1, so 8-1) + the struct's size
+ */
+ BUILD_BUG_ON(ALIGN(1, sizeof(long)) - 1 + sizeof(struct mptcp_data_frag)
+ > U8_MAX);
}
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 0bd1ee860316..02031007100b 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -263,7 +263,8 @@ struct mptcp_data_frag {
u64 data_seq;
u16 data_len;
u16 offset;
- u16 overhead;
+ u8 overhead;
+ u8 __unused;
u16 already_sent;
struct page *page;
};
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 2/5] mptcp: preserve MSG_EOR semantics in sendmsg path
From: Matthieu Baerts (NGI0) @ 2026-04-03 11:29 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Gang Yan
In-Reply-To: <20260403-net-next-mptcp-msg_eor-misc-v1-0-b0b33bea3fed@kernel.org>
From: Gang Yan <yangang@kylinos.cn>
Extend MPTCP's sendmsg handling to recognize and honor the MSG_EOR flag,
which marks the end of a record for application-level message boundaries.
Data fragments tagged with MSG_EOR are explicitly marked in the
mptcp_data_frag structure and skb context to prevent unintended
coalescing with subsequent data chunks. This ensures the intent of
applications using MSG_EOR is preserved across MPTCP subflows,
maintaining consistent message segmentation behavior.
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.c | 24 +++++++++++++++++++++---
net/mptcp/protocol.h | 2 +-
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 79315e575d07..e21e416cd19a 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -1005,7 +1005,8 @@ static bool mptcp_frag_can_collapse_to(const struct mptcp_sock *msk,
const struct page_frag *pfrag,
const struct mptcp_data_frag *df)
{
- return df && pfrag->page == df->page &&
+ return df && !df->eor &&
+ pfrag->page == df->page &&
pfrag->size - pfrag->offset > 0 &&
pfrag->offset == (df->offset + df->data_len) &&
df->data_seq + df->data_len == msk->write_seq;
@@ -1147,6 +1148,7 @@ mptcp_carve_data_frag(const struct mptcp_sock *msk, struct page_frag *pfrag,
dfrag->offset = offset + sizeof(struct mptcp_data_frag);
dfrag->already_sent = 0;
dfrag->page = pfrag->page;
+ dfrag->eor = 0;
return dfrag;
}
@@ -1408,6 +1410,13 @@ static int mptcp_sendmsg_frag(struct sock *sk, struct sock *ssk,
mptcp_update_infinite_map(msk, ssk, mpext);
trace_mptcp_sendmsg_frag(mpext);
mptcp_subflow_ctx(ssk)->rel_write_seq += copy;
+
+ /* if this is the last chunk of a dfrag with MSG_EOR set,
+ * mark the skb to prevent coalescing with subsequent data.
+ */
+ if (dfrag->eor && info->sent + copy >= dfrag->data_len)
+ TCP_SKB_CB(skb)->eor = 1;
+
return copy;
}
@@ -1868,7 +1877,8 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
long timeo;
/* silently ignore everything else */
- msg->msg_flags &= MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL | MSG_FASTOPEN;
+ msg->msg_flags &= MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL |
+ MSG_FASTOPEN | MSG_EOR;
lock_sock(sk);
@@ -1975,8 +1985,16 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
goto do_error;
}
- if (copied)
+ if (copied) {
+ /* mark the last dfrag with EOR if MSG_EOR was set */
+ if (msg->msg_flags & MSG_EOR) {
+ struct mptcp_data_frag *dfrag = mptcp_pending_tail(sk);
+
+ if (dfrag)
+ dfrag->eor = 1;
+ }
__mptcp_push_pending(sk, msg->msg_flags);
+ }
out:
release_sock(sk);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 02031007100b..1208f317ac33 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -264,7 +264,7 @@ struct mptcp_data_frag {
u16 data_len;
u16 offset;
u8 overhead;
- u8 __unused;
+ u8 eor; /* currently using 1 bit */
u16 already_sent;
struct page *page;
};
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 3/5] tcp: add recv_should_stop helper
From: Matthieu Baerts (NGI0) @ 2026-04-03 11:29 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Neal Cardwell, Kuniyuki Iwashima, David Ahern, Geliang Tang
In-Reply-To: <20260403-net-next-mptcp-msg_eor-misc-v1-0-b0b33bea3fed@kernel.org>
From: Geliang Tang <tanggeliang@kylinos.cn>
Factor out a new helper tcp_recv_should_stop() from tcp_recvmsg_locked()
and tcp_splice_read() to check whether to stop receiving. And use this
helper in mptcp_recvmsg() and mptcp_splice_read() to reduce redundant code.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Neal Cardwell <ncardwell@google.com>
To: Kuniyuki Iwashima <kuniyu@google.com>
To: David Ahern <dsahern@kernel.org>
---
include/net/tcp.h | 8 ++++++++
net/ipv4/tcp.c | 9 ++-------
net/mptcp/protocol.c | 11 +++--------
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 565943c34b7e..6156d1d068e1 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -3077,4 +3077,12 @@ enum skb_drop_reason tcp_inbound_hash(struct sock *sk,
const void *saddr, const void *daddr,
int family, int dif, int sdif);
+static inline int tcp_recv_should_stop(struct sock *sk)
+{
+ return sk->sk_err ||
+ sk->sk_state == TCP_CLOSE ||
+ (sk->sk_shutdown & RCV_SHUTDOWN) ||
+ signal_pending(current);
+}
+
#endif /* _TCP_H */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index bd2c3c4587e1..e57eaffc007a 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -888,9 +888,7 @@ ssize_t tcp_splice_read(struct socket *sock, loff_t *ppos,
release_sock(sk);
lock_sock(sk);
- if (sk->sk_err || sk->sk_state == TCP_CLOSE ||
- (sk->sk_shutdown & RCV_SHUTDOWN) ||
- signal_pending(current))
+ if (tcp_recv_should_stop(sk))
break;
}
@@ -2755,10 +2753,7 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len,
if (copied) {
if (!timeo ||
- sk->sk_err ||
- sk->sk_state == TCP_CLOSE ||
- (sk->sk_shutdown & RCV_SHUTDOWN) ||
- signal_pending(current))
+ tcp_recv_should_stop(sk))
break;
} else {
if (sock_flag(sk, SOCK_DONE))
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index e21e416cd19a..2f4776a4f06a 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2333,11 +2333,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
break;
if (copied) {
- if (sk->sk_err ||
- sk->sk_state == TCP_CLOSE ||
- (sk->sk_shutdown & RCV_SHUTDOWN) ||
- !timeo ||
- signal_pending(current))
+ if (tcp_recv_should_stop(sk) ||
+ !timeo)
break;
} else {
if (sk->sk_err) {
@@ -4520,9 +4517,7 @@ static ssize_t mptcp_splice_read(struct socket *sock, loff_t *ppos,
release_sock(sk);
lock_sock(sk);
- if (sk->sk_err || sk->sk_state == TCP_CLOSE ||
- (sk->sk_shutdown & RCV_SHUTDOWN) ||
- signal_pending(current))
+ if (tcp_recv_should_stop(sk))
break;
}
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 4/5] mptcp: pm: in-kernel: remove mptcp_pm_has_addr_attr_id
From: Matthieu Baerts (NGI0) @ 2026-04-03 11:29 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0)
In-Reply-To: <20260403-net-next-mptcp-msg_eor-misc-v1-0-b0b33bea3fed@kernel.org>
There is no need to call this helper: it will check if the address ID
attribute is set, but this attribute has already been parsed previously.
Indeed, the value has been set in 'entry->addr.id' if it was set and
positive, which is what we were looking at. Then only looking at this
already parsed value is enough, not need to re-extract all Netlink
attributes again.
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/pm_kernel.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
index 82e59f9c6dd9..0ebf43be9939 100644
--- a/net/mptcp/pm_kernel.c
+++ b/net/mptcp/pm_kernel.c
@@ -720,7 +720,7 @@ static void __mptcp_pm_release_addr_entry(struct mptcp_pm_addr_entry *entry)
static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
struct mptcp_pm_addr_entry *entry,
- bool needs_id, bool replace)
+ bool replace)
{
struct mptcp_pm_addr_entry *cur, *del_entry = NULL;
int ret = -EINVAL;
@@ -779,7 +779,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
}
}
- if (!entry->addr.id && needs_id) {
+ if (!entry->addr.id) {
find_next:
entry->addr.id = find_next_zero_bit(pernet->id_bitmap,
MPTCP_PM_MAX_ADDR_ID + 1,
@@ -790,7 +790,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
}
}
- if (!entry->addr.id && needs_id)
+ if (!entry->addr.id)
goto out;
__set_bit(entry->addr.id, pernet->id_bitmap);
@@ -923,7 +923,7 @@ int mptcp_pm_nl_get_local_id(struct mptcp_sock *msk,
return -ENOMEM;
entry->addr.port = 0;
- ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, true, false);
+ ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, false);
if (ret < 0)
kfree(entry);
@@ -977,18 +977,6 @@ static int mptcp_nl_add_subflow_or_signal_addr(struct net *net,
return 0;
}
-static bool mptcp_pm_has_addr_attr_id(const struct nlattr *attr,
- struct genl_info *info)
-{
- struct nlattr *tb[MPTCP_PM_ADDR_ATTR_MAX + 1];
-
- if (!nla_parse_nested_deprecated(tb, MPTCP_PM_ADDR_ATTR_MAX, attr,
- mptcp_pm_address_nl_policy, info->extack) &&
- tb[MPTCP_PM_ADDR_ATTR_ID])
- return true;
- return false;
-}
-
/* Add an MPTCP endpoint */
int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info)
{
@@ -1037,9 +1025,7 @@ int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info)
goto out_free;
}
}
- ret = mptcp_pm_nl_append_new_local_addr(pernet, entry,
- !mptcp_pm_has_addr_attr_id(attr, info),
- true);
+ ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, true);
if (ret < 0) {
GENL_SET_ERR_MSG_FMT(info, "too many addresses or duplicate one: %d", ret);
goto out_free;
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 5/5] selftests: mptcp: join: recreate signal endp with same ID
From: Matthieu Baerts (NGI0) @ 2026-04-03 11:29 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Shuah Khan,
linux-kselftest
In-Reply-To: <20260403-net-next-mptcp-msg_eor-misc-v1-0-b0b33bea3fed@kernel.org>
In this "delete re-add signal" MPTCP Join subtest, the endpoint linked
to the initial subflow is removed, but readded once with different ID.
It appears that there was an issue when reusing the same ID, recently
fixed by commit d191101dee25 ("mptcp: pm: in-kernel: always set ID as
avail when rm endp"). The test then now reuses the same ID the first
time, but continue to use another one (88) the second time.
This should then cover more cases.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/615
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Shuah Khan <shuah@kernel.org>
Cc: linux-kselftest@vger.kernel.org
---
tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index a3144d7298a5..beec41f6662a 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -4343,13 +4343,13 @@ endpoint_tests()
chk_mptcp_info add_addr_signal 2 add_addr_accepted 2
[ ${ipt} = 1 ] && ip netns exec "${ns1}" ${iptables} -D OUTPUT 1
- pm_nl_add_endpoint $ns1 10.0.1.1 id 99 flags signal
+ pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal
wait_mpj 4
chk_subflow_nr "after re-add ID 0" 3
chk_mptcp_info subflows 3 subflows 3
chk_mptcp_info add_addr_signal 3 add_addr_accepted 2
- pm_nl_del_endpoint $ns1 99 10.0.1.1
+ pm_nl_del_endpoint $ns1 42 10.0.1.1
sleep 0.5
chk_subflow_nr "after re-delete ID 0" 2
chk_mptcp_info subflows 2 subflows 2
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] netfilter: xt_multiport: validate range encoding in checkentry
From: Pablo Neira Ayuso @ 2026-04-03 11:31 UTC (permalink / raw)
To: Ren Wei
Cc: netfilter-devel, netdev, fw, phil, davem, edumazet, kuba, pabeni,
horms, yasuyuki.kozakai, kaber, yifanwucs, tomapufckgml,
yuantan098, bird, z1652074432
In-Reply-To: <d5c0d106e724c732436b985dd694272bcb813bb1.1775153311.git.n05ec@lzu.edu.cn>
On Fri, Apr 03, 2026 at 02:21:17AM +0800, Ren Wei wrote:
> ports_match_v1() treats any non-zero pflags entry as the start of a
> port range and unconditionally consumes the next ports[] element as
> the range end.
>
> The checkentry path currently validates protocol, flags and count, but
> it does not validate the range encoding itself. As a result, malformed
> rules can mark the last slot as a range start or place two range starts
> back to back, leaving ports_match_v1() to step past the last valid
> ports[] element while interpreting the rule.
>
> Reject malformed multiport v1 rules in checkentry by validating that
> each range start has a following element and that the following element
> is not itself marked as another range start.
>
> Fixes: a89ecb6a2ef7 ("[NETFILTER]: x_tables: unify IPv4/IPv6 multiport match")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Yuhang Zheng <z1652074432@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> Changes in v2:
> - drop the selftest patch
> - send the fix publicly to netfilter-devel
>
> Changes in v3:
> - drop datatype cleanup from the fix
> - keep the original check() interface unchanged
> - validate malformed range encoding in checkentry
>
> net/netfilter/xt_multiport.c | 30 ++++++++++++++++++++++++++----
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/xt_multiport.c b/net/netfilter/xt_multiport.c
> index 44a00f5acde8..07a0f2a3fc75 100644
> --- a/net/netfilter/xt_multiport.c
> +++ b/net/netfilter/xt_multiport.c
> @@ -105,6 +105,24 @@ multiport_mt(const struct sk_buff *skb, struct xt_action_param *par)
> return ports_match_v1(multiinfo, ntohs(pptr[0]), ntohs(pptr[1]));
> }
>
> +static inline bool
> +multiport_valid_ranges(const struct xt_multiport_v1 *multiinfo)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < multiinfo->count; i++) {
> + if (!multiinfo->pflags[i])
> + continue;
> +
> + if (i + 1 >= multiinfo->count || multiinfo->pflags[i + 1])
> + return false;
> +
> + i++;
> + }
> +
> + return true;
> +}
I'd suggest:
static inline bool
multiport_valid_ranges(const struct xt_multiport_v1 *multiinfo)
{
unsigned int i;
for (i = 0; i < multiinfo->count; i++) {
if (!multiinfo->pflags[i])
continue;
if (++i >= multiinfo->count)
return false;
if (multiinfo->pflags[i])
return false;
if (multiinfo->ports[i - 1] > multiinfo->ports[i])
return false;
}
return true;
}
Then, this validate non-sense ports array too.
^ permalink raw reply
* Re: [PATCH] net: use get_random_u32() for net_namespace hash_mix initialization
From: Eric Dumazet @ 2026-04-03 11:34 UTC (permalink / raw)
To: David Carlier
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Christian Brauner, Kuniyuki Iwashima, Jan Kara, Jeff Layton,
Qiliang Yuan, netdev
In-Reply-To: <20260403103654.15304-1-devnexen@gmail.com>
On Fri, Apr 3, 2026 at 3:36 AM David Carlier <devnexen@gmail.com> wrote:
>
> Use get_random_u32() instead of get_random_bytes() to initialize
> net->hash_mix. This is the preferred API for obtaining a single
> random u32 value, as it returns the value directly rather than
> writing through a pointer, and requires no size parameter.
>
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
I feel a tree-wide patch could be attempted ?
Thanks.
^ permalink raw reply
* Re: [PATCH v3] netfilter: xt_multiport: validate range encoding in checkentry
From: Pablo Neira Ayuso @ 2026-04-03 11:38 UTC (permalink / raw)
To: Ren Wei
Cc: netfilter-devel, netdev, fw, phil, davem, edumazet, kuba, pabeni,
horms, yasuyuki.kozakai, kaber, yifanwucs, tomapufckgml,
yuantan098, bird, z1652074432
In-Reply-To: <ac-lHcg6NTg9sWGY@lemonverbena>
On Fri, Apr 03, 2026 at 01:31:41PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Apr 03, 2026 at 02:21:17AM +0800, Ren Wei wrote:
> > ports_match_v1() treats any non-zero pflags entry as the start of a
> > port range and unconditionally consumes the next ports[] element as
> > the range end.
> >
> > The checkentry path currently validates protocol, flags and count, but
> > it does not validate the range encoding itself. As a result, malformed
> > rules can mark the last slot as a range start or place two range starts
> > back to back, leaving ports_match_v1() to step past the last valid
> > ports[] element while interpreting the rule.
> >
> > Reject malformed multiport v1 rules in checkentry by validating that
> > each range start has a following element and that the following element
> > is not itself marked as another range start.
> >
> > Fixes: a89ecb6a2ef7 ("[NETFILTER]: x_tables: unify IPv4/IPv6 multiport match")
> > Reported-by: Yifan Wu <yifanwucs@gmail.com>
> > Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> > Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> > Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> > Suggested-by: Xin Liu <bird@lzu.edu.cn>
> > Tested-by: Yuhang Zheng <z1652074432@gmail.com>
> > Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> > ---
> > Changes in v2:
> > - drop the selftest patch
> > - send the fix publicly to netfilter-devel
> >
> > Changes in v3:
> > - drop datatype cleanup from the fix
> > - keep the original check() interface unchanged
> > - validate malformed range encoding in checkentry
> >
> > net/netfilter/xt_multiport.c | 30 ++++++++++++++++++++++++++----
> > 1 file changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/netfilter/xt_multiport.c b/net/netfilter/xt_multiport.c
> > index 44a00f5acde8..07a0f2a3fc75 100644
> > --- a/net/netfilter/xt_multiport.c
> > +++ b/net/netfilter/xt_multiport.c
> > @@ -105,6 +105,24 @@ multiport_mt(const struct sk_buff *skb, struct xt_action_param *par)
> > return ports_match_v1(multiinfo, ntohs(pptr[0]), ntohs(pptr[1]));
> > }
> >
> > +static inline bool
> > +multiport_valid_ranges(const struct xt_multiport_v1 *multiinfo)
> > +{
> > + unsigned int i;
> > +
> > + for (i = 0; i < multiinfo->count; i++) {
> > + if (!multiinfo->pflags[i])
> > + continue;
> > +
> > + if (i + 1 >= multiinfo->count || multiinfo->pflags[i + 1])
> > + return false;
> > +
> > + i++;
> > + }
> > +
> > + return true;
> > +}
>
> I'd suggest:
>
> static inline bool
Actually, inline is silly here, no inline here.
> multiport_valid_ranges(const struct xt_multiport_v1 *multiinfo)
> {
> unsigned int i;
>
> for (i = 0; i < multiinfo->count; i++) {
> if (!multiinfo->pflags[i])
> continue;
>
> if (++i >= multiinfo->count)
> return false;
>
> if (multiinfo->pflags[i])
> return false;
>
> if (multiinfo->ports[i - 1] > multiinfo->ports[i])
> return false;
> }
>
> return true;
> }
>
> Then, this validate non-sense ports array too.
You can also mention in the patch description that this leads to
off-by-one read after the array that is reported via UBSAN.
Thanks.
^ permalink raw reply
* Re: [PATCH] net/sched: act_nat: fix inner IP header checksum in ICMP error packets
From: Eric Dumazet @ 2026-04-03 11:38 UTC (permalink / raw)
To: David Carlier
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Herbert Xu, netdev, stable, Jamal Hadi Salim
In-Reply-To: <20260403110238.16596-1-devnexen@gmail.com>
On Fri, Apr 3, 2026 at 4:02 AM David Carlier <devnexen@gmail.com> wrote:
>
> Update the inner IP header checksum when rewriting addresses
> inside ICMP error payloads, matching netfilter's nf_nat_ipv4_manip_pkt()
> behavior.
>
> Fixes: b4219952356b ("[PKT_SCHED]: Add stateless NAT")
> Cc: stable@vger.kernel.org
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
> net/sched/act_nat.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
> index abb332dee836..cd1d299da57c 100644
> --- a/net/sched/act_nat.c
> +++ b/net/sched/act_nat.c
> @@ -242,7 +242,9 @@ TC_INDIRECT_SCOPE int tcf_nat_act(struct sk_buff *skb,
> new_addr &= mask;
> new_addr |= addr & ~mask;
>
> - /* XXX Fix up the inner checksums. */
> + /* Update inner IP header checksum after address rewrite */
> + csum_replace4(&iph->check, addr, new_addr);
> +
~20 years old code, are we sure this fix is needed?
How was this patch was tested?
A selftest would be great.
^ permalink raw reply
* Re: [PATCH net 2/2] vsock/test: add MSG_PEEK after partial recv test
From: Luigi Leonardi @ 2026-04-03 11:40 UTC (permalink / raw)
To: Stefano Garzarella
Cc: Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Arseniy Krasnov, kvm, virtualization,
netdev, linux-kernel
In-Reply-To: <ac5qWSEBM--HuKQK@sgarzare-redhat>
On Thu, Apr 02, 2026 at 03:28:25PM +0200, Stefano Garzarella wrote:
>On Thu, Apr 02, 2026 at 10:18:02AM +0200, Luigi Leonardi wrote:
>>Add a test that verifies MSG_PEEK works correctly after a partial
>>recv().
>>
>>This is to test a bug that was present in the `virtio_transport_stream_do_peek()`
>
>WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
>#11: This is to test a bug that was present in the
>`virtio_transport_stream_do_peek()`
>
oops, thanks :)
>>when computing the number of bytes to copy: After a partial read, the
>>peek function didn't take into consideration the number of bytes that
>>were already read. So peeking the whole buffer would cause a out-of-bounds read,
>>that resulted in a -EFAULT.
>>
>>This test does exactly this: do a partial recv on a buffer, then try to
>>peek the whole buffer content.
>>
>>Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>>---
>>tools/testing/vsock/vsock_test.c | 64 ++++++++++++++++++++++++++++++++++++++++
>>1 file changed, 64 insertions(+)
>>
>>diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
>>index 5bd20ccd9335caafe68e8b7a5d02a4deb3d2deec..308f9f8f30d22bec5aaa282356e400d8438fe321 100644
>>--- a/tools/testing/vsock/vsock_test.c
>>+++ b/tools/testing/vsock/vsock_test.c
>>@@ -346,6 +346,65 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
>> return test_msg_peek_server(opts, false);
>>}
>>
>>+#define PEEK_AFTER_RECV_LEN 100
>
>Why 100 ?
>Better to use a power of 2 IMO like we do in all other cases IIRC.
>
Right, I'll reuse `MSG_PEEK_BUF_LEN`.
>>+
>>+static void test_stream_peek_after_recv_client(const struct test_opts *opts)
>>+{
>>+ unsigned char buf[PEEK_AFTER_RECV_LEN];
>>+ int fd;
>>+ int i;
>
>nit: int fd, i;
>
>>+
>>+ fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
>>+ if (fd < 0) {
>>+ perror("connect");
>>+ exit(EXIT_FAILURE);
>>+ }
>>+
>>+ for (i = 0; i < sizeof(buf); i++)
>>+ buf[i] = (unsigned char)i;
>
>Why setting the payload in this way ? Can we just do a memset() ?
Good point.
>
>>+
>>+ control_expectln("SRVREADY");
>
>Why we need this barrier ?
leftover from development, will remove.
>
>>+
>>+ send_buf(fd, buf, sizeof(buf), 0, sizeof(buf));
>>+
>>+ close(fd);
>>+}
>>+
>>+static void test_stream_peek_after_recv_server(const struct test_opts *opts)
>>+{
>>+ unsigned char buf[PEEK_AFTER_RECV_LEN];
>>+ int half = PEEK_AFTER_RECV_LEN / 2;
>>+ ssize_t ret;
>>+ int fd;
>>+
>>+ fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
>>+ if (fd < 0) {
>>+ perror("accept");
>>+ exit(EXIT_FAILURE);
>>+ }
>>+
>>+ control_writeln("SRVREADY");
>>+
>>+ /* Partial recv to advance offset within the skb */
>>+ recv_buf(fd, buf, half, 0, half);
>
>Why reading half of the size ?
>
>IMO is better to read just 1 byte, since it is almost certain that an
>skb does not have a 1-byte payload.
>
will do
>>+
>>+ /* Try to peek more than what remains: should return only 'half'
>
>How we are sure that the sender sent all the bytes ?
>
>>+ * bytes. Note: we can't use recv_buf() because it loops until
>>+ * all requested bytes are returned.
>
>Why this is a problem ? (an useful comment should explain the reason)
>
Some changes are required to `recv_buf`, I have a working v2 version
that uses that. Thanks for the hint.
>>+ */
>>+ ret = recv(fd, buf, sizeof(buf), MSG_PEEK);
>>+ if (ret < 0) {
>
>Should we handle EINTR like we do in recv_buf() ?
>But I still don't understand why we can't use it directly.
>
>Thanks,
>Stefano
>
>>+ perror("recv");
>>+ exit(EXIT_FAILURE);
>>+ } else if (ret != half) {
>>+ fprintf(stderr, "MSG_PEEK after partial recv returned %d (expected %d)\n",
>>+ ret, half);
>>+ exit(EXIT_FAILURE);
>>+ }
>>+
>>+ close(fd);
>>+}
>>+
>>#define SOCK_BUF_SIZE (2 * 1024 * 1024)
>>#define SOCK_BUF_SIZE_SMALL (64 * 1024)
>>#define MAX_MSG_PAGES 4
>>@@ -2520,6 +2579,11 @@ static struct test_case test_cases[] = {
>> .run_client = test_stream_tx_credit_bounds_client,
>> .run_server = test_stream_tx_credit_bounds_server,
>> },
>>+ {
>>+ .name = "SOCK_STREAM MSG_PEEK after partial recv",
>>+ .run_client = test_stream_peek_after_recv_client,
>>+ .run_server = test_stream_peek_after_recv_server,
>>+ },
>> {},
>>};
>>
>>
>>--
>>2.53.0
>>
>
^ permalink raw reply
* Re: [PATCH] net: use get_random_u32() for net_namespace hash_mix initialization
From: David CARLIER @ 2026-04-03 11:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Christian Brauner, Kuniyuki Iwashima, Jan Kara, Jeff Layton,
Qiliang Yuan, netdev
In-Reply-To: <CANn89iL-4-JBQLsumT_XGv6DYXUWtgKHYKVztec1pj3w8ksuDQ@mail.gmail.com>
Sure !
On Fri, 3 Apr 2026 at 12:34, Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Apr 3, 2026 at 3:36 AM David Carlier <devnexen@gmail.com> wrote:
> >
> > Use get_random_u32() instead of get_random_bytes() to initialize
> > net->hash_mix. This is the preferred API for obtaining a single
> > random u32 value, as it returns the value directly rather than
> > writing through a pointer, and requires no size parameter.
> >
> > Signed-off-by: David Carlier <devnexen@gmail.com>
> > ---
>
> I feel a tree-wide patch could be attempted ?
>
> Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox