summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-01-23geneve: extract hint option at GRO stagePaolo Abeni1-5/+183
Add helpers for finding a GRO hint option in the geneve header, performing basic sanitization of the option offsets vs the actual packet layout, validate the option for GRO aggregation and check the nested header checksum. The validation helper closely mirrors similar check performed by the ipv4 and ipv6 gro callbacks, with the additional twist of accessing the relevant network header via the GRO hint offset. To validate the nested UDP checksum, leverage the csum completed of the outer header, similarly to LCO, with the main difference that in this case we have the outer checksum available. Use the helpers to extract the hint info at the GRO stage. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/cd0e9dc42ba83f388b604097cffe268ffcb53351.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23geneve: add GRO hint output pathPaolo Abeni1-4/+120
If a geneve egress packet contains nested UDP encap headers, add a geneve option including the information necessary on the RX side to perform GRO aggregation of the whole packets: the nested network and transport headers, and the nested protocol type. Use geneve option class `netdev`, already registered in the Network Virtualization Overlay (NVO3) IANA registry: https://www.iana.org/assignments/nvo3/nvo3.xhtml#Linux-NetDev. To pass the GRO hint information across the different xmit path functions, store them in the skb control buffer, to avoid adding additional arguments. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/aa614567f7bdb776d693041375bede4990a19649.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23geneve: pass the geneve device ptr to geneve_build_skb()Paolo Abeni1-12/+8
Instead of handing to it the geneve configuration in multiple arguments. This already avoids some code duplication and we are going to pass soon more arguments to such function. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/761f05690646181fffc533ee4db59b68e5c3a0c3.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23geneve: constify geneve_hlen()Paolo Abeni1-5/+5
Such helper does not modify the argument; constifying it will additionally simplify later patches. Additionally move the definition earlier, still for later's patchesi sake. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/ea9e279b9544e8644194508dd9a4320ee455fa95.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23geneve: add netlink support for GRO hintPaolo Abeni3-4/+29
Allow configuring and dumping the new device option, and cache its value into the geneve socket itself. The new option is not tie to it any code yet. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/2295d4e4d1e919a3189425141bbc71c7850a2de0.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23vxlan: expose gso partial features for tunnel offloadPaolo Abeni1-3/+13
Similar to the previous patch, reuse the same helpers to add tunnel GSO partial capabilities to vxlan devices. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/93d916c11b3a790a8bfccad77d9e85ee6e533042.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23geneve: expose gso partial features for tunnel offloadPaolo Abeni2-1/+42
GSO partial features for tunnels do not require any kind of support from the underlying device: we can safely add them to the geneve UDP tunnel. The only point of attention is the skb required features propagation in the device xmit op: partial features must be stripped, except for UDP_TUNNEL*. Keep partial features disabled by default. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/d851ca8e928cf05d68310bcbaeaa5e9e0b01e058.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: introduce mangleid_featuresPaolo Abeni2-1/+7
Some/most devices implementing gso_partial need to disable the GSO partial features when the IP ID can't be mangled; to that extend each of them implements something alike the following[1]: if (skb->encapsulation && !(features & NETIF_F_TSO_MANGLEID)) features &= ~NETIF_F_TSO; in the ndo_features_check() op, which leads to a bit of duplicate code. Later patch in the series will implement GSO partial support for virtual devices, and the current status quo will require more duplicate code and a new indirect call in the TX path for them. Introduce the mangleid_features mask, allowing the core to disable NIC features based on/requiring MANGLEID, without any further intervention from the driver. The same functionality could be alternatively implemented adding a single boolean flag to the struct net_device, but would require an additional checks in ndo_features_check(). Also note that [1] is incorrect if the NIC additionally implements NETIF_F_GSO_UDP_L4, mangleid_features transparently handle even such a case. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/5a7cdaeea40b0a29b88e525b6c942d73ed3b8ce7.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23Merge branch 'net-convert-drivers-to-get_rx_ring_count-last-part'Jakub Kicinski14-73/+75
Breno Leitao says: ==================== net: convert drivers to .get_rx_ring_count (last part) Commit 84eaf4359c36 ("net: ethtool: add get_rx_ring_count callback to optimize RX ring queries") added specific support for GRXRINGS callback, simplifying .get_rxnfc. Remove the handling of GRXRINGS in .get_rxnfc() by moving it to the new .get_rx_ring_count(). This simplifies the RX ring count retrieval and aligns the following drivers with the new ethtool API for querying RX ring parameters. * sfc * ionic * sfc/siena * sfc/ef100 * fbnic * mana * nfp * atlantic * benet (this is v2 in fact, where v1 had some discussions that required a v2). See link [0] Link: https://lore.kernel.org/all/20260119094514.5b12a097@kernel.org/ [0] This is covering the last drivers, and as soon as this lands, I will change the ethtool framework to avoid calling .get_rx_ring_count for ETHTOOL_GRXRINGS, simplifying the ethtool core framework. ==================== Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-0-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: sfc: falcon: convert to use .get_rx_ring_countBreno Leitao1-4/+8
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-9-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: sfc: siena: convert to use .get_rx_ring_countBreno Leitao3-4/+9
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-8-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: sfc: efx: convert to use .get_rx_ring_countBreno Leitao4-4/+10
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-7-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: ionic: convert to use .get_rx_ring_countBreno Leitao1-15/+3
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Since ETHTOOL_GRXRINGS was the only command handled by ionic_get_rxnfc(), remove the function entirely. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-6-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: fbnic: convert to use .get_rx_ring_countBreno Leitao1-4/+8
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-5-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: mana: convert to use .get_rx_ring_countBreno Leitao1-10/+3
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Since ETHTOOL_GRXRINGS was the only command handled by mana_get_rxnfc(), remove the function entirely. Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-4-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: nfp: convert to use .get_rx_ring_countBreno Leitao1-3/+8
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-3-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: atlantic: convert to use .get_rx_ring_countBreno Leitao1-6/+12
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-2-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: benet: convert to use .get_rx_ring_countBreno Leitao1-23/+14
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of handling ETHTOOL_GRXRINGS directly in .get_rxnfc(). Since ETHTOOL_GRXRINGS was the only command handled by be_get_rxnfc(), remove the function entirely. Since the be_multi_rxq() check in be_get_rxnfc() previously blocked RSS configuration on single-queue setups (via ethtool core validation), add an equivalent check to be_set_rxfh() to preserve this behavior, as suggested by Jakub. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20260122-grxring_big_v4-v2-1-94dbe4dcaa10@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23tcp: move tcp_stream_memory_free() to tcp.cEric Dumazet2-14/+13
Moving tcp_stream_memory_free() to tcp.c allows the compiler to (auto)inline it from tcp_poll() and tcp_sendmsg_locked() for better performance. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 2/0 up/down: 118/0 (118) Function old new delta tcp_poll 840 923 +83 tcp_sendmsg_locked 4217 4252 +35 Total: Before=22573095, After=22573213, chg +0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://patch.msgid.link/20260122090228.1678207-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23MAINTAINERS: remove obsolete file entry in NETWORKING DRIVERSLukas Bulwahn1-1/+0
Commit d8f87aa5fa0a ("net: remove HIPPI support and RoadRunner HIPPI driver") removes the hippidevice header file, but misses that there is still a file entry in MAINTAINERS referring to it. Remove the obsolete file entry in NETWORKING DRIVERS. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260122074609.151058-1-lukas.bulwahn@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski425-2343/+4715
Cross-merge networking fixes after downstream PR (net-6.19-rc7). Conflicts: drivers/net/ethernet/huawei/hinic3/hinic3_irq.c b35a6fd37a00 ("hinic3: Add adaptive IRQ coalescing with DIM") fb2bb2a1ebf7 ("hinic3: Fix netif_queue_set_napi queue_index input parameter error") https://lore.kernel.org/fc0a7fdf08789a52653e8ad05281a0a849e79206.1768915707.git.zhuyikai1@h-partners.com drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/wifi7/hw.c 31707572108d ("wifi: ath12k: Fix wrong P2P device link id issue") c26f294fef2a ("wifi: ath12k: Move ieee80211_ops callback to the arch specific module") https://lore.kernel.org/20260114123751.6a208818@canb.auug.org.au Adjacent changes: drivers/net/wireless/ath/ath12k/mac.c 8b8d6ee53dfd ("wifi: ath12k: Fix scan state stuck in ABORTING after cancel_remain_on_channel") 914c890d3b90 ("wifi: ath12k: Add framework for hardware specific ieee80211_ops registration") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: phy: Grammar update for comment in genphy_update_linkSimon Horman1-1/+1
Enhance the grammar of the comment in genphy_update_link() describing momentary link drop handling. Found by inspection. Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260121-phy-gra-v1-1-8b4d178939de@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23selftests: net: Add kernel selftest for RFC 4884Danielle Ratson3-0/+681
RFC 4884 extended certain ICMP messages with a length attribute that encodes the length of the "original datagram" field. This is needed so that new information could be appended to these messages without applications thinking that it is part of the "original datagram" field. In version 5.9, the kernel was extended with two new socket options (SOL_IP/IP_RECVERR_4884 and SOL_IPV6/IPV6_RECVERR_RFC4884) that allow user space to retrieve this length which is basically the offset to the ICMP Extension Structure at the end of the ICMP message. This is required by user space applications that need to parse the information contained in the ICMP Extension Structure. For example, the RFC 5837 extension for tracepath. Add a selftest that verifies correct handling of the RFC 4884 length field for both IPv4 and IPv6, with and without extension structures, and validates that malformed extensions are correctly reported as invalid. For each address family, the test creates: - a raw socket used to send locally crafted ICMP error packets to the loopback address, and - a datagram socket used to receive the encapsulated original datagram and associated error metadata from the kernel error queue. ICMP packets are constructed entirely in user space rather than relying on kernel-generated errors. This allows the test to exercise invalid scenarios (such as corrupted checksums and incorrect length fields) and verify that the SO_EE_RFC4884_FLAG_INVALID flag is set as expected. Output Example: $ ./icmp_rfc4884 Starting 18 tests from 18 test cases. RUN rfc4884.ipv4_ext_small_payload.rfc4884 ... OK rfc4884.ipv4_ext_small_payload.rfc4884 ok 1 rfc4884.ipv4_ext_small_payload.rfc4884 RUN rfc4884.ipv4_ext.rfc4884 ... OK rfc4884.ipv4_ext.rfc4884 ok 2 rfc4884.ipv4_ext.rfc4884 RUN rfc4884.ipv4_ext_large_payload.rfc4884 ... OK rfc4884.ipv4_ext_large_payload.rfc4884 ok 3 rfc4884.ipv4_ext_large_payload.rfc4884 RUN rfc4884.ipv4_no_ext_small_payload.rfc4884 ... OK rfc4884.ipv4_no_ext_small_payload.rfc4884 ok 4 rfc4884.ipv4_no_ext_small_payload.rfc4884 RUN rfc4884.ipv4_no_ext_min_payload.rfc4884 ... OK rfc4884.ipv4_no_ext_min_payload.rfc4884 ok 5 rfc4884.ipv4_no_ext_min_payload.rfc4884 RUN rfc4884.ipv4_no_ext_large_payload.rfc4884 ... OK rfc4884.ipv4_no_ext_large_payload.rfc4884 ok 6 rfc4884.ipv4_no_ext_large_payload.rfc4884 RUN rfc4884.ipv4_invalid_ext_checksum.rfc4884 ... OK rfc4884.ipv4_invalid_ext_checksum.rfc4884 ok 7 rfc4884.ipv4_invalid_ext_checksum.rfc4884 RUN rfc4884.ipv4_invalid_ext_length_small.rfc4884 ... OK rfc4884.ipv4_invalid_ext_length_small.rfc4884 ok 8 rfc4884.ipv4_invalid_ext_length_small.rfc4884 RUN rfc4884.ipv4_invalid_ext_length_large.rfc4884 ... OK rfc4884.ipv4_invalid_ext_length_large.rfc4884 ok 9 rfc4884.ipv4_invalid_ext_length_large.rfc4884 RUN rfc4884.ipv6_ext_small_payload.rfc4884 ... OK rfc4884.ipv6_ext_small_payload.rfc4884 ok 10 rfc4884.ipv6_ext_small_payload.rfc4884 RUN rfc4884.ipv6_ext.rfc4884 ... OK rfc4884.ipv6_ext.rfc4884 ok 11 rfc4884.ipv6_ext.rfc4884 RUN rfc4884.ipv6_ext_large_payload.rfc4884 ... OK rfc4884.ipv6_ext_large_payload.rfc4884 ok 12 rfc4884.ipv6_ext_large_payload.rfc4884 RUN rfc4884.ipv6_no_ext_small_payload.rfc4884 ... OK rfc4884.ipv6_no_ext_small_payload.rfc4884 ok 13 rfc4884.ipv6_no_ext_small_payload.rfc4884 RUN rfc4884.ipv6_no_ext_min_payload.rfc4884 ... OK rfc4884.ipv6_no_ext_min_payload.rfc4884 ok 14 rfc4884.ipv6_no_ext_min_payload.rfc4884 RUN rfc4884.ipv6_no_ext_large_payload.rfc4884 ... OK rfc4884.ipv6_no_ext_large_payload.rfc4884 ok 15 rfc4884.ipv6_no_ext_large_payload.rfc4884 RUN rfc4884.ipv6_invalid_ext_checksum.rfc4884 ... OK rfc4884.ipv6_invalid_ext_checksum.rfc4884 ok 16 rfc4884.ipv6_invalid_ext_checksum.rfc4884 RUN rfc4884.ipv6_invalid_ext_length_small.rfc4884 ... OK rfc4884.ipv6_invalid_ext_length_small.rfc4884 ok 17 rfc4884.ipv6_invalid_ext_length_small.rfc4884 RUN rfc4884.ipv6_invalid_ext_length_large.rfc4884 ... OK rfc4884.ipv6_invalid_ext_length_large.rfc4884 ok 18 rfc4884.ipv6_invalid_ext_length_large.rfc4884 PASSED: 18 / 18 tests passed. Totals: pass:18 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260121114644.2863640-1-danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23Merge branch 'tcp-remove-tcp_rate-c'Jakub Kicinski5-135/+130
Eric Dumazet says: ==================== tcp: remove tcp_rate.c Move tcp_rate_gen() to tcp_input.c and tcp_rate_check_app_limited() to tcp.c for better code generation. tcp_rate.c was interesting from code maintenance perspective but was adding cpu costs. ==================== Link: https://patch.msgid.link/20260121095923.3134639-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23tcp: move tcp_rate_check_app_limited() to tcp.cEric Dumazet4-23/+20
tcp_rate_check_app_limited() is used from tcp_sendmsg_locked() fast path and from other callers. Move it to tcp.c so that it can be inlined in tcp_sendmsg_locked(). Small increase of code, for better TCP performance. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 1/0 up/down: 87/0 (87) Function old new delta tcp_sendmsg_locked 4217 4304 +87 Total: Before=22566462, After=22566549, chg +0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://patch.msgid.link/20260121095923.3134639-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23tcp: move tcp_rate_gen to tcp_input.cEric Dumazet3-112/+110
This function is called from one caller only, in TCP fast path. Move it to tcp_input.c so that compiler can inline it. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/2 grow/shrink: 1/0 up/down: 226/-300 (-74) Function old new delta tcp_ack 5405 5631 +226 __pfx_tcp_rate_gen 16 - -16 tcp_rate_gen 284 - -284 Total: Before=22566536, After=22566462, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://patch.msgid.link/20260121095923.3134639-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23Merge branch 'net-stmmac-dwmac-enforce-preamble-before-sfd-for-i-mx8mp'Jakub Kicinski5-5/+29
Stefan Eichenberger says: ==================== net: stmmac: dwmac: enforce preamble before SFD for i.MX8MP This series adds a new phy_device flag PHY_F_KEEP_PREAMBLE_BEFORE_SFD that allows a MAC driver to request to keep the preamble bytes before the start frame delimiter (SFD) when receiving frames from the PHY. This flag is set in the stmmac driver for the i.MX8MP SoC due to errata (ERR050694), which causes it to drop frames without a preamble. The Micrel KSZ9131 PHY supports keeping the preamble before SFD by setting an undocumented flag, that was confirmed by NXP and Micrel. This new feature has been added to the Micrel PHY driver for the KSZ9131 PHY. ==================== Link: https://patch.msgid.link/20260120203905.23805-1-eichest@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: stmmac: dwmac-imx: keep preamble before sfd on i.MX8MPStefan Eichenberger3-2/+13
The stmmac implementation used by NXP for the i.MX8MP SoC is subject to errata ERR050694. According to this errata, when no preamble byte is transferred before the SFD from the PHY to the MAC, the MAC will discard the frame. Setting the PHY_F_KEEP_PREAMBLE_BEFORE_SFD flag instructs PHYs that support it to keep the preamble byte before the SFD. This ensures that the MAC successfully receives frames. As this is an issue in the MAC implementation, only enable the flag for the i.MX8MP SoC where the errata applies but not for other SoCs using a working stmmac implementation. The exact wording of the errata ERR050694 from NXP: The IEEE 802.3 standard states that, in MII/GMII modes, the byte preceding the SFD (0xD5), SMD-S (0xE6,0x4C, 0x7F, or 0xB3), or SMD-C (0x61, 0x52, 0x9E, or 0x2A) byte can be a non-PREAMBLE byte or there can be no preceding preamble byte. The MAC receiver must successfully receive a packet without any preamble(0x55) byte preceding the SFD, SMD-S, or SMD-C byte. However due to the defect, in configurations where frame preemption is enabled, when preamble byte does not precede the SFD, SMD-S, or SMD-C byte, the received packet is discarded by the MAC receiver. This is because, the start-of-packet detection logic of the MAC receiver incorrectly checks for a preamble byte. NXP refers to IEEE 802.3 where in clause 35.2.3.2.2 Receive case (GMII) they show two tables one where the preamble is preceding the SFD and one where it is not. The text says: The operation of 1000 Mb/s PHYs can result in shrinkage of the preamble between transmission at the source GMII and reception at the destination GMII. Table 35-3 depicts the case where no preamble bytes are conveyed across the GMII. This case may not be possible with a specific PHY, but illustrates the minimum preamble with which MAC shall be able to operate. Table 35-4 depicts the case where the entire preamble is conveyed across the GMII. This workaround was tested on a Verdin iMX8MP by enforcing 10 MBit/s: ethtool -s end0 speed 10 Without keeping the preamble, no packet were received. With keeping the preamble, everything worked as expected. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260120203905.23805-4-eichest@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: phy: micrel: add option to keep the preamble before sfd for KSZ9131Stefan Eichenberger1-1/+13
If the PHY_F_KEEP_PREAMBLE_BEFORE_SFD flag is set in the phy_device::dev_flags field, the preamble will be kept before the start frame delimiter (SFD) on the KSZ9131 PHY. This flag is not officially documented by Micrel. However, information provided by NXP and Micrel indicates that this flag ensures the PHY sends the full preamble instead of removing it. The full discussion can be found on the NXP forum: https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032 Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260120203905.23805-3-eichest@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23net: phy: add a new phy_device flag to keep preamble before sfdStefan Eichenberger1-2/+3
Add a new flag, PHY_F_KEEP_PREAMBLE_BEFORE_SFD, to indicate that the PHY shall not remove the preamble before the SFD if it supports it. MACs that do not support receiving frames without a preamble can set this flag. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260120203905.23805-2-eichest@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23Merge tag 'nf-next-26-01-22' of ↵Jakub Kicinski4-145/+291
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next Florian Westphal says: ==================== netfilter: updates for net-next There is an issue with interval matching in nftables rbtree set type: When userspace sends us set updates, there is a brief window where false negative lookups may occur from the data plane. Quoting Pablos original cover letter: This series addresses this issue by translating the rbtree, which keeps the intervals in order, to binary search. The array is published to packet path through RCU. The idea is to keep using the rbtree datastructure for control plane, which needs to deal with updates, then generate an array using this rbtree for binary search lookups. Patch #1 allows to call .remove in case .abort is defined, which is needed by this new approach. Only pipapo needs to skip .remove to speed. Patch #2 add the binary search array approach for interval matching. Patch #3 updates .get to use the binary search array to find for (closest or exact) interval matching. Patch #4 removes seqcount_rwlock_t as it is not needed anymore (new in this series). * tag 'nf-next-26-01-22' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: netfilter: nft_set_rbtree: remove seqcount_rwlock_t netfilter: nft_set_rbtree: use binary search array in get command netfilter: nft_set_rbtree: translate rbtree to array for binary search netfilter: nf_tables: add .abort_skip_removal flag for set types ==================== Link: https://patch.msgid.link/20260122162935.8581-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22Merge tag 'net-6.19-rc7' of ↵Linus Torvalds108-472/+1144
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Including fixes from CAN and wireless. Pretty big, but hard to make up any cohesive story that would explain it, a random collection of fixes. The two reverts of bad patches from this release here feel like stuff that'd normally show up by rc5 or rc6. Perhaps obvious thing to say, given the holiday timing. That said, no active investigations / regressions. Let's see what the next week brings. Current release - fix to a fix: - can: alloc_candev_mqs(): add missing default CAN capabilities Current release - regressions: - usbnet: fix crash due to missing BQL accounting after resume - Revert "net: wwan: mhi_wwan_mbim: Avoid -Wflex-array-member-not ... Previous releases - regressions: - Revert "nfc/nci: Add the inconsistency check between the input ... Previous releases - always broken: - number of driver fixes for incorrect use of seqlocks on stats - rxrpc: fix recvmsg() unconditional requeue, don't corrupt rcv queue when MSG_PEEK was set - ipvlan: make the addrs_lock be per port avoid races in the port hash table - sched: enforce that teql can only be used as root qdisc - virtio: coalesce only linear skb - wifi: ath12k: fix dead lock while flushing management frames - eth: igc: reduce TSN TX packet buffer from 7KB to 5KB per queue" * tag 'net-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (96 commits) Octeontx2-af: Add proper checks for fwdata dpll: Prevent duplicate registrations net/sched: act_ife: avoid possible NULL deref hinic3: Fix netif_queue_set_napi queue_index input parameter error vsock/test: add stream TX credit bounds test vsock/virtio: cap TX credit to local buffer size vsock/test: fix seqpacket message bounds test vsock/virtio: fix potential underflow in virtio_transport_get_credit() net: fec: account for VLAN header in frame length calculations net: openvswitch: fix data race in ovs_vport_get_upcall_stats octeontx2-af: Fix error handling net: pcs: pcs-mtk-lynxi: report in-band capability for 2500Base-X rxrpc: Fix data-race warning and potential load/store tearing net: dsa: fix off-by-one in maximum bridge ID determination net: bcmasp: Fix network filter wake for asp-3.0 bonding: provide a net pointer to __skb_flow_dissect() selftests: net: amt: wait longer for connection before sending packets be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list Revert "net: wwan: mhi_wwan_mbim: Avoid -Wflex-array-member-not-at-end warning" netrom: fix double-free in nr_route_frame() ...
2026-01-22Merge tag 'leds-fixes-6.19' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED fix from Lee Jones: - Fix race condition leading to null pointer dereference on ThinkPad * tag 'leds-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: leds: led-class: Only Add LED to leds_list when it is fully ready
2026-01-22netfilter: nft_set_rbtree: remove seqcount_rwlock_tPablo Neira Ayuso1-6/+0
After the conversion to binary search array, this is not required anymore. Remove it. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-22netfilter: nft_set_rbtree: use binary search array in get commandPablo Neira Ayuso1-90/+64
Rework .get interface to use the binary search array, this needs a specific lookup function to match on end intervals (<=). Packet path lookup is slight different because match is on lesser value, not equal (ie. <). After this patch, seqcount can be removed in a follow up patch. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-22netfilter: nft_set_rbtree: translate rbtree to array for binary searchPablo Neira Ayuso1-84/+257
The rbtree can temporarily store overlapping inactive elements during the transaction processing, leading to false negative lookups. To address this issue, this patch adds a .commit function that walks the the rbtree to build a array of intervals of ordered elements. This conversion compacts the two singleton elements that represent the start and the end of the interval into a single interval object for space efficient. Binary search is O(log n), similar to rbtree lookup time, therefore, performance number should be similar, and there is an implementation available under lib/bsearch.c and include/linux/bsearch.h that is used for this purpose. This slightly increases memory consumption for this new array that stores pointers to the start and the end of the interval. With this patch: # time nft -f 100k-intervals-set.nft real 0m4.218s user 0m3.544s sys 0m0.400s Without this patch: # time nft -f 100k-intervals-set.nft real 0m3.920s user 0m3.547s sys 0m0.276s With this patch, with IPv4 intervals: baseline rbtree (match on first field only): 15254954pps Without this patch: baseline rbtree (match on first field only): 10256119pps This provides a ~50% improvement in matching intervals from packet path. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-22netfilter: nf_tables: add .abort_skip_removal flag for set typesPablo Neira Ayuso3-1/+6
The pipapo set backend is the only user of the .abort interface so far. To speed up pipapo abort path, removals are skipped. The follow up patch updates the rbtree to use to build an array of ordered elements, then use binary search. This needs a new .abort interface but, unlike pipapo, it also need to undo/remove elements. Add a flag and use it from the pipapo set backend. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-01-22Octeontx2-af: Add proper checks for fwdataHariprasad Kelam2-1/+4
firmware populates MAC address, link modes (supported, advertised) and EEPROM data in shared firmware structure which kernel access via MAC block(CGX/RPM). Accessing fwdata, on boards booted with out MAC block leading to kernel panics. Internal error: Oops: 0000000096000005 [#1] SMP [ 10.460721] Modules linked in: [ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT [ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT) [ 10.479793] Workqueue: events work_for_cpu_fn [ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.491124] pc : rvu_sdp_init+0x18/0x114 [ 10.495051] lr : rvu_probe+0xe58/0x1d18 Fixes: 997814491cee ("Octeontx2-af: Fetch MAC channel info from firmware") Fixes: 5f21226b79fd ("Octeontx2-pf: ethtool: support multi advertise mode") Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Link: https://patch.msgid.link/20260121094819.2566786-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22dpll: Prevent duplicate registrationsIvan Vecera1-8/+4
Modify the internal registration helpers dpll_xa_ref_{dpll,pin}_add() to reject duplicate registration attempts. Previously, if a caller attempted to register the same pin multiple times (with the same ops, priv, and cookie) on the same device, the core silently increments the reference count and return success. This behavior is incorrect because if the caller makes these duplicate registrations then for the first one dpll_pin_registration is allocated and for others the associated dpll_pin_ref.refcount is incremented. During the first unregistration the associated dpll_pin_registration is freed and for others WARN is fired. Fix this by updating the logic to return `-EEXIST` if a matching registration is found to enforce a strict "register once" policy. Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260121130012.112606-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22net/sched: act_ife: avoid possible NULL derefEric Dumazet1-2/+4
tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: <TASK> ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798 Fixes: 295a6e06d21e ("net/sched: act_ife: Change to use ife module") Reported-by: syzbot+5cf914f193dffde3bd3c@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6970d61d.050a0220.706b.0010.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Yotam Gigi <yotam.gi@gmail.com> Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260121133724.3400020-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22hinic3: Fix netif_queue_set_napi queue_index input parameter errorFan Gong1-9/+13
Incorrectly transmitted interrupt number instead of queue number when using netif_queue_set_napi. Besides, move this to appropriate code location to set napi. Remove redundant netif_stop_subqueue beacuase it is not part of the hinic3_send_one_skb process. Fixes: 17fcb3dc12bb ("hinic3: module initialization and tx/rx logic") Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com> Signed-off-by: Fan Gong <gongfan1@huawei.com> Link: https://patch.msgid.link/7b8e4eb5c53cbd873ee9aaefeb3d9dbbaff52deb.1769070766.git.zhuyikai1@h-partners.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22Merge tag 'wireless-2026-11-22' of ↵Jakub Kicinski15-150/+171
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Another set of updates: - various small fixes for ath10k/ath12k/mwifiex/rsi - cfg80211 fix for HE bitrate overflow - mac80211 fixes - S1G beacon handling in scan - skb tailroom handling for HW encryption - CSA fix for multi-link - handling of disabled links during association * tag 'wireless-2026-11-22' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: cfg80211: ignore link disabled flag from userspace wifi: mac80211: apply advertised TTLM from association response wifi: mac80211: parse all TTLM entries wifi: mac80211: don't increment crypto_tx_tailroom_needed_cnt twice wifi: mac80211: don't perform DA check on S1G beacon wifi: ath12k: Fix wrong P2P device link id issue wifi: ath12k: fix dead lock while flushing management frames wifi: ath12k: Fix scan state stuck in ABORTING after cancel_remain_on_channel wifi: ath12k: cancel scan only on active scan vdev wifi: mwifiex: Fix a loop in mwifiex_update_ampdu_rxwinsize() wifi: mac80211: correctly check if CSA is active wifi: cfg80211: Fix bitrate calculation overflow for HE rates wifi: rsi: Fix memory corruption due to not set vif driver data size wifi: ath12k: don't force radio frequency check in freq_to_idx() wifi: ath12k: fix dma_free_coherent() pointer wifi: ath10k: fix dma_free_coherent() pointer ==================== Link: https://patch.msgid.link/20260122110248.15450-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22Merge branch 'vsock-virtio-fix-tx-credit-handling'Paolo Abeni2-9/+133
Stefano Garzarella says: ==================== vsock/virtio: fix TX credit handling The original series was posted by Melbin K Mathew <mlbnkm1@gmail.com> till v4. Since it's a real issue and the original author seems busy, I'm sending the new version fixing my comments but keeping the authorship (and restoring mine on patch 2 as reported on v4). v5: https://lore.kernel.org/netdev/20260116201517.273302-1-sgarzare@redhat.com/ v4: https://lore.kernel.org/netdev/20251217181206.3681159-1-mlbnkm1@gmail.com/ From Melbin K Mathew <mlbnkm1@gmail.com>: This series fixes TX credit handling in virtio-vsock: Patch 1: Fix potential underflow in get_credit() using s64 arithmetic Patch 2: Fix vsock_test seqpacket bounds test Patch 3: Cap TX credit to local buffer size (security hardening) Patch 4: Add stream TX credit bounds regression test The core issue is that a malicious guest can advertise a huge buffer size via SO_VM_SOCKETS_BUFFER_SIZE, causing the host to allocate excessive sk_buff memory when sending data to that guest. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. With this series applied, the same PoC shows only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. ==================== Link: https://patch.msgid.link/20260121093628.9941-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22vsock/test: add stream TX credit bounds testMelbin K Mathew1-0/+101
Add a regression test for the TX credit bounds fix. The test verifies that a sender with a small local buffer size cannot queue excessive data even when the peer advertises a large receive buffer. The client: - Sets a small buffer size (64 KiB) - Connects to server (which advertises 2 MiB buffer) - Sends in non-blocking mode until EAGAIN - Verifies total queued data is bounded This guards against the original vulnerability where a remote peer could cause unbounded kernel memory allocation by advertising a large buffer and reading slowly. Suggested-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com> [Stefano: use sock_buf_size to check the bytes sent + small fixes] Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20260121093628.9941-5-sgarzare@redhat.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22vsock/virtio: cap TX credit to local buffer sizeMelbin K Mathew1-2/+12
The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base. Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport. This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Suggested-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com> [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message] Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Luigi Leonardi <leonardi@redhat.com> Link: https://patch.msgid.link/20260121093628.9941-4-sgarzare@redhat.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22vsock/test: fix seqpacket message bounds testStefano Garzarella1-0/+11
The test requires the sender (client) to send all messages before waking up the receiver (server). Since virtio-vsock had a bug and did not respect the size of the TX buffer, this test worked, but now that we are going to fix the bug, the test hangs because the sender would fill the TX buffer before waking up the receiver. Set the buffer size in the sender (client) as well, as we already do for the receiver (server). Fixes: 5c338112e48a ("test/vsock: rework message bounds test") Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20260121093628.9941-3-sgarzare@redhat.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22vsock/virtio: fix potential underflow in virtio_transport_get_credit()Melbin K Mathew1-7/+9
The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle. Reuse virtio_transport_has_space() which already handles this case and add a comment to make it clear why we are doing that. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Suggested-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com> [Stefano: use virtio_transport_has_space() instead of duplicating the code] [Stefano: tweak the commit message] Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Luigi Leonardi <leonardi@redhat.com> Link: https://patch.msgid.link/20260121093628.9941-2-sgarzare@redhat.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: atp: drop ancient parallel-port Ethernet driverEthan Nelson-Moore4-1164/+1
This driver is old and almost certainly entirely unused. The two other parallel port Ethernet drivers (de600/de620) were removed by Paul Gortmaker in commit 168e06ae26dd ("drivers/net: delete old parallel port de600/de620 drivers"), but this driver remained. Drop it - Paul's reasoning applies here as well. To quote him: "The parallel port is largely replaced by USB [...] Let us not pretend that anyone cares about these drivers anymore, or worse - pretend that anyone is using them on a modern kernel." Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Acked-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260121084532.60606-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: fec: account for VLAN header in frame length calculationsClemens Gruber1-6/+7
The MAX_FL (maximum frame length) and related calculations used ETH_HLEN, which does not account for the 4-byte VLAN tag in tagged frames. This caused the hardware to reject valid VLAN frames as oversized, resulting in RX errors and dropped packets. Use VLAN_ETH_HLEN instead of ETH_HLEN in the MAX_FL register setup, cut-through mode threshold, buffer allocation, and max_mtu calculation. Cc: stable@kernel.org # v6.18+ Fixes: 62b5bb7be7bc ("net: fec: update MAX_FL based on the current MTU") Fixes: d466c16026e9 ("net: fec: enable the Jumbo frame support for i.MX8QM") Fixes: 59e9bf037d75 ("net: fec: add change_mtu to support dynamic buffer allocation") Fixes: ec2a1681ed4f ("net: fec: use a member variable for maximum buffer size") Signed-off-by: Clemens Gruber <mail@clemensgruber.at> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260121083751.66997-1-mail@clemensgruber.at Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22xen/netfront: Use u64_stats_t with u64_stats_sync properlyDavid Yang1-12/+12
On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260121082550.2389249-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-02 11:24:32 +0300