* Re: [PATCH bpf v3 0/2] bpf, sockmap: Fix FIONREAD for sockets without a verdict program
From: patchwork-bot+netdevbpf @ 2026-07-15 9:20 UTC (permalink / raw)
To: Mattia Meleleo
Cc: bpf, netdev, john.fastabend, jakub, jiayuan.chen, memxor, emil
In-Reply-To: <20260708-fionread-no-verdict-v3-0-b4ee31b3af53@coralogix.com>
Hello:
This series was applied to bpf/bpf.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
On Wed, 08 Jul 2026 18:54:59 +0200 you wrote:
> Sockets added to a sockmap/sockhash with no stream/skb verdict program
> attached answer FIONREAD with 0 even when unread data is pending in
> sk_receive_queue. Fix tcp_bpf_ioctl() to account for the receive queue
> in that case, and add a selftest.
>
> Changes in v3:
> - Remove unused sk_psock_msg_inq()
> - Link to v2: https://patch.msgid.link/20260708-fionread-no-verdict-v2-0-29dd293621c7@coralogix.com
>
> [...]
Here is the summary with links:
- [bpf,v3,1/2] bpf, sockmap: Account for receive queue in FIONREAD without a verdict program
https://git.kernel.org/bpf/bpf/c/04af4efde58a
- [bpf,v3,2/2] selftests/bpf: Test FIONREAD on a sockmap socket without a verdict program
https://git.kernel.org/bpf/bpf/c/a42f05cc4c1d
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] net/mlx5: Use unique names for software steering caches
From: Yevgeny Kliteynik @ 2026-07-15 9:19 UTC (permalink / raw)
To: Leon Romanovsky, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alex Vesker
Cc: netdev, linux-rdma, linux-kernel, Christian Borntraeger
In-Reply-To: <20260715-kmem-dupliate-name-v1-1-85551c328155@nvidia.com>
On 15-Jul-26 11:22, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Each software steering domain creates its own slab caches, but all
> domains use the same names. When domains for two devices are alive at
> once, the second kmem_cache_create() triggers the following splat:
>
> WARNING: mm/slab_common.c:111 at __kmem_cache_create_args+0xca/0x480, CPU#18: devlink/331372
> Modules linked in: act_mirred act_skbedit cls_matchall act_gact cls_flower sch_ingress
> vhost_vdpa veth nfnetlink_cttimeout openvswitch macvtap macvlan vfio_ap kvm nf_nat_tftp
> nf_conntrack_tftp nsh nf_conncount vfio_pci_core irqbypass scsi_debug vhost_net tap tun
> vhost_vsock vmw_vsock_virtio_transport_common vsock vhost nft_masq nft_reject_ipv4 act_csum
> cls_u32 sch_htb smc_diag smc ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc loop
> algif_hash af_alg nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4
> nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
> nf_tables mlx5_vdpa vdpa mlx5_ib dm_service_time ib_uverbs_support vringh ib_core vhost_iotlb
> mlx5_core s390_trng eadm_sch vfio_ccw mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core
> dm_multipath drm_panel_orientation_quirks uvdevice diag288_wdt watchdog hmac_s390 prng aes_s390
> zfcp scsi_transport_fc pkey_pckmo pkey_cca pkey_ep11 zcrypt paes_s390 phmac_s390 rng_core
> scsi_dh_alua pkey scsi_dh_rdac scsi_dh_emc crypto_engine autofs4 ecdsa_generic ecc sha512 [last unloaded: openvswitch]
> CPU: 18 UID: 0 PID: 331372 Comm: devlink Tainted: G W 7.2.0-20260712.rc2.git0.e3321fa3034d.300.fc44.s390x+debug #1 PREEMPT
> Tainted: [W]=WARN
> Hardware name: IBM 9175 ME1 701 (LPAR)
> Krnl PSW : 0704c00180000000 0000038139a6771a (__kmem_cache_create_args+0xda/0x480)
> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
> Krnl GPRS: 0000000000000000 0000000000000000 000003813b7de578 00000380b9eb8974
> 00000276c417f690 00000380b9eb8974 0000030144623348 00000277234a1660
> 0000000000000020 00000380b9eb8974 00000277234a1600 000003813b686d30
> 0000000000000000 00000380b9e9a810 0000038139a6771a 0000030144623238
> Krnl Code: 0000038139a6770a: c02000ebb737 larl %r2,000003813b7de578
> 0000038139a67710: b9040039 lgr %r3,%r9
> *0000038139a67714: c0e5006e2eb2 brasl %r14,000003813a82d478
> >0000038139a6771a: a7390020 lghi %r3,32
> 0000038139a6771e: b9040029 lgr %r2,%r9
> 0000038139a67722: c0e5006cf98f brasl %r14,000003813a806a40
> 0000038139a67728: ec26018e007c cgij %r2,0,6,0000038139a67a44
> 0000038139a6772e: 58d0f0a4 l %r13,164(%r15)
> Call Trace:
> [<0000038139a6771a>] __kmem_cache_create_args+0xda/0x480
> ([<0000038139a676a2>] __kmem_cache_create_args+0x62/0x480)
> [<00000380b9da1c70>] dr_domain_init_mem_resources+0x80/0x240 [mlx5_core]
> [<00000380b9da226e>] dr_domain_init_resources.constprop.0+0x7e/0x2c0 [mlx5_core]
> [<00000380b9da28b2>] mlx5dr_domain_create+0x132/0x250 [mlx5_core]
> [<00000380b9dc1e20>] mlx5_cmd_dr_create_ns+0x30/0x90 [mlx5_core]
> [<00000380b9cd8dbe>] mlx5_flow_namespace_set_mode+0x6e/0x130 [mlx5_core]
> [<00000380b9d846ec>] esw_create_offloads_fdb_tables+0xac/0x5a0 [mlx5_core]
> [<00000380b9d865b6>] esw_offloads_steering_init+0x1c6/0x480 [mlx5_core]
> [<00000380b9d86e8e>] esw_offloads_enable+0x13e/0x410 [mlx5_core]
> [<00000380b9d7b04a>] mlx5_eswitch_enable_locked+0x36a/0x540 [mlx5_core]
> [<00000380b9d84ff0>] esw_offloads_start+0x50/0x1d0 [mlx5_core]
> [<00000380b9d8774a>] mlx5_devlink_eswitch_mode_set+0x35a/0x3f0 [mlx5_core]
> [<000003813a791e68>] devlink_nl_eswitch_set_doit+0x88/0x120
> [<000003813a5b93ea>] genl_family_rcv_msg_doit+0xea/0x150
> [<000003813a5b95c2>] genl_family_rcv_msg+0x172/0x210
> [<000003813a5b96c2>] genl_rcv_msg+0x62/0xc0
> [<000003813a5b7cac>] netlink_rcv_skb+0x5c/0x120
> [<000003813a5b8f0c>] genl_rcv+0x3c/0x50
> [<000003813a5b74a4>] netlink_unicast+0x1f4/0x2b0
> [<000003813a5b783c>] netlink_sendmsg+0x2dc/0x460
> [<000003813a4c9764>] __sock_sendmsg+0x64/0xd0
> [<000003813a4cc878>] __sys_sendto+0x108/0x160
> [<000003813a4cdf50>] __do_sys_socketcall+0x350/0x460
> [<000003813a8184d2>] __do_syscall+0x172/0x750
> [<000003813a82d5d2>] system_call+0x72/0x90
>
> Prefix each cache name with the device name to make it unique.
>
> Fixes: fd785e5213f0 ("net/mlx5: DR, Allocate icm_chunks from their own slab allocator")
> Fixes: fb628b71fb2a ("net/mlx5: DR, Allocate htbl from its own slab allocator")
> Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Closes: https://lore.kernel.org/all/a3cea501-4d1f-47d5-b6d0-fcda9a0aab16@linux.ibm.com/
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c
> index fedefb565a21..c9f20a9033eb 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c
> @@ -98,9 +98,12 @@ int mlx5dr_domain_get_recalc_cs_ft_addr(struct mlx5dr_domain *dmn,
>
> static int dr_domain_init_mem_resources(struct mlx5dr_domain *dmn)
> {
> + char name[80];
> int ret;
>
> - dmn->chunks_kmem_cache = kmem_cache_create("mlx5_dr_chunks",
> + snprintf(name, sizeof(name), "%s-mlx5_dr_chunks",
> + dev_name(dmn->mdev->device));
> + dmn->chunks_kmem_cache = kmem_cache_create(name,
> sizeof(struct mlx5dr_icm_chunk), 0,
> SLAB_HWCACHE_ALIGN, NULL);
> if (!dmn->chunks_kmem_cache) {
> @@ -108,7 +111,9 @@ static int dr_domain_init_mem_resources(struct mlx5dr_domain *dmn)
> return -ENOMEM;
> }
>
> - dmn->htbls_kmem_cache = kmem_cache_create("mlx5_dr_htbls",
> + snprintf(name, sizeof(name), "%s-mlx5_dr_htbls",
> + dev_name(dmn->mdev->device));
> + dmn->htbls_kmem_cache = kmem_cache_create(name,
> sizeof(struct mlx5dr_ste_htbl), 0,
> SLAB_HWCACHE_ALIGN, NULL);
> if (!dmn->htbls_kmem_cache) {
>
> ---
> base-commit: f8d04b0c74e989c515e0fa17bf779b730077f63e
> change-id: 20260715-kmem-dupliate-name-b151167f5119
>
> Best regards,
> --
> Leon Romanovsky <leonro@nvidia.com>
>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next v2] selftests/net: Skip srv6_end_dt46_l3vpn_test::host_vpn_tests if iproute2 too old
From: Andrea Mayer @ 2026-07-15 9:15 UTC (permalink / raw)
To: Alessio Faina
Cc: netdev, linux-kselftest, Po-Hsu Lin, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, Andrea Mayer, stefano.salsano
In-Reply-To: <20260713095750.2671173-1-alessio.faina@canonical.com>
On Mon, 13 Jul 2026 11:57:50 +0200
Alessio Faina <alessio.faina@canonical.com> wrote:
> In case iproute2 is older than version 5.14.0, released ~Sept 1, 2021,
> the End.DT46 support is not available and the host_vpn_tests test contained
> in the srv6_end_dt46_l3vpn_test.sh file is failing in some kernel backports.
> This is the result of those tests:
>
> ################################################################################
> TEST SECTION: SRv6 VPN connectivity test among hosts in the same tenant
> ################################################################################
>
> TEST: IPv6 Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [ FAIL ]
>
> TEST: IPv4 Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [ FAIL ]
>
> TEST: IPv6 Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [ FAIL ]
>
> TEST: IPv4 Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [ FAIL ]
>
> TEST: IPv6 Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [ FAIL ]
>
> TEST: IPv4 Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [ FAIL ]
>
> TEST: IPv6 Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [ FAIL ]
>
> TEST: IPv4 Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [ FAIL ]
>
> To amend this, check the current running iproute2 supports the required
> feature and, if not, just skip the test to avoid a failure.
>
>
> Signed-off-by: Alessio Faina <alessio.faina@canonical.com>
Hi Alessio,
Thanks for the v2, the code looks good to me.
One question: since the check now exits the entire script before setup(),
should the subject drop the "::host_vpn_tests" part?
just a nit: test_iproute2_supp_or_ksft_skip() uses spaces, but most of this
file uses tabs.
Ciao
Andrea
> ---
> v2:
> - skip entire test suite if iproute2 is too old
> v1: https://urldefense.com/v3/__https://lore.kernel.org/netdev/20260708152745.2430714-1-alessio.faina@canonical.com/__;!!O5Bi4QcV!CGb1HmTUSZ4JwCff0mVcoY_KnoHJmrGDAdGnPOEYWRVFi-J05H-ZtpLVZBNK12kwLaNmhzw7mrQw4M_eY5uuSft8PRuFHqU$
>
> .../testing/selftests/net/srv6_end_dt46_l3vpn_test.sh | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh b/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
> index a5e959a080bb..cd7ac03e3907 100755
> --- a/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
> +++ b/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
> @@ -536,6 +536,14 @@ host_vpn_isolation_tests()
> done
> }
>
> +test_iproute2_supp_or_ksft_skip()
> +{
> + if ! ip route add help 2>&1 | grep -qo "End.DT46"; then
> + echo "SKIP: Missing SRv6 End.DT46 support in iproute2"
> + exit "${ksft_skip}"
> + fi
> +}
> +
> if [ "$(id -u)" -ne 0 ];then
> echo "SKIP: Need root privileges"
> exit $ksft_skip
> @@ -546,6 +554,8 @@ if [ ! -x "$(command -v ip)" ]; then
> exit $ksft_skip
> fi
>
> +test_iproute2_supp_or_ksft_skip
> +
> modprobe vrf &>/dev/null
> if [ ! -e /proc/sys/net/vrf/strict_mode ]; then
> echo "SKIP: vrf sysctl does not exist"
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net] net/mlx5: Use unique names for software steering caches
From: Kalesh Anakkur Purayil @ 2026-07-15 9:14 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Saeed Mahameed, Tariq Toukan, Mark Bloch, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alex Vesker, Yevgeny Kliteynik, netdev, linux-rdma, linux-kernel,
Christian Borntraeger
In-Reply-To: <20260715-kmem-dupliate-name-v1-1-85551c328155@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 5140 bytes --]
On Wed, Jul 15, 2026 at 1:53 PM Leon Romanovsky <leon@kernel.org> wrote:
>
> From: Leon Romanovsky <leonro@nvidia.com>
>
> Each software steering domain creates its own slab caches, but all
> domains use the same names. When domains for two devices are alive at
> once, the second kmem_cache_create() triggers the following splat:
>
> WARNING: mm/slab_common.c:111 at __kmem_cache_create_args+0xca/0x480, CPU#18: devlink/331372
> Modules linked in: act_mirred act_skbedit cls_matchall act_gact cls_flower sch_ingress
> vhost_vdpa veth nfnetlink_cttimeout openvswitch macvtap macvlan vfio_ap kvm nf_nat_tftp
> nf_conntrack_tftp nsh nf_conncount vfio_pci_core irqbypass scsi_debug vhost_net tap tun
> vhost_vsock vmw_vsock_virtio_transport_common vsock vhost nft_masq nft_reject_ipv4 act_csum
> cls_u32 sch_htb smc_diag smc ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc loop
> algif_hash af_alg nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4
> nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
> nf_tables mlx5_vdpa vdpa mlx5_ib dm_service_time ib_uverbs_support vringh ib_core vhost_iotlb
> mlx5_core s390_trng eadm_sch vfio_ccw mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core
> dm_multipath drm_panel_orientation_quirks uvdevice diag288_wdt watchdog hmac_s390 prng aes_s390
> zfcp scsi_transport_fc pkey_pckmo pkey_cca pkey_ep11 zcrypt paes_s390 phmac_s390 rng_core
> scsi_dh_alua pkey scsi_dh_rdac scsi_dh_emc crypto_engine autofs4 ecdsa_generic ecc sha512 [last unloaded: openvswitch]
> CPU: 18 UID: 0 PID: 331372 Comm: devlink Tainted: G W 7.2.0-20260712.rc2.git0.e3321fa3034d.300.fc44.s390x+debug #1 PREEMPT
> Tainted: [W]=WARN
> Hardware name: IBM 9175 ME1 701 (LPAR)
> Krnl PSW : 0704c00180000000 0000038139a6771a (__kmem_cache_create_args+0xda/0x480)
> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
> Krnl GPRS: 0000000000000000 0000000000000000 000003813b7de578 00000380b9eb8974
> 00000276c417f690 00000380b9eb8974 0000030144623348 00000277234a1660
> 0000000000000020 00000380b9eb8974 00000277234a1600 000003813b686d30
> 0000000000000000 00000380b9e9a810 0000038139a6771a 0000030144623238
> Krnl Code: 0000038139a6770a: c02000ebb737 larl %r2,000003813b7de578
> 0000038139a67710: b9040039 lgr %r3,%r9
> *0000038139a67714: c0e5006e2eb2 brasl %r14,000003813a82d478
> >0000038139a6771a: a7390020 lghi %r3,32
> 0000038139a6771e: b9040029 lgr %r2,%r9
> 0000038139a67722: c0e5006cf98f brasl %r14,000003813a806a40
> 0000038139a67728: ec26018e007c cgij %r2,0,6,0000038139a67a44
> 0000038139a6772e: 58d0f0a4 l %r13,164(%r15)
> Call Trace:
> [<0000038139a6771a>] __kmem_cache_create_args+0xda/0x480
> ([<0000038139a676a2>] __kmem_cache_create_args+0x62/0x480)
> [<00000380b9da1c70>] dr_domain_init_mem_resources+0x80/0x240 [mlx5_core]
> [<00000380b9da226e>] dr_domain_init_resources.constprop.0+0x7e/0x2c0 [mlx5_core]
> [<00000380b9da28b2>] mlx5dr_domain_create+0x132/0x250 [mlx5_core]
> [<00000380b9dc1e20>] mlx5_cmd_dr_create_ns+0x30/0x90 [mlx5_core]
> [<00000380b9cd8dbe>] mlx5_flow_namespace_set_mode+0x6e/0x130 [mlx5_core]
> [<00000380b9d846ec>] esw_create_offloads_fdb_tables+0xac/0x5a0 [mlx5_core]
> [<00000380b9d865b6>] esw_offloads_steering_init+0x1c6/0x480 [mlx5_core]
> [<00000380b9d86e8e>] esw_offloads_enable+0x13e/0x410 [mlx5_core]
> [<00000380b9d7b04a>] mlx5_eswitch_enable_locked+0x36a/0x540 [mlx5_core]
> [<00000380b9d84ff0>] esw_offloads_start+0x50/0x1d0 [mlx5_core]
> [<00000380b9d8774a>] mlx5_devlink_eswitch_mode_set+0x35a/0x3f0 [mlx5_core]
> [<000003813a791e68>] devlink_nl_eswitch_set_doit+0x88/0x120
> [<000003813a5b93ea>] genl_family_rcv_msg_doit+0xea/0x150
> [<000003813a5b95c2>] genl_family_rcv_msg+0x172/0x210
> [<000003813a5b96c2>] genl_rcv_msg+0x62/0xc0
> [<000003813a5b7cac>] netlink_rcv_skb+0x5c/0x120
> [<000003813a5b8f0c>] genl_rcv+0x3c/0x50
> [<000003813a5b74a4>] netlink_unicast+0x1f4/0x2b0
> [<000003813a5b783c>] netlink_sendmsg+0x2dc/0x460
> [<000003813a4c9764>] __sock_sendmsg+0x64/0xd0
> [<000003813a4cc878>] __sys_sendto+0x108/0x160
> [<000003813a4cdf50>] __do_sys_socketcall+0x350/0x460
> [<000003813a8184d2>] __do_syscall+0x172/0x750
> [<000003813a82d5d2>] system_call+0x72/0x90
>
> Prefix each cache name with the device name to make it unique.
>
> Fixes: fd785e5213f0 ("net/mlx5: DR, Allocate icm_chunks from their own slab allocator")
> Fixes: fb628b71fb2a ("net/mlx5: DR, Allocate htbl from its own slab allocator")
> Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Closes: https://lore.kernel.org/all/a3cea501-4d1f-47d5-b6d0-fcda9a0aab16@linux.ibm.com/
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
LGTM,
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
--
Regards,
Kalesh AP
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5509 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v9 0/9] BIG TCP for UDP tunnels
From: Alice Mikityanska @ 2026-07-15 9:06 UTC (permalink / raw)
To: zebang.li
Cc: Alice Mikityanska, Andrew Lunn, Daniel Borkmann, David S. Miller,
David Ahern, Eric Dumazet, Florian Westphal, Simon Horman,
Jakub Kicinski, Xin Long, netdev, Paolo Abeni,
Nikolay Aleksandrov, Shuah Khan, Stanislav Fomichev,
Willem de Bruijn, Willem de Bruijn, nh78.kim, kwangho2.kim,
h10.kim, hongfei.tang, yajie.yan
In-Reply-To: <(raw)>
On Wed, Jul 15, 2026, at 09:11, zebang.li wrote:
> On 10/07/2026 16:42, Alice Mikityanska wrote:
>> From: Alice Mikityanska <alice@isovalent.com>
>>
>> This series is a follow-up to "BIG TCP without HBH in IPv6", and it adds
>> support for BIG TCP IPv4/IPv6 workloads in vxlan and geneve. Now that
>> IPv6 BIG TCP doesn't require stripping the HBH in all various
>> combinations in tunneled traffic, adding BIG TCP becomes feasible.
>>
>> Patch 01 adds accessors for the length field in the UDP header, as
>> suggested by Paolo in review. The usage of udp_set_len is then added in
>> the following patches that start using length=0 in BIG TCP UDP packets.
>>
>> Patches 02-04 close the gaps that prevent BIG TCP packets from going
>> through UDP tunnel code.
>>
>> Patch 05 validates packets in udp_gro_receive to exclude packets with
>> length=0 from GRO aggregation.
>>
>> Patch 06 is for proper formatting in tcpdump (set UDP len to 0 rather
>> than a trimmed value on overflow).
>>
>> Patches 07-08 bump up tso_max_size for VXLAN and GENEVE.
>>
>> Patch 09 adds selftests.
>>
>> Thanks all!
>>
>> v9 changes: Converted the selftest to iptables counters to avoid the
>> issue with tcpdump pcaps taking all space in /tmp.
>>
>> v8: https://lore.kernel.org/netdev/20260706181941.385672-1-alice.kernel@fastmail.im/
>>
>> v8 changes: Addressed Paolo's and Jason's review comments. Made the
>> selftest more robust, added checks for SACK and mode with disabled tx
>> checksum offload on lower veth netdevs. Added details to commit
>> messages. Kept skb_segment logic unchanged, because the frags overflow
>> issue is not specific to BIG TCP.
>>
>> v7: https://lore.kernel.org/netdev/20260611192955.604661-1-alice.kernel@fastmail.im/
>>
>> v7 changes: Addressed Paolo's comments to properly block malformed
>> packets with UDP length=0 at udp_rcv level.
>>
>> v6: https://lore.kernel.org/netdev/20260602093931.516281-1-alice.kernel@fastmail.im/
>>
>> v6 changes: Lowered the packets threshold in the selftest to pass
>> upstream CI on debug kernels, also made it configurable.
>>
>> v5: https://lore.kernel.org/netdev/20260526161200.1135899-1-alice.kernel@fastmail.im/
>>
>> v5 changes: Rebased, dropped one of the patches that came in via the net
>> tree, addressed an overflow in nsim_do_psp found by Sashiko.
>>
>> v4: https://lore.kernel.org/netdev/20260512165648.386518-1-alice.kernel@fastmail.im/
>>
>> v4 changes: Rebased, addressed Sashiko AI review [1] and Willem's
>> comment about netperf flags.
>>
>> My comments on Sashiko AI review per patch:
>>
>> 01: I'd prefer to keep the cases that I haven't tested outside of the
>> scope of this series, which is for VXLAN/GENEVE tunnels, not for ESP.
>>
>> 02: The patch doesn't have behavioral changes other than fixing the
>> checksum. The final uh->len assignment assigns the actual length, not
>> 64k.
>>
>> 03: The check can't be loosened, because total_len is also assigned to
>> UDP length. BIG TCP works in the mode without GRO hint option.
>>
>> 04: Fixed the fallback value for udplen. BIG TCP is fine, it's the
>> uh->len = 0 case, uh->len can't exceed 64k.
>>
>> 05: In the BIG TCP case, partial GSO splits the SKB in two. If full
>> segmentation is needed, the SKB is split in many MSS-sized SKBs without
>> fragments.
>>
>> 06: Invalid packets from the wire are addressed in 08.
>>
>> 07: __udp_gso_segment only handles UDP GSO packets, which can't be
>> bigger than 64k. Kept udp_set_len_short in nf_nat_mangle_udp_packet, as
>> the function doesn't support BIG TCP packets anyway (see
>> mangle_contents).
>>
>> 08: udp_gro_receive handles packets before aggregation, there are no BIG
>> TCP packets at this point. RFC 768 doesn't say that padded UDP packets
>> are valid. Real jumbograms don't seem to be supported in this path
>> anyway.
>>
>> 09: The packet goes to skb_udp_tunnel_segment, not __udp_gso_segment.
>> __skb_udp_tunnel_segment handles this case.
>>
>> 12: Improved process cleanup by killing everything inside netns before
>> deleting them, and by avoiding killing netserver outside of netns.
>> netperf with -r in TCP_STREAM mode works, and the option has the
>> intended effect, but I replaced it with -m. Added dependency check for
>> tcpdump.
>>
>> [1]: https://sashiko.dev/#/patchset/20260410150943.993350-1-alice.kernel%40fastmail.im
>>
>> v3: https://lore.kernel.org/netdev/20260410150943.993350-1-alice.kernel@fastmail.im/
>>
>> v3 changes: Fixed the redirect in the selftest, rebased over my L2TP fix
>> [2] for the syzbot report [3].
>>
>> [2]: https://lore.kernel.org/netdev/20260403174949.843941-1-alice.kernel@fastmail.im/
>> [3]: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/
>>
>> v2: https://lore.kernel.org/netdev/20260226201600.222044-1-alice.kernel@fastmail.im/
>>
>> v2 changes: Addressed the review comments: added UDP len helpers,
>> consolidated UDP len sanity checks in patch 08 into one, added
>> selftests. Added fixups to related code (patch 01-03).
>>
>> v1: https://lore.kernel.org/netdev/20250923134742.1399800-1-maxtram95@gmail.com/
>>
>> Alice Mikityanska (8):
>> net: Use helpers to get/set UDP len tree-wide
>> net: Enable BIG TCP with partial GSO
>> udp: Support BIG TCP GSO packets where they can occur
>> udp: Support gro_ipv4_max_size > 65536
>> udp: Validate UDP length in udp_gro_receive
>> udp: Set length in UDP header to 0 for big GSO packets
>> vxlan: Enable BIG TCP packets
>> selftests: net: Add a test for BIG TCP in UDP tunnels
>>
>> Daniel Borkmann (1):
>> geneve: Enable BIG TCP packets
>>
>> drivers/infiniband/core/lag.c | 2 +-
>> drivers/infiniband/sw/rxe/rxe_net.c | 4 +-
>> drivers/net/amt.c | 6 +-
>> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
>> drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +-
>> drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
>> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
>> .../marvell/octeontx2/nic/otx2_txrx.c | 2 +-
>> .../net/ethernet/mellanox/mlx5/core/en_rx.c | 4 +-
>> .../ethernet/mellanox/mlx5/core/en_selftest.c | 2 +-
>> drivers/net/ethernet/sfc/falcon/selftest.c | 4 +-
>> drivers/net/ethernet/sfc/selftest.c | 4 +-
>> drivers/net/ethernet/sfc/siena/selftest.c | 4 +-
>> drivers/net/ethernet/sfc/tc_encap_actions.c | 2 +-
>> .../stmicro/stmmac/stmmac_selftests.c | 4 +-
>> drivers/net/geneve.c | 4 +-
>> drivers/net/netconsole.c | 2 +-
>> drivers/net/netdevsim/dev.c | 2 +-
>> drivers/net/netdevsim/psample.c | 2 +-
>> drivers/net/netdevsim/psp.c | 8 +-
>> drivers/net/vxlan/vxlan_core.c | 2 +
>> drivers/net/wireguard/receive.c | 2 +-
>> include/linux/udp.h | 27 +++
>> include/trace/events/icmp.h | 2 +-
>> lib/tests/blackhole_dev_kunit.c | 2 +-
>> net/6lowpan/nhc_udp.c | 10 +-
>> net/core/pktgen.c | 4 +-
>> net/core/selftests.c | 4 +-
>> net/core/skbuff.c | 10 +-
>> net/core/tso.c | 3 +-
>> net/ipv4/esp4.c | 2 +-
>> net/ipv4/fou_core.c | 2 +-
>> net/ipv4/ipconfig.c | 6 +-
>> net/ipv4/netfilter/nf_nat_snmp_basic_main.c | 4 +-
>> net/ipv4/route.c | 2 +-
>> net/ipv4/udp.c | 7 +-
>> net/ipv4/udp_offload.c | 49 ++---
>> net/ipv4/udp_tunnel_core.c | 2 +-
>> net/ipv6/esp6.c | 5 +-
>> net/ipv6/fou6.c | 2 +-
>> net/ipv6/ip6_udp_tunnel.c | 2 +-
>> net/ipv6/udp.c | 7 +-
>> net/ipv6/udp_offload.c | 2 +-
>> net/l2tp/l2tp_core.c | 2 +-
>> net/netfilter/ipvs/ip_vs_xmit.c | 2 +-
>> net/netfilter/nf_conntrack_proto_udp.c | 15 +-
>> net/netfilter/nf_log_syslog.c | 2 +-
>> net/netfilter/nf_nat_helper.c | 2 +-
>> net/psp/psp_main.c | 2 +-
>> net/sched/act_csum.c | 4 +-
>> net/xfrm/xfrm_nat_keepalive.c | 2 +-
>> tools/testing/selftests/net/Makefile | 1 +
>> .../testing/selftests/net/big_tcp_tunnels.sh | 188 ++++++++++++++++++
>> 53 files changed, 340 insertions(+), 102 deletions(-)
>> create mode 100755 tools/testing/selftests/net/big_tcp_tunnels.sh
>>
>
>
> Hi Alice,
>
> This patch looks promising, but I noticed that it does not include a
> modification for `skb_gro_receive`.
>
> Currently, for UDP data aggregated via GRO, if the resulting packet
> size exceeds 65536 (`GRO_LEGACY_MAX_SIZE`), this check will return
> `-E2BIG`.
>
> To allow UDP GRO aggregation beyond this limit (similar to the existing
> TCP behavior), we should update the condition to include `IPPROTO_UDP`.
Thanks for the feedback! That's a good idea for future development,
however, I'd like to keep the scope of this effort limited to BIG TCP.
The series is already big enough, and adding UDP GRO might be not as
trivial as it seems. At the very least, it requires adding another
selftest to cover the new paths. In the worst case, it might need more
tweaks in the datapath in case something breaks at later points in the
pipeline. Moreover, since UDP GRO is not transparent for the userspace
(unlike BIG TCP), the userspace might rely on assumptions about max
aggregation size, and this topic needs additional research.
To sum up, it's a good direction for further research, which can be done
independently after merging this series, but I'd rather keep the scope
of this series clear and limited to BIG TCP. Note that the current
version of skb_gro_receive doesn't block tunneled BIG TCP traffic, which
is proved by the selftest and manual testing.
Thanks,
Alice
> I suggest the following modification:
>
> diff --git a/net/core/gro.c b/net/core/gro.c
> index 35f2f708f010..01e56ad629c2 100644
> --- a/net/core/gro.c
> +++ b/net/core/gro.c
> @@ -117,7 +117,7 @@ int skb_gro_receive(struct sk_buff *p, struct
> sk_buff *skb)
> return -E2BIG;
> if (unlikely(p->len + len >= GRO_LEGACY_MAX_SIZE)) {
> - if (NAPI_GRO_CB(skb)->proto != IPPROTO_TCP ||
> + if ((NAPI_GRO_CB(skb)->proto != IPPROTO_TCP &&
> NAPI_GRO_CB(skb)->proto != IPPROTO_UDP) ||
> p->encapsulation)
> return -E2BIG;
> }
>
> Thanks,
> zebang
^ permalink raw reply
* Re: [PATCH bpf-next v7 0/3] bpf: bidirectional VLAN support for bpf_fib_lookup()
From: patchwork-bot+netdevbpf @ 2026-07-15 9:00 UTC (permalink / raw)
To: Avinash Duduskar
Cc: ast, daniel, andrii, eddyz87, memxor, martin.lau, song,
yonghong.song, jolsa, emil, john.fastabend, sdf, davem, edumazet,
kuba, pabeni, horms, shuah, hawk, yatsenko, leon.hwang, kpsingh,
a.s.protopopov, ameryhung, rongtao, eyal.birger, bpf, netdev,
linux-kernel, linux-kselftest, toke, dsahern
In-Reply-To: <20260713162305.1237211-1-avinash.duduskar@gmail.com>
Hello:
This series was applied to bpf/bpf-next.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
On Mon, 13 Jul 2026 21:53:02 +0530 you wrote:
> This series adds VLAN awareness to bpf_fib_lookup() in both directions.
> BPF_FIB_LOOKUP_VLAN resolves a VLAN egress to its underlying real device
> plus the VLAN tag (XDP programs need this because VLAN devices have no
> XDP xmit), and BPF_FIB_LOOKUP_VLAN_INPUT runs the lookup as if a tagged
> frame had arrived on the matching VLAN subinterface, for iif policy
> routing and VRF table selection.
>
> [...]
Here is the summary with links:
- [bpf-next,v7,1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper
https://git.kernel.org/bpf/bpf-next/c/35dac1daeb3c
- [bpf-next,v7,2/3] bpf: Add BPF_FIB_LOOKUP_VLAN_INPUT flag to bpf_fib_lookup() helper
https://git.kernel.org/bpf/bpf-next/c/217828aad80d
- [bpf-next,v7,3/3] selftests/bpf: Add bpf_fib_lookup() VLAN flag tests
https://git.kernel.org/bpf/bpf-next/c/e54a87872e34
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] ppp: reuse ppp_get_stats64() for ioctl stats
From: Zhixing Chen @ 2026-07-15 8:58 UTC (permalink / raw)
To: Qingfang Deng
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-ppp, netdev
In-Reply-To: <e07c280b-d3a8-442d-bf19-f00d544ab26c@linux.dev>
Hi Qingfang,
Thanks a lot for pointing this out.
> On a 32-bit architecture, this will introduce unnecessary seqlock
> overhead to get the upper 32-bit of a counter, which would then be
> immediately discarded.
That makes sense. I missed that reusing ppp_get_stats64() would add
unnecessary 64-bit stats read overhead on 32-bit architectures, while the
ioctl path only returns 32-bit counters. I agree this is not a good
trade-off for a cleanup.
Please ignore this patch.
Thanks again,
Zhixing
^ permalink raw reply
* Re: [PATCH] virtio_net: fix spelling of aggressively in comments
From: Jakub Raczynski @ 2026-07-15 8:49 UTC (permalink / raw)
To: weimin xiong
Cc: netdev, mst, jasowangio, xuanzhuo, eperezma, virtualization,
xiongweimin
In-Reply-To: <20260714024037.186799-1-15927021679@163.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
Please read
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
This patch should target net-next tree and is not actively CC'ing any
maintainer. Use 'get_maintainer.pl' script to get correct recipents.
BR
Jakub Raczynski
On Tue, Jul 14, 2026 at 10:40:37AM +0800, weimin xiong wrote:
> From: xiongweimin <xiongweimin@kylinos.cn>
>
> Two receive-path comments misspell "aggressively" as "agressively".
>
> Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
> ---
> drivers/net/virtio_net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 3e2a5876c..f3c7b28ce 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -3190,7 +3190,7 @@ static int virtnet_open(struct net_device *dev)
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> if (i < vi->curr_queue_pairs)
> - /* Pre-fill rq agressively, to make sure we are ready to
> + /* Pre-fill rq aggressively, to make sure we are ready to
> * get packets immediately.
> */
> try_fill_recv(vi, &vi->rq[i], GFP_KERNEL);
> @@ -3419,7 +3419,7 @@ static void virtnet_rx_resume(struct virtnet_info *vi,
> bool refill)
> {
> if (netif_running(vi->dev)) {
> - /* Pre-fill rq agressively, to make sure we are ready to get
> + /* Pre-fill rq aggressively, to make sure we are ready to get
> * packets immediately.
> */
> if (refill)
> --
> 2.43.0
>
>
> No virus found
> Checked by Hillstone Network AntiVirus
>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 01/10] net: stmmac: move XPCS lifetime management to platform drivers
From: Christian Marangi @ 2026-07-15 8:44 UTC (permalink / raw)
To: Coia Prant
Cc: Maxime Chevallier, kuba, davem, edumazet, pabeni, andrew+netdev,
robh, krzk+dt, heiko, netdev, linux-rockchip, devicetree,
linux-arm-kernel, linux-phy
In-Reply-To: <CALj3r0gWyfHHp0S4=71M1-TjgHKcgGax4Lr0DzPi37Q69-iCwA@mail.gmail.com>
On Wed, Jul 15, 2026 at 04:17:50PM +0800, Coia Prant wrote:
> Maxime Chevallier <maxime.chevallier@bootlin.com> 于2026年7月15日周三 15:31写道：
> >
> > Hi,
> >
> > +Christian
> >
> > On 7/14/26 21:08, Coia Prant wrote:
> > > The current XPCS creation logic in stmmac_pcs_setup() is problematic
> > > for several reasons.
> > >
> > > First, if a device tree specifies a "pcs-handle" but no select_pcs()
> > > callback is provided by the platform driver, the created XPCS is never
> > > used. The phylink framework requires select_pcs() to actually return
> > > the PCS to the core, so the pcs-handle property becomes effectively
> > > useless without the matching callback. This is confusing for developers
> > > who expect that specifying a pcs-handle in their device tree should be
> > > sufficient to enable the PCS.
> >
> > I think Christian's work on fwnode PCS would help a lot with that PCS
> > handling in stmmac:
> >
> > https://lore.kernel.org/netdev/20260618125752.1223-1-ansuelsmth@gmail.com/
> >
> > I don't know when Christian plans to iterate, it could be worth using
> > that new fwnode mechanism here ?
> >
> > Maxime
>
> Hi Maxime,
>
> Thanks for pointing me to Christian's work. This looks like a
> much-needed improvement.
>
> I actually spent all night debugging call traces caused by the current
> stmmac PCS lifetime management, and it was not a pleasant experience.
> The code feels like accumulated technical debt that should be cleaned
> up.
>
Yes we also got a similar situation with an ipq50xx SoC where the
standalone PCS feature was implemented (I can add reference to OpenWrt
code) and we also had some ""magic"" code to implement PCS as it does use
the DWMAC plat. It seems for DWMAC PCS is very abstracted and have at least
3 different implementation aside from the common "select_pcs" one.
> Regarding timeline: since Christian's series is still in RFC with an
> uncertain merge date, I'd prefer to keep this series as-is for now, as
> it solves the problem for Rockchip and has already started receiving
> review feedback. Once Christian's fwnode PCS work lands in net-next,
> I'm happy to rebase and convert the Rockchip glue driver to the new
> interface.
The series in RFC just because i posted while net-next was closed but it's
not in RFC state. (sashiko is starting to hallucinate problems) I plan to
post v10 today but still low review aside from ""lovely"" bot.
>
> One thing I'd really like to see: the ability to specify the logical
> MII port instance via something like:
>
> pcs-handle = <&pcs MII_PortX>;
>
> That would make the DT binding much cleaner and more flexible for
> multi-port configurations.
That is exactly one of the main feature of this new implementation as is
already used downstream by Airoha SoC where a PCIe PCS expose 2 PCS from a
single provider. (the code use the simple consumer/provider pattern and the
driver have complete freedom of applying whatever logic is needed when
returning the correct cell)
I think the idea of Maxime is to test that series on most Scenario as
possible to verify for fragility or regression on it.
(but just for Maxime the feature is getting actively used on OpenWrt by 3
different SoC and no complain for now)
--
Ansuel
^ permalink raw reply
* Re: [PATCH bpf v4 0/4] bpf, sockmap: Fix sockmap leaking UDP socks
From: patchwork-bot+netdevbpf @ 2026-07-15 8:40 UTC (permalink / raw)
To: Michal Luczaj
Cc: ast, daniel, andrii, eddyz87, memxor, martin.lau, song,
yonghong.song, jolsa, emil, shuah, john.fastabend, jakub,
jiayuan.chen, edumazet, kuniyu, pabeni, willemb, davem, kuba,
horms, cong.wang, bpf, linux-kselftest, linux-kernel, netdev
In-Reply-To: <20260707-sockmap-lookup-udp-leak-v4-0-f878346f27ab@rbox.co>
Hello:
This series was applied to bpf/bpf.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
On Tue, 07 Jul 2026 06:23:55 +0200 you wrote:
> Fix for UDP sockets getting leaked during sockmap lookup/release.
> Accompanied by selftests updates.
>
> Two Sashiko's concerns to be addressed separately:
> https://lore.kernel.org/bpf/20260626205814.BAC3C1F000E9@smtp.kernel.org/
>
> Signed-off-by: Michal Luczaj <mhal@rbox.co>
>
> [...]
Here is the summary with links:
- [bpf,v4,1/4] selftests/bpf: Ensure UDP sockets are bound
https://git.kernel.org/bpf/bpf/c/fe3ff273767e
- [bpf,v4,2/4] bpf, sockmap: Reject unhashed UDP sockets on sockmap update
https://git.kernel.org/bpf/bpf/c/66efd3368ae1
- [bpf,v4,3/4] selftests/bpf: Adapt sockmap update error handling
https://git.kernel.org/bpf/bpf/c/30581eda4a07
- [bpf,v4,4/4] selftests/bpf: Fail unbound UDP on sockmap update
https://git.kernel.org/bpf/bpf/c/203b06932777
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 bpf-next v4 1/6] netlink: specs: Add XDP RX checksum capability to XDP metadata specs
From: Stanislav Fomichev @ 2026-07-15 8:32 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Vladimir Vdovin, Donald Hunter, Jakub Kicinski, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Andrew Lunn, Tony Nguyen, Przemek Kitszel,
Alexander Lobakin, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Shuah Khan, Maciej Fijalkowski, Jakub Sitnicki,
Aleksandr Loktionov, netdev, bpf, intel-wired-lan,
linux-kselftest
In-Reply-To: <alZtI782RGKb8y4Y@lore-desk>
On 07/14, Lorenzo Bianconi wrote:
> > On 07/08, Vladimir Vdovin wrote:
> > > From: Lorenzo Bianconi <lorenzo@kernel.org>
> > >
> > > Introduce XDP RX checksum capability to XDP metadata specs. XDP RX
> > > checksum will be use by devices capable of exposing receive checksum
> > > result via bpf_xdp_metadata_rx_checksum().
> > > Moreover, introduce xmo_rx_checksum netdev callback in order to allow
> > > the eBPF program bound to the device to retrieve the RX checksum result
> > > computed by the hw NIC and reported via DMA descriptors.
> > >
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > Signed-off-by: Vladimir Vdovin <deliran@verdict.gg>
> > > ---
> > > Documentation/netlink/specs/netdev.yaml | 5 ++++
> > > include/net/xdp.h | 18 ++++++++++++++
> > > include/uapi/linux/netdev.h | 3 +++
> > > net/core/xdp.c | 32 +++++++++++++++++++++++++
> > > tools/include/uapi/linux/netdev.h | 3 +++
> > > 5 files changed, 61 insertions(+)
> > >
> > > diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml
> > > index 5f143da7458c..6d0d90d3a614 100644
> > > --- a/Documentation/netlink/specs/netdev.yaml
> > > +++ b/Documentation/netlink/specs/netdev.yaml
> > > @@ -61,6 +61,11 @@ definitions:
> > > doc: |
> > > Device is capable of exposing receive packet VLAN tag via
> > > bpf_xdp_metadata_rx_vlan_tag().
> > > + -
> > > + name: checksum
> > > + doc: |
> > > + Device is capable of exposing receive checksum result via
> > > + bpf_xdp_metadata_rx_checksum().
> > > -
> > > type: flags
> > > name: xsk-flags
> > > diff --git a/include/net/xdp.h b/include/net/xdp.h
> > > index aa742f413c35..e255ff786131 100644
> > > --- a/include/net/xdp.h
> > > +++ b/include/net/xdp.h
> > > @@ -586,6 +586,10 @@ void xdp_attachment_setup(struct xdp_attachment_info *info,
> > > NETDEV_XDP_RX_METADATA_VLAN_TAG, \
> > > bpf_xdp_metadata_rx_vlan_tag, \
> > > xmo_rx_vlan_tag) \
> > > + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_CHECKSUM, \
> > > + NETDEV_XDP_RX_METADATA_CHECKSUM, \
> > > + bpf_xdp_metadata_rx_checksum, \
> > > + xmo_rx_checksum)
> > >
> > > enum xdp_rx_metadata {
> > > #define XDP_METADATA_KFUNC(name, _, __, ___) name,
> > > @@ -643,12 +647,26 @@ enum xdp_rss_hash_type {
> > > XDP_RSS_TYPE_L4_IPV6_SCTP_EX = XDP_RSS_TYPE_L4_IPV6_SCTP | XDP_RSS_L3_DYNHDR,
> > > };
> >
> > [..]
> >
> > > +/* Please note the driver is required to invalidate the checksum if the NIC
> > > + * reports CHECKSUM_UNNECESSARY or CHECKSUM_COMPLETE and the eBPF program
> > > + * modifies the packet since it can change some fields validated by the
> > > + * checksum.
> > > + */
> >
> > Sorry, a bit confused about this part. IIUC this is in response to this
> > discussion https://lore.kernel.org/bpf/aaLYfWnuuf_ne72u@lore-desk/ ?
> >
> > Looking at a few drivers:
> > - bnxt (bnxt_rx_pkt) does UNNECESSARY - ok
> > - mlx5 (mlx5e_handle_csum) does UNNECESSARY and skips COMPLETE if there is
> > bpf prog attached
> > - fbnic (fbnic_rx_csum) - can do COMPLETE even with xdp attached?
> > - gve (gve_rx) - can do COMPLETE even with xdp attached?
> >
> > So none of the drivers invalidate anything (and nether the bpf machinery), some
> > choose to (correctly?) not report COMPLETE when there is XDP. So was the
> > discussion about documenting this and giving some guidance? This probably
> > belongs to that `DOC: skb checksums` section of include/linux/skbuff.h?
>
> Hi Stanislav,
>
> re-reading the previous upstream discussion, I guess we should just document the
> expected driver behaviour (invalidate the cksum for both COMPLETE and
> UNNECESSARY cases when the XDP program running on the NIC returns XDP_PASS) and
> add a given kselftest for it. Agree?
Yes, let's have something a bit more detailed about how it works right now
vs the expectation.
By my point is: the comment in this patch also seems wrong? We do not seem
to invalidate the csum, we just disable COMPLETE when there is a xdp program
attached (or I'm missing something).
^ permalink raw reply
* Re: [PATCH iwl-net v1 1/2] iavf: fix ASQ command buffer leak on init failure
From: luoxuanqiang @ 2026-07-15 8:30 UTC (permalink / raw)
To: Jagielski, Jedrzej, Nguyen, Anthony L, Kitszel, Przemyslaw,
intel-wired-lan@lists.osuosl.org
Cc: Andrew Lunn, Mitch Williams, Greg Rose, Sudheer Mogilappagari,
netdev@vger.kernel.org, Xuanqiang Luo, stable@vger.kernel.org
In-Reply-To: <PH0PR11MB590272FD2023440F52E95689F0F82@PH0PR11MB5902.namprd11.prod.outlook.com>
在 2026/7/15 15:24, Jagielski, Jedrzej 写道:
> From: xuanqiang.luo@linux.dev <xuanqiang.luo@linux.dev>
> Sent: Wednesday, July 15, 2026 8:12 AM
>
>> From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>>
>> iavf_alloc_adminq_asq_ring() allocates cmd_buf before the remaining ASQ
>> resources. If iavf_alloc_asq_bufs() or iavf_config_asq_regs() fails, the
>> unwind path elides cmd_buf while freeing the other allocations.
>>
>> The ASQ count is not set until initialization succeeds, so the shutdown
>> path cannot reclaim the buffer. Free cmd_buf in the common unwind path.
>>
>> Fixes: d358aa9a7a2d ("i40evf: init code and hardware support")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
>> ---
>> drivers/net/ethernet/intel/iavf/iavf_adminq.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq.c b/drivers/net/ethernet/intel/iavf/iavf_adminq.c
>> index 6937b7dd44cbb..82a32f8e78c12 100644
>> --- a/drivers/net/ethernet/intel/iavf/iavf_adminq.c
>> +++ b/drivers/net/ethernet/intel/iavf/iavf_adminq.c
>> @@ -346,6 +346,7 @@ static enum iavf_status iavf_init_asq(struct iavf_hw *hw)
>> iavf_free_virt_mem(hw, &hw->aq.asq.dma_head);
>>
>> init_adminq_free_rings:
>> + iavf_free_virt_mem(hw, &hw->aq.asq.cmd_buf);
> Hi Xuanqiang
> much thanks for the patches!
>
> how about moving that line directly into iavf_free_adminq_asq()?
> then free func would be paired 1:1 with alloc func
Thanks for the suggestion!
I've addressed it and sent out v2.
>
>> iavf_free_adminq_asq(hw);
>>
>> init_adminq_exit:
>> --
>> 2.43.0
^ permalink raw reply
* [PATCH iwl-net v2 2/2] iavf: fix QoS capabilities memory leak
From: xuanqiang.luo @ 2026-07-15 8:25 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Jagielski, Jedrzej, intel-wired-lan
Cc: Andrew Lunn, Mitch Williams, Greg Rose, Sudheer Mogilappagari,
netdev, Xuanqiang Luo, stable
In-Reply-To: <20260715082548.56687-1-xuanqiang.luo@linux.dev>
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Commit 4c1a457cb8b0 ("iavf: add support to exchange qos capabilities")
allocates adapter->qos_caps during probe, but iavf_remove() does not
free it. This leaks the allocation whenever an iavf device is removed.
Free adapter->qos_caps in iavf_remove().
Fixes: 4c1a457cb8b0 ("iavf: add support to exchange qos capabilities")
Cc: stable@vger.kernel.org
Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 29b8403a066bc..c7f69a9040588 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -5589,6 +5589,7 @@ static void iavf_remove(struct pci_dev *pdev)
iounmap(hw->hw_addr);
pci_release_regions(pdev);
kfree(adapter->vf_res);
+ kfree(adapter->qos_caps);
spin_lock_bh(&adapter->mac_vlan_list_lock);
/* If we got removed before an up/down sequence, we've got a filter
* hanging out there that we need to get rid of.
--
2.43.0
^ permalink raw reply related
* [PATCH iwl-net v2 1/2] iavf: fix ASQ command buffer leak on init failure
From: xuanqiang.luo @ 2026-07-15 8:25 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Jagielski, Jedrzej, intel-wired-lan
Cc: Andrew Lunn, Mitch Williams, Greg Rose, Sudheer Mogilappagari,
netdev, Xuanqiang Luo, stable
In-Reply-To: <20260715082548.56687-1-xuanqiang.luo@linux.dev>
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
iavf_alloc_adminq_asq_ring() allocates cmd_buf before the remaining ASQ
resources. If iavf_alloc_asq_bufs() or iavf_config_asq_regs() fails, the
unwind path elides cmd_buf while freeing the other allocations.
The ASQ count is not set until initialization succeeds, so the shutdown
path cannot reclaim the buffer. Free cmd_buf in the common unwind path.
Fixes: d358aa9a7a2d ("i40evf: init code and hardware support")
Cc: stable@vger.kernel.org
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
---
drivers/net/ethernet/intel/iavf/iavf_adminq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq.c b/drivers/net/ethernet/intel/iavf/iavf_adminq.c
index 6937b7dd44cbb..40f76f9507f4b 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_adminq.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_adminq.c
@@ -60,6 +60,7 @@ static enum iavf_status iavf_alloc_adminq_arq_ring(struct iavf_hw *hw)
**/
static void iavf_free_adminq_asq(struct iavf_hw *hw)
{
+ iavf_free_virt_mem(hw, &hw->aq.asq.cmd_buf);
iavf_free_dma_mem(hw, &hw->aq.asq.desc_buf);
}
--
2.43.0
^ permalink raw reply related
* [PATCH iwl-net v2 0/2] iavf: fix two memory leaks
From: xuanqiang.luo @ 2026-07-15 8:25 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Jagielski, Jedrzej, intel-wired-lan
Cc: Andrew Lunn, Mitch Williams, Greg Rose, Sudheer Mogilappagari,
netdev, Xuanqiang Luo
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
This series fixes two memory leaks found by inspection in iavf. Release
the ASQ command buffer when initialization fails and the QoS capabilities
buffer when the device is removed.
---
Changes:
v2:
Patch1:
- Move the ASQ command buffer cleanup into iavf_free_adminq_asq() to
pair it with iavf_alloc_adminq_asq_ring(). (Suggested by Jedrzej.)
v1: https://lore.kernel.org/all/20260715061131.34420-1-xuanqiang.luo@linux.dev/
Xuanqiang Luo (2):
iavf: fix ASQ command buffer leak on init failure
iavf: fix QoS capabilities memory leak
drivers/net/ethernet/intel/iavf/iavf_adminq.c | 1 +
drivers/net/ethernet/intel/iavf/iavf_main.c | 1 +
2 files changed, 2 insertions(+)
base-commit: 58717b2a1365d06c8c64b72aa948541b53fe31eb
--
2.43.0
^ permalink raw reply
* [PATCH rdma-next v3] RDMA/mlx5: quiesce CQ polling before device shutdown on reboot
From: Chenguang Zhao @ 2026-07-15 8:23 UTC (permalink / raw)
To: jgg, leon, andrew+netdev, davem, edumazet, kuba, pabeni
Cc: linux-rdma, netdev, chenguang.zhao, tariqt, mbloch, dtatulea,
shayd, moshe, Chenguang Zhao
From: Chenguang Zhao <zhaochenguang@kylinos.cn>
On reboot -f with NFS over RDMA, mlx5 shutdown can tear the device
down while ib-comp-wq still polls live CQs, leading to UAF in
wr_cqe->done().
Mark the device shutting down before teardown, flush completion
workqueues so in-flight pollers observe the flag, skip SYS_ERROR
completion delivery, and make poll/arm CQ a no-op under the CQ lock
while shutting down.
Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
---
changelog:
- Fix the race on MLX5_INTERFACE_STATE_SHUTTING_DOWN: set the
flag, then flush ib-comp / mlx5_ib event workqueues via an
mlx5_ib quiesce hook before fast_unload/teardown.
- Check shutting-down under cq->lock in mlx5_ib_poll_cq/arm_cq.
- Export ib_comp_wq and ib_comp_unbound_wq so modular mlx5_ib
can flush them.
v2:
https://lore.kernel.org/all/20260714075558.1420384-1-chenguang.zhao@linux.dev/
v1:
https://lore.kernel.org/all/20260702073422.279820-1-chenguang.zhao@linux.dev/
drivers/infiniband/core/device.c | 2 ++
drivers/infiniband/hw/mlx5/cq.c | 11 ++++++++++
drivers/infiniband/hw/mlx5/main.c | 20 +++++++++++++++++++
.../net/ethernet/mellanox/mlx5/core/health.c | 3 +++
.../net/ethernet/mellanox/mlx5/core/main.c | 10 ++++++++++
.../mellanox/mlx5/core/sf/dev/driver.c | 3 +++
include/linux/mlx5/driver.h | 11 ++++++++++
7 files changed, 60 insertions(+)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index b8193e077a74..6c3377bd53df 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -56,7 +56,9 @@ MODULE_DESCRIPTION("core kernel InfiniBand API");
MODULE_LICENSE("Dual BSD/GPL");
struct workqueue_struct *ib_comp_wq;
+EXPORT_SYMBOL_GPL(ib_comp_wq);
struct workqueue_struct *ib_comp_unbound_wq;
+EXPORT_SYMBOL_GPL(ib_comp_unbound_wq);
struct workqueue_struct *ib_wq;
EXPORT_SYMBOL_GPL(ib_wq);
static struct workqueue_struct *ib_unreg_wq;
diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 49b4bf148a4a..5d951c186cb3 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -619,6 +619,10 @@ int mlx5_ib_poll_cq(struct ib_cq *ibcq, int num_entries, struct ib_wc *wc)
int npolled;
spin_lock_irqsave(&cq->lock, flags);
+ if (mlx5_core_is_shutting_down(mdev)) {
+ spin_unlock_irqrestore(&cq->lock, flags);
+ return 0;
+ }
if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) {
/* make sure no soft wqe's are waiting */
if (unlikely(!list_empty(&cq->wc_list)))
@@ -654,6 +658,10 @@ int mlx5_ib_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify_flags flags)
int ret = 0;
spin_lock_irqsave(&cq->lock, irq_flags);
+ if (mlx5_core_is_shutting_down(mdev)) {
+ spin_unlock_irqrestore(&cq->lock, irq_flags);
+ return 0;
+ }
if (cq->notify_flags != IB_CQ_NEXT_COMP)
cq->notify_flags = flags & IB_CQ_SOLICITED_MASK;
@@ -661,6 +669,9 @@ int mlx5_ib_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify_flags flags)
ret = 1;
spin_unlock_irqrestore(&cq->lock, irq_flags);
+ if (mlx5_core_is_shutting_down(mdev))
+ return ret;
+
mlx5_cq_arm(&cq->mcq,
(flags & IB_CQ_SOLICITED_MASK) == IB_CQ_SOLICITED ?
MLX5_CQ_DB_REQ_NOT_SOL : MLX5_CQ_DB_REQ_NOT,
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 02809114fc79..dfc805892684 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -84,6 +84,13 @@ static LIST_HEAD(mlx5_ib_dev_list);
*/
static DEFINE_MUTEX(mlx5_ib_multiport_mutex);
+static void mlx5_ib_shutdown_quiesce(void)
+{
+ flush_workqueue(ib_comp_wq);
+ flush_workqueue(ib_comp_unbound_wq);
+ flush_workqueue(mlx5_ib_event_wq);
+}
+
struct mlx5_ib_dev *mlx5_ib_get_ibdev_from_mpi(struct mlx5_ib_multiport_info *mpi)
{
struct mlx5_ib_dev *dev;
@@ -2976,6 +2983,9 @@ static void mlx5_ib_handle_internal_error(struct mlx5_ib_dev *ibdev)
unsigned long flags_cq;
unsigned long flags;
+ if (mlx5_core_is_shutting_down(ibdev->mdev))
+ return;
+
INIT_LIST_HEAD(&cq_armed_list);
/* Go over qp list reside on that ibdev, sync with create/destroy qp.*/
@@ -3200,6 +3210,9 @@ static void mlx5_ib_handle_sys_error_event(struct work_struct *_work)
struct mlx5_ib_dev *ibdev = work->dev;
struct ib_event ibev;
+ if (mlx5_core_is_shutting_down(ibdev->mdev))
+ goto out;
+
ibev.event = IB_EVENT_DEVICE_FATAL;
mlx5_ib_handle_internal_error(ibdev);
ibev.element.port_num = (u8)(unsigned long)work->param;
@@ -3222,10 +3235,15 @@ static int mlx5_ib_sys_error_event(struct notifier_block *nb,
unsigned long event, void *param)
{
struct mlx5_ib_event_work *work;
+ struct mlx5_ib_dev *ibdev;
if (event != MLX5_DEV_EVENT_SYS_ERROR)
return NOTIFY_DONE;
+ ibdev = container_of(nb, struct mlx5_ib_dev, sys_error_events);
+ if (mlx5_core_is_shutting_down(ibdev->mdev))
+ return NOTIFY_OK;
+
work = kmalloc_obj(*work, GFP_ATOMIC);
if (!work)
return NOTIFY_DONE;
@@ -5529,6 +5547,7 @@ static int __init mlx5_ib_init(void)
if (ret)
goto drv_err;
+ mlx5_rdma_shutdown_quiesce = mlx5_ib_shutdown_quiesce;
return 0;
drv_err:
@@ -5547,6 +5566,7 @@ static int __init mlx5_ib_init(void)
static void __exit mlx5_ib_cleanup(void)
{
+ mlx5_rdma_shutdown_quiesce = NULL;
mlx5_data_direct_driver_unregister();
auxiliary_driver_unregister(&mlx5r_driver);
auxiliary_driver_unregister(&mlx5r_mp_driver);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
index aeeb136f5ebc..d9cc42c4c310 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -202,6 +202,9 @@ static void enter_error_state(struct mlx5_core_dev *dev, bool force)
mlx5_cmd_flush(dev);
}
+ if (mlx5_core_is_shutting_down(dev))
+ return;
+
mlx5_notifier_call_chain(dev->priv.events, MLX5_DEV_EVENT_SYS_ERROR, (void *)1);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 643b4aac2033..51de0b4570aa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -2186,12 +2186,22 @@ static int mlx5_try_fast_unload(struct mlx5_core_dev *dev)
return 0;
}
+void (*mlx5_rdma_shutdown_quiesce)(void);
+EXPORT_SYMBOL_GPL(mlx5_rdma_shutdown_quiesce);
+
static void shutdown(struct pci_dev *pdev)
{
struct mlx5_core_dev *dev = pci_get_drvdata(pdev);
int err;
mlx5_core_info(dev, "Shutdown was called\n");
+ set_bit(MLX5_INTERFACE_STATE_SHUTTING_DOWN, &dev->intf_state);
+ /*
+ * Ensure in-flight CQ pollers observe SHUTTING_DOWN before
+ * fast_unload tears the device down.
+ */
+ if (mlx5_rdma_shutdown_quiesce)
+ mlx5_rdma_shutdown_quiesce();
set_bit(MLX5_BREAK_FW_WAIT, &dev->intf_state);
mlx5_drain_fw_reset(dev);
mlx5_drain_health_wq(dev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c b/drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c
index 4391ef0bab5d..d9735e492971 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c
@@ -111,6 +111,9 @@ static void mlx5_sf_dev_shutdown(struct auxiliary_device *adev)
struct mlx5_sf_dev *sf_dev = container_of(adev, struct mlx5_sf_dev, adev);
struct mlx5_core_dev *mdev = sf_dev->mdev;
+ set_bit(MLX5_INTERFACE_STATE_SHUTTING_DOWN, &mdev->intf_state);
+ if (mlx5_rdma_shutdown_quiesce)
+ mlx5_rdma_shutdown_quiesce();
set_bit(MLX5_BREAK_FW_WAIT, &mdev->intf_state);
mlx5_drain_health_wq(mdev);
mlx5_unload_one(mdev, false);
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index b1871c0821d0..d81d13169828 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -653,8 +653,14 @@ enum mlx5_device_state {
enum mlx5_interface_state {
MLX5_INTERFACE_STATE_UP = BIT(0),
MLX5_BREAK_FW_WAIT = BIT(1),
+ MLX5_INTERFACE_STATE_SHUTTING_DOWN = BIT(2),
};
+/* Optional hook installed by mlx5_ib to flush CQ poll work after the
+ * SHUTTING_DOWN flag is set and before teardown continues.
+ */
+extern void (*mlx5_rdma_shutdown_quiesce)(void);
+
enum mlx5_pci_status {
MLX5_PCI_STATUS_DISABLED,
MLX5_PCI_STATUS_ENABLED,
@@ -1220,6 +1226,11 @@ static inline bool mlx5_core_is_pf(const struct mlx5_core_dev *dev)
return dev->coredev_type == MLX5_COREDEV_PF;
}
+static inline bool mlx5_core_is_shutting_down(struct mlx5_core_dev *dev)
+{
+ return test_bit(MLX5_INTERFACE_STATE_SHUTTING_DOWN, &dev->intf_state);
+}
+
static inline bool mlx5_core_is_vf(const struct mlx5_core_dev *dev)
{
return dev->coredev_type == MLX5_COREDEV_VF;
--
2.25.1
^ permalink raw reply related
* [PATCH net] net/mlx5: Use unique names for software steering caches
From: Leon Romanovsky @ 2026-07-15 8:22 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alex Vesker, Yevgeny Kliteynik
Cc: netdev, linux-rdma, linux-kernel, Christian Borntraeger
From: Leon Romanovsky <leonro@nvidia.com>
Each software steering domain creates its own slab caches, but all
domains use the same names. When domains for two devices are alive at
once, the second kmem_cache_create() triggers the following splat:
WARNING: mm/slab_common.c:111 at __kmem_cache_create_args+0xca/0x480, CPU#18: devlink/331372
Modules linked in: act_mirred act_skbedit cls_matchall act_gact cls_flower sch_ingress
vhost_vdpa veth nfnetlink_cttimeout openvswitch macvtap macvlan vfio_ap kvm nf_nat_tftp
nf_conntrack_tftp nsh nf_conncount vfio_pci_core irqbypass scsi_debug vhost_net tap tun
vhost_vsock vmw_vsock_virtio_transport_common vsock vhost nft_masq nft_reject_ipv4 act_csum
cls_u32 sch_htb smc_diag smc ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc loop
algif_hash af_alg nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4
nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
nf_tables mlx5_vdpa vdpa mlx5_ib dm_service_time ib_uverbs_support vringh ib_core vhost_iotlb
mlx5_core s390_trng eadm_sch vfio_ccw mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core
dm_multipath drm_panel_orientation_quirks uvdevice diag288_wdt watchdog hmac_s390 prng aes_s390
zfcp scsi_transport_fc pkey_pckmo pkey_cca pkey_ep11 zcrypt paes_s390 phmac_s390 rng_core
scsi_dh_alua pkey scsi_dh_rdac scsi_dh_emc crypto_engine autofs4 ecdsa_generic ecc sha512 [last unloaded: openvswitch]
CPU: 18 UID: 0 PID: 331372 Comm: devlink Tainted: G W 7.2.0-20260712.rc2.git0.e3321fa3034d.300.fc44.s390x+debug #1 PREEMPT
Tainted: [W]=WARN
Hardware name: IBM 9175 ME1 701 (LPAR)
Krnl PSW : 0704c00180000000 0000038139a6771a (__kmem_cache_create_args+0xda/0x480)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000000 0000000000000000 000003813b7de578 00000380b9eb8974
00000276c417f690 00000380b9eb8974 0000030144623348 00000277234a1660
0000000000000020 00000380b9eb8974 00000277234a1600 000003813b686d30
0000000000000000 00000380b9e9a810 0000038139a6771a 0000030144623238
Krnl Code: 0000038139a6770a: c02000ebb737 larl %r2,000003813b7de578
0000038139a67710: b9040039 lgr %r3,%r9
*0000038139a67714: c0e5006e2eb2 brasl %r14,000003813a82d478
>0000038139a6771a: a7390020 lghi %r3,32
0000038139a6771e: b9040029 lgr %r2,%r9
0000038139a67722: c0e5006cf98f brasl %r14,000003813a806a40
0000038139a67728: ec26018e007c cgij %r2,0,6,0000038139a67a44
0000038139a6772e: 58d0f0a4 l %r13,164(%r15)
Call Trace:
[<0000038139a6771a>] __kmem_cache_create_args+0xda/0x480
([<0000038139a676a2>] __kmem_cache_create_args+0x62/0x480)
[<00000380b9da1c70>] dr_domain_init_mem_resources+0x80/0x240 [mlx5_core]
[<00000380b9da226e>] dr_domain_init_resources.constprop.0+0x7e/0x2c0 [mlx5_core]
[<00000380b9da28b2>] mlx5dr_domain_create+0x132/0x250 [mlx5_core]
[<00000380b9dc1e20>] mlx5_cmd_dr_create_ns+0x30/0x90 [mlx5_core]
[<00000380b9cd8dbe>] mlx5_flow_namespace_set_mode+0x6e/0x130 [mlx5_core]
[<00000380b9d846ec>] esw_create_offloads_fdb_tables+0xac/0x5a0 [mlx5_core]
[<00000380b9d865b6>] esw_offloads_steering_init+0x1c6/0x480 [mlx5_core]
[<00000380b9d86e8e>] esw_offloads_enable+0x13e/0x410 [mlx5_core]
[<00000380b9d7b04a>] mlx5_eswitch_enable_locked+0x36a/0x540 [mlx5_core]
[<00000380b9d84ff0>] esw_offloads_start+0x50/0x1d0 [mlx5_core]
[<00000380b9d8774a>] mlx5_devlink_eswitch_mode_set+0x35a/0x3f0 [mlx5_core]
[<000003813a791e68>] devlink_nl_eswitch_set_doit+0x88/0x120
[<000003813a5b93ea>] genl_family_rcv_msg_doit+0xea/0x150
[<000003813a5b95c2>] genl_family_rcv_msg+0x172/0x210
[<000003813a5b96c2>] genl_rcv_msg+0x62/0xc0
[<000003813a5b7cac>] netlink_rcv_skb+0x5c/0x120
[<000003813a5b8f0c>] genl_rcv+0x3c/0x50
[<000003813a5b74a4>] netlink_unicast+0x1f4/0x2b0
[<000003813a5b783c>] netlink_sendmsg+0x2dc/0x460
[<000003813a4c9764>] __sock_sendmsg+0x64/0xd0
[<000003813a4cc878>] __sys_sendto+0x108/0x160
[<000003813a4cdf50>] __do_sys_socketcall+0x350/0x460
[<000003813a8184d2>] __do_syscall+0x172/0x750
[<000003813a82d5d2>] system_call+0x72/0x90
Prefix each cache name with the device name to make it unique.
Fixes: fd785e5213f0 ("net/mlx5: DR, Allocate icm_chunks from their own slab allocator")
Fixes: fb628b71fb2a ("net/mlx5: DR, Allocate htbl from its own slab allocator")
Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Closes: https://lore.kernel.org/all/a3cea501-4d1f-47d5-b6d0-fcda9a0aab16@linux.ibm.com/
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c
index fedefb565a21..c9f20a9033eb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/sws/dr_domain.c
@@ -98,9 +98,12 @@ int mlx5dr_domain_get_recalc_cs_ft_addr(struct mlx5dr_domain *dmn,
static int dr_domain_init_mem_resources(struct mlx5dr_domain *dmn)
{
+ char name[80];
int ret;
- dmn->chunks_kmem_cache = kmem_cache_create("mlx5_dr_chunks",
+ snprintf(name, sizeof(name), "%s-mlx5_dr_chunks",
+ dev_name(dmn->mdev->device));
+ dmn->chunks_kmem_cache = kmem_cache_create(name,
sizeof(struct mlx5dr_icm_chunk), 0,
SLAB_HWCACHE_ALIGN, NULL);
if (!dmn->chunks_kmem_cache) {
@@ -108,7 +111,9 @@ static int dr_domain_init_mem_resources(struct mlx5dr_domain *dmn)
return -ENOMEM;
}
- dmn->htbls_kmem_cache = kmem_cache_create("mlx5_dr_htbls",
+ snprintf(name, sizeof(name), "%s-mlx5_dr_htbls",
+ dev_name(dmn->mdev->device));
+ dmn->htbls_kmem_cache = kmem_cache_create(name,
sizeof(struct mlx5dr_ste_htbl), 0,
SLAB_HWCACHE_ALIGN, NULL);
if (!dmn->htbls_kmem_cache) {
---
base-commit: f8d04b0c74e989c515e0fa17bf779b730077f63e
change-id: 20260715-kmem-dupliate-name-b151167f5119
Best regards,
--
Leon Romanovsky <leonro@nvidia.com>
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: mdio: Kconfig: Group mdio multiplexers in a submenu
From: Maxime Chevallier @ 2026-07-15 8:22 UTC (permalink / raw)
To: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni,
Andrew Lunn
In-Reply-To: <20260715082226.51481-1-maxime.chevallier@bootlin.com>
Move all MDIO muxes under the "MDIO controller drivers" submenu.
This doesn't change any dependency for KConfig options and is
purely cosmetic.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/mdio/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index b845f1c17843..a05229838cb4 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -199,7 +199,7 @@ config MDIO_THUNDER
ThunderX SoCs when the MDIO bus device appears as a PCI
device.
-comment "MDIO Multiplexers"
+menu "MDIO Multiplexers"
config MDIO_BUS_MUX
tristate
@@ -290,3 +290,4 @@ config MDIO_BUS_MUX_MMIOREG
Currently, only 8/16/32 bits registers are supported.
endmenu
+endmenu
--
2.55.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: mdio: Kconfig: Group mdio controller drivers in a submenu
From: Maxime Chevallier @ 2026-07-15 8:22 UTC (permalink / raw)
To: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni
In-Reply-To: <20260715082226.51481-1-maxime.chevallier@bootlin.com>
Currently, all inidivual drivers for MDIO bus controllers are directly
listed under Device drivers -> Network device support. Let's group them
altogether in a submenu, while keeping the dependency on PHYLIB.
No intended functional change besides the menuconfig ordering.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/mdio/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index e57121019153..b845f1c17843 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -3,7 +3,8 @@
# MDIO Layer Configuration
#
-if PHYLIB
+menu "MDIO controller drivers"
+ depends on PHYLIB
config FWNODE_MDIO
def_tristate (ACPI || OF) || COMPILE_TEST
@@ -288,5 +289,4 @@ config MDIO_BUS_MUX_MMIOREG
Currently, only 8/16/32 bits registers are supported.
-
-endif
+endmenu
--
2.55.0
^ permalink raw reply related
* [PATCH net-next v2 0/2] net: mdio: Rearrange Kconfig menus
From: Maxime Chevallier @ 2026-07-15 8:22 UTC (permalink / raw)
To: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit
Cc: Maxime Chevallier, netdev, linux-kernel, thomas.petazzoni
In menuconfig, all MDIO controllers and muxes are listed directly under the
Device drivers -> Network device support menu.
Let's group these in their own subenu :
Device drivers ->
Network device support ->
MDIO controller drivers ->
Mdio driver A
Mdio driver B
...
MDIO Multiplexers ->
MDIO Mux driver A
MDIO Mux driver B
...
There are no functional or KConfig dependency changes in this series,
just menu reorganisation.
V2:
- Add mux submenu
V1: https://lore.kernel.org/r/20260712201739.260742-1-maxime.chevallier@bootlin.com
Maxime Chevallier (2):
net: mdio: Kconfig: Group mdio controller drivers in a submenu
net: mdio: Kconfig: Group mdio multiplexers in a submenu
drivers/net/mdio/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--
2.55.0
^ permalink raw reply
* [PATCH net v2] mctp: serial: handle zero-length frames to prevent rx buffer overflow
From: Doruk Tan Ozturk @ 2026-07-15 8:20 UTC (permalink / raw)
To: jk, matt, andrew+netdev, davem, edumazet, kuba, pabeni
Cc: netdev, linux-kernel, stable
The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:
if (c > MCTP_SERIAL_FRAME_MTU) {
dev->rxstate = STATE_ERR;
} else {
dev->rxlen = c;
dev->rxpos = 0;
dev->rxstate = STATE_DATA;
...
}
A length of zero passes this check, so rxlen is set to 0 and the state
machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the
incoming byte is stored and rxpos incremented before the terminator is
tested:
dev->rxbuf[dev->rxpos] = c;
dev->rxpos++;
dev->rxstate = STATE_DATA;
if (dev->rxpos == dev->rxlen) {
dev->rxpos = 0;
dev->rxstate = STATE_TRAILER;
}
With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is
already 1 on the first data byte), so subsequent bytes are written past
the end of the fixed 74-byte rxbuf, which is the last member of the
netdev private area. Every following data byte is an attacker-controlled
1-byte out-of-bounds heap write, and the overflow continues until a
frame (0x7e) or escape byte resets the parser -- effectively unbounded.
Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line
discipline and bring the resulting mctpserialN netdev up, after which
the bytes arrive via the tty receive path.
Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes are still consumed, and the frame
resolves to a zero-length skb that the MCTP core rejects; the parser
never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can
no longer occur.
KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this
change):
UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370
index 74 is out of range for type 'u8 [74]'
BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf
Write of size 1 at addr ... by task kworker/u16:0
mctp_serial_tty_receive_buf
tty_ldisc_receive_buf
flush_to_ldisc
Allocated by task 152:
alloc_netdev_mqs
mctp_serial_open
v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so
the trailer/framing bytes are still consumed (Jeremy Kerr).
Found by 0sec automated security-research tooling (https://0sec.ai).
Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding")
Cc: stable@vger.kernel.org
Suggested-by: Jeremy Kerr <jk@codeconstruct.com.au>
Assisted-by: 0sec:multi-model
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
drivers/net/mctp/mctp-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mctp/mctp-serial.c b/drivers/net/mctp/mctp-serial.c
index 26c9a33fd636..a5070ffa9a95 100644
--- a/drivers/net/mctp/mctp-serial.c
+++ b/drivers/net/mctp/mctp-serial.c
@@ -318,7 +318,7 @@ static void mctp_serial_push_header(struct mctp_serial *dev, u8 c)
} else {
dev->rxlen = c;
dev->rxpos = 0;
- dev->rxstate = STATE_DATA;
+ dev->rxstate = c > 0 ? STATE_DATA : STATE_TRAILER;
dev->rxfcs = crc_ccitt_byte(dev->rxfcs, c);
}
break;
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH 01/10] net: stmmac: move XPCS lifetime management to platform drivers
From: Coia Prant @ 2026-07-15 8:17 UTC (permalink / raw)
To: Maxime Chevallier
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, robh, krzk+dt,
heiko, netdev, linux-rockchip, devicetree, linux-arm-kernel,
linux-phy, Christian Marangi
In-Reply-To: <dc21b2fc-ae11-4fde-a5b9-09e2c6bee5c9@bootlin.com>
Maxime Chevallier <maxime.chevallier@bootlin.com> 于2026年7月15日周三 15:31写道：
>
> Hi,
>
> +Christian
>
> On 7/14/26 21:08, Coia Prant wrote:
> > The current XPCS creation logic in stmmac_pcs_setup() is problematic
> > for several reasons.
> >
> > First, if a device tree specifies a "pcs-handle" but no select_pcs()
> > callback is provided by the platform driver, the created XPCS is never
> > used. The phylink framework requires select_pcs() to actually return
> > the PCS to the core, so the pcs-handle property becomes effectively
> > useless without the matching callback. This is confusing for developers
> > who expect that specifying a pcs-handle in their device tree should be
> > sufficient to enable the PCS.
>
> I think Christian's work on fwnode PCS would help a lot with that PCS
> handling in stmmac:
>
> https://lore.kernel.org/netdev/20260618125752.1223-1-ansuelsmth@gmail.com/
>
> I don't know when Christian plans to iterate, it could be worth using
> that new fwnode mechanism here ?
>
> Maxime
Hi Maxime,
Thanks for pointing me to Christian's work. This looks like a
much-needed improvement.
I actually spent all night debugging call traces caused by the current
stmmac PCS lifetime management, and it was not a pleasant experience.
The code feels like accumulated technical debt that should be cleaned
up.
Regarding timeline: since Christian's series is still in RFC with an
uncertain merge date, I'd prefer to keep this series as-is for now, as
it solves the problem for Rockchip and has already started receiving
review feedback. Once Christian's fwnode PCS work lands in net-next,
I'm happy to rebase and convert the Rockchip glue driver to the new
interface.
One thing I'd really like to see: the ability to specify the logical
MII port instance via something like:
pcs-handle = <&pcs MII_PortX>;
That would make the DT binding much cleaner and more flexible for
multi-port configurations.
Thanks,
Coia
^ permalink raw reply
* [PATCH 00/12] vhost: cleanups and improvements - PLEASE IGNORE
From: Weimin Xiong @ 2026-07-15 8:14 UTC (permalink / raw)
To: virtualization
Cc: kvm, netdev, linux-kernel, mst, jasowangio, michael.christie
Please ignore the previous series "[PATCH 00/12] vhost: cleanups and improvements"
sent earlier today. There were missing CC recipients. A corrected version
will be resent shortly.
Sorry for the noise.
Weimin Xiong
^ permalink raw reply
* Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
From: Ayoub Kaanich @ 2026-07-15 8:09 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Russell King, netdev@vger.kernel.org
In-Reply-To: <23323308-6278-47ba-834e-662b0e408705@lunn.ch>
Hi,
> In general, we are trying to block user space drivers, by only allowing read.
So in principle, a write from a third party driver (not the NIC own driver) is allowed?
> What protocol does it use? Have you seen drivers/net/mdio/mdio-i2c.c.
> That currently implements two different C22 or C45 over I2C.
Our current addressing schema does not fit C22, C45 or ROLLBALL.
Even if we were to change it (not sure of possible) or add another addressing schema to mdio-i2c.c, there is still one fundamental issue:
Our issue is that the NIC drivers (especially the netlink based drivers), have no standard way to expose the I2C bus of the SFP module to other drivers.
phylink based drivers don't have this issue.
The current hierarchy is
net_device => sfp_bus (missing in many drivers) => sfp (internal) => i2c_adapter
For example: ice driver does not create an i2c_adapter or sfp_bus, even though many of the NICs using that driver have SFP28 or QSFP28 pluggable cages.
This means no i2c_adapter and no sfp_bus are available to build the mii_bus on when using ice driver.
Best Regards.
Ayoub Kaanich
Principal Software Engineer
Engineering Department
________________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Tuesday, July 14, 2026 09:55 PM
To: Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>
Cc: Russell King <linux@armlinux.org.uk>; netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> There is no equivalent SET. ethtool --set-module-eeprom (both
> netlink and the legacy ioctl fallback)
In general, we are trying to block user space drivers, by only
allowing read.
> Concrete use case:
>
> We (Technica Engineering) manufacture automotive SFP/SFP+ modules for 100/1000BASE-T1 and multi-gig automotive Ethernet (TE-1441, PT-1445). Alongside the standard SFF-8472 EEPROM at 0x50, these modules expose an I2C-to-MDIO gateway at I2C address 0x40 (0x80/0x81 as 8-bit read/write):
>
> Writes to that address are relayed by the module's own logic as MDIO Clause 22/45 transactions to the embedded automotive PHY, giving access to link speed, master/slave mode, and other PHY configuration without needing register-level documentation of the PHY itself.
What protocol does it use? Have you seen drivers/net/mdio/mdio-i2c.c.
That currently implements two different C22 or C45 over I2C.
You should add your protocol here, and then Linux can just drive the
PHY, like it does for any other PHY.
Andrew
^ permalink raw reply
* Re: [PATCH RFC net-next] net: phy: sfp: drop 1000Base-T support for FCLF8521P2BTL
From: Maxime Chevallier @ 2026-07-15 8:00 UTC (permalink / raw)
To: Michael Walle, Russell King, Andrew Lunn, Heiner Kallweit,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel
In-Reply-To: <20260714125008.2466023-1-mwalle@kernel.org>
On 7/14/26 14:49, Michael Walle wrote:
> The FCLF8521P2BTL is marketed as a drop in replacement for fiber
> modules using 1000Base-X autoneg towards the host as default. See the
> referenced application note, esp. question #11. Drop the 1000baseT
> capability, so 1000Base-X will eventually be used.
>
> This is esp. important if the TX_DISABLE pin is not connected on a
> board. Usually, pin is used as a reset line to the PHY on the copper
> SFP. If a bootloader expects the default mode and doesn't do any
> reconfiguration of the SFP module, a link might not be established.
>
> Link: https://www.coherent.com/resources/application-note/networking/1000base-t-sfp-faq-an-2036.pdf
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> I'm not sure, this is the correct place for the fix, nor if it goes in
> the right direction. There is a comment in
>
> /*
> * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
> * negotiation enabled, but some may be in 1000base-X - which is for the
> * PHY driver to determine.
> */
>
> I haven't found any traces of that though. So any pointers, what flags
> have to be modified is appreciated (phydev->supported?
> phydev->possible_interfaces?).
Well I've tried in the past to change the resolution of the phy_interface_t
for a module, possible_interfaces won't work as this is populated too late
(at config init time), and we do the SFP interface resolution before that.
What we need is for PHYs to expose the list of interfaces they support at
drive-probe time.
Thing is, Russell has code for that :
http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue
but that code isn't upstream. I've tried to ask multiple times how we should
go forward with that, but with no reply :
https://lore.kernel.org/netdev/20260114225731.811993-3-maxime.chevallier@bootlin.com/
Russell's supported_interfaces approach works, I'm using that for SGMII to 100FX
modules, but the question is "how do we upstream that", especially with Russell
being away at the time :(
Maxime
^ 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