* [PATCH net-next] ppp: don't byte-swap at run time
From: Qingfang Deng @ 2026-02-07 6:47 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-ppp, netdev, linux-kernel
Currently, the code loads the protocol number from a skb and converts it
to host-endian for comparison. This requires runtime byte swapping on
little-endian architectures.
Optimize this by comparing the protocol number directly to
constant-folded big-endian values. This reduces code size, and slightly
improves performance in the fastpath. ppp_ioctl() still takes a
host-endian int, so keep the old function for it.
bloat-o-meter analysis on a x86_64 build:
add/remove: 0/0 grow/shrink: 0/6 up/down: 0/-131 (-131)
Function old new delta
ppp_receive_nonmp_frame 2002 2000 -2
ppp_input 641 639 -2
npindex_to_proto 24 12 -12
npindex_to_ethertype 24 12 -12
ppp_start_xmit 375 344 -31
__ppp_xmit_process 1881 1809 -72
Total: Before=22998, After=22867, chg -0.57%
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
---
drivers/net/ppp/ppp_generic.c | 109 ++++++++++++++++++++--------------
1 file changed, 65 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index f8814d7be6f1..eca9cd6f3a87 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -239,7 +239,7 @@ struct ppp_net {
};
/* Get the PPP protocol number from a skb */
-#define PPP_PROTO(skb) get_unaligned_be16((skb)->data)
+#define PPP_PROTO(skb) get_unaligned((__be16 *)(skb)->data)
/* We limit the length of ppp->file.rq to this (arbitrary) value */
#define PPP_MAX_RQLEN 32
@@ -312,7 +312,26 @@ static inline struct ppp_net *ppp_pernet(struct net *net)
}
/* Translates a PPP protocol number to a NP index (NP == network protocol) */
-static inline int proto_to_npindex(int proto)
+static __always_inline int proto_to_npindex(__be16 proto)
+{
+ switch (proto) {
+ case htons(PPP_IP):
+ return NP_IP;
+ case htons(PPP_IPV6):
+ return NP_IPV6;
+ case htons(PPP_IPX):
+ return NP_IPX;
+ case htons(PPP_AT):
+ return NP_AT;
+ case htons(PPP_MPLS_UC):
+ return NP_MPLS_UC;
+ case htons(PPP_MPLS_MC):
+ return NP_MPLS_MC;
+ }
+ return -EINVAL;
+}
+
+static __always_inline int proto_to_npindex_user(int proto)
{
switch (proto) {
case PPP_IP:
@@ -332,44 +351,44 @@ static inline int proto_to_npindex(int proto)
}
/* Translates an NP index into a PPP protocol number */
-static const int npindex_to_proto[NUM_NP] = {
- PPP_IP,
- PPP_IPV6,
- PPP_IPX,
- PPP_AT,
- PPP_MPLS_UC,
- PPP_MPLS_MC,
+static const __be16 npindex_to_proto[NUM_NP] = {
+ htons(PPP_IP),
+ htons(PPP_IPV6),
+ htons(PPP_IPX),
+ htons(PPP_AT),
+ htons(PPP_MPLS_UC),
+ htons(PPP_MPLS_MC),
};
/* Translates an ethertype into an NP index */
-static inline int ethertype_to_npindex(int ethertype)
+static inline int ethertype_to_npindex(__be16 ethertype)
{
switch (ethertype) {
- case ETH_P_IP:
+ case htons(ETH_P_IP):
return NP_IP;
- case ETH_P_IPV6:
+ case htons(ETH_P_IPV6):
return NP_IPV6;
- case ETH_P_IPX:
+ case htons(ETH_P_IPX):
return NP_IPX;
- case ETH_P_PPPTALK:
- case ETH_P_ATALK:
+ case htons(ETH_P_PPPTALK):
+ case htons(ETH_P_ATALK):
return NP_AT;
- case ETH_P_MPLS_UC:
+ case htons(ETH_P_MPLS_UC):
return NP_MPLS_UC;
- case ETH_P_MPLS_MC:
+ case htons(ETH_P_MPLS_MC):
return NP_MPLS_MC;
}
return -1;
}
/* Translates an NP index into an ethertype */
-static const int npindex_to_ethertype[NUM_NP] = {
- ETH_P_IP,
- ETH_P_IPV6,
- ETH_P_IPX,
- ETH_P_PPPTALK,
- ETH_P_MPLS_UC,
- ETH_P_MPLS_MC,
+static const __be16 npindex_to_ethertype[NUM_NP] = {
+ htons(ETH_P_IP),
+ htons(ETH_P_IPV6),
+ htons(ETH_P_IPX),
+ htons(ETH_P_PPPTALK),
+ htons(ETH_P_MPLS_UC),
+ htons(ETH_P_MPLS_MC),
};
/*
@@ -504,7 +523,7 @@ static bool ppp_check_packet(struct sk_buff *skb, size_t count)
/* LCP packets must include LCP header which 4 bytes long:
* 1-byte code, 1-byte identifier, and 2-byte length.
*/
- return get_unaligned_be16(skb->data) != PPP_LCP ||
+ return PPP_PROTO(skb) != htons(PPP_LCP) ||
count >= PPP_PROTO_LEN + PPP_LCP_HDRLEN;
}
@@ -914,7 +933,7 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case PPPIOCSNPMODE:
if (copy_from_user(&npi, argp, sizeof(npi)))
break;
- err = proto_to_npindex(npi.protocol);
+ err = proto_to_npindex_user(npi.protocol);
if (err < 0)
break;
i = err;
@@ -1451,10 +1470,10 @@ static netdev_tx_t
ppp_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ppp *ppp = netdev_priv(dev);
- int npi, proto;
- unsigned char *pp;
+ __be16 *pp, proto;
+ int npi;
- npi = ethertype_to_npindex(ntohs(skb->protocol));
+ npi = ethertype_to_npindex(skb->protocol);
if (npi < 0)
goto outf;
@@ -1478,7 +1497,7 @@ ppp_start_xmit(struct sk_buff *skb, struct net_device *dev)
pp = skb_push(skb, 2);
proto = npindex_to_proto[npi];
- put_unaligned_be16(proto, pp);
+ put_unaligned(proto, pp);
skb_scrub_packet(skb, !net_eq(ppp->ppp_net, dev_net(dev)));
ppp_xmit_process(ppp, skb);
@@ -1764,14 +1783,14 @@ pad_compress_skb(struct ppp *ppp, struct sk_buff *skb)
static void
ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
{
- int proto = PPP_PROTO(skb);
+ __be16 proto = PPP_PROTO(skb);
struct sk_buff *new_skb;
int len;
unsigned char *cp;
skb->dev = ppp->dev;
- if (proto < 0x8000) {
+ if (!(proto & htons(0x8000))) {
#ifdef CONFIG_PPP_FILTER
/* check if the packet passes the pass and active filters.
* See comment for PPP_FILTER_OUTBOUND_TAG above.
@@ -2324,7 +2343,7 @@ ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
{
struct channel *pch = chan->ppp;
struct ppp *ppp;
- int proto;
+ __be16 proto;
if (!pch) {
kfree_skb(skb);
@@ -2347,7 +2366,8 @@ ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
}
proto = PPP_PROTO(skb);
- if (!ppp || proto >= 0xc000 || proto == PPP_CCPFRAG) {
+ if (!ppp || (proto & htons(0xc000)) == htons(0xc000) ||
+ proto == htons(PPP_CCPFRAG)) {
/* put it on the channel queue */
skb_queue_tail(&pch->file.rq, skb);
/* drop old frames if queue too long */
@@ -2399,7 +2419,7 @@ ppp_receive_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)
skb_checksum_complete_unset(skb);
#ifdef CONFIG_PPP_MULTILINK
/* XXX do channel-level decompression here */
- if (PPP_PROTO(skb) == PPP_MP)
+ if (PPP_PROTO(skb) == htons(PPP_MP))
ppp_receive_mp_frame(ppp, skb, pch);
else
#endif /* CONFIG_PPP_MULTILINK */
@@ -2422,7 +2442,8 @@ static void
ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
{
struct sk_buff *ns;
- int proto, len, npi;
+ int len, npi;
+ __be16 proto;
/*
* Decompress the frame, if compressed.
@@ -2441,7 +2462,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
*/
proto = PPP_PROTO(skb);
switch (proto) {
- case PPP_VJC_COMP:
+ case htons(PPP_VJC_COMP):
/* decompress VJ compressed packets */
if (!ppp->vj || (ppp->flags & SC_REJ_COMP_TCP))
goto err;
@@ -2473,10 +2494,10 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
skb_put(skb, len - skb->len);
else if (len < skb->len)
skb_trim(skb, len);
- proto = PPP_IP;
+ proto = htons(PPP_IP);
break;
- case PPP_VJC_UNCOMP:
+ case htons(PPP_VJC_UNCOMP):
if (!ppp->vj || (ppp->flags & SC_REJ_COMP_TCP))
goto err;
@@ -2490,10 +2511,10 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
netdev_err(ppp->dev, "PPP: VJ uncompressed error\n");
goto err;
}
- proto = PPP_IP;
+ proto = htons(PPP_IP);
break;
- case PPP_CCP:
+ case htons(PPP_CCP):
ppp_ccp_peek(ppp, skb, 1);
break;
}
@@ -2546,7 +2567,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
/* chop off protocol */
skb_pull_rcsum(skb, 2);
skb->dev = ppp->dev;
- skb->protocol = htons(npindex_to_ethertype[npi]);
+ skb->protocol = npindex_to_ethertype[npi];
skb_reset_mac_header(skb);
skb_scrub_packet(skb, !net_eq(ppp->ppp_net,
dev_net(ppp->dev)));
@@ -2563,7 +2584,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
static struct sk_buff *
ppp_decompress_frame(struct ppp *ppp, struct sk_buff *skb)
{
- int proto = PPP_PROTO(skb);
+ __be16 proto = PPP_PROTO(skb);
struct sk_buff *ns;
int len;
@@ -2573,7 +2594,7 @@ ppp_decompress_frame(struct ppp *ppp, struct sk_buff *skb)
if (!pskb_may_pull(skb, skb->len))
goto err;
- if (proto == PPP_COMP) {
+ if (proto == htons(PPP_COMP)) {
int obuff_size;
switch(ppp->rcomp->compress_proto) {
--
2.43.0
^ permalink raw reply related
* [PATCH net v3] net: ti: icssg-prueth: Add optional dependency on HSR
From: Kevin Hao @ 2026-02-07 6:21 UTC (permalink / raw)
To: netdev
Cc: Kevin Hao, stable, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Roger Quadros, Mohan Reddy Putluru,
MD Danish Anwar, Arnd Bergmann, Sascha Hauer
Commit 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame
forward offload") introduced support for offloading HSR frame forwarding,
which relies on functions such as is_hsr_master() provided by the HSR
module. Although HSR provides stubs for configurations with HSR
disabled, this driver still requires an optional dependency on HSR.
Otherwise, build failures will occur when icssg-prueth is built-in
while HSR is configured as a module.
ld.lld: error: undefined symbol: is_hsr_master
>>> referenced by icssg_prueth.c:710 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:710)
>>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a
>>> referenced by icssg_prueth.c:681 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:681)
>>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a
>>> referenced by icssg_prueth.c:1812 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:1812)
>>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(prueth_netdevice_event) in archive vmlinux.a
ld.lld: error: undefined symbol: hsr_get_port_ndev
>>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712)
>>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_del_mcast) in archive vmlinux.a
>>> referenced by icssg_prueth.c:712 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:712)
>>> drivers/net/etherneteth_hsr_del_mcast) in archive vmlinux.a
>>> referenced by icssg_prueth.c:683 (drivers/net/ethernet/ti/icssg/icssg_prueth.c:683)
>>> drivers/net/ethernet/ti/icssg/icssg_prueth.o:(icssg_prueth_hsr_add_mcast) in archive vmlinux.a
>>> referenced 1 more times
Fixes: 95540ad6747c ("net: ti: icssg-prueth: Add support for HSR frame forward offload")
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Cc: stable@vger.kernel.org
---
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Mohan Reddy Putluru <pmohan@couthit.com>
Cc: MD Danish Anwar <danishanwar@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
Changes in v3:
- The implementation of the 'HSR if HSR' syntax has not yet been merged, use
'depends on HSR || !HSR' instead.
- Link to v2: https://lore.kernel.org/r/20260206-icssg-dep-v2-1-9dae19b19e6d@gmail.com
Changes in v2:
- Switch to the optional dependency as recommended by Jakub.
- Link to v1: https://lore.kernel.org/r/20260203-icssg-dep-v1-1-bacaf5234fb3@gmail.com
---
drivers/net/ethernet/ti/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index fe5b2926d8ab060d83f5a58d91e749a45c6cea18..c60b04921c62cab52983efa5aaafecdb9b7d4da4 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -192,6 +192,7 @@ config TI_ICSSG_PRUETH
depends on NET_SWITCHDEV
depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
depends on PTP_1588_CLOCK_OPTIONAL
+ depends on HSR || !HSR
help
Support dual Gigabit Ethernet ports over the ICSSG PRU Subsystem.
This subsystem is available starting with the AM65 platform.
---
base-commit: 6d2f142b1e4b203387a92519d9d2e34752a79dbb
change-id: 20260203-icssg-dep-b9f7fc2be11e
Best regards,
--
Kevin Hao <haokexin@gmail.com>
^ permalink raw reply related
* Re: [PATCH net-next v5 2/2] virtio_net: add page_pool support for buffer allocation
From: Vishwanath Seshagiri @ 2026-02-07 5:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Michael S . Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Andrew Lunn, David S . Miller, Eric Dumazet, Paolo Abeni,
David Wei, Matteo Croce, Ilias Apalodimas, netdev, virtualization,
linux-kernel, kernel-team
In-Reply-To: <20260206204140.56d85273@kernel.org>
On 2/6/26 8:41 PM, Jakub Kicinski wrote:
> On Thu, 5 Feb 2026 16:27:15 -0800 Vishwanath Seshagiri wrote:
>> + page = page_pool_alloc_frag(rq->page_pool, &offset, len + room, gfp);
>> + if (unlikely(!page))
>> return -ENOMEM;
>>
>> + buf = page_address(page) + offset;
>
> Please take a look at page_pool_alloc_va()
>
> I mean all the way down until you reach page_pool_alloc_netmem()
> and realize the helper you're adding in patch 1 is a solved problem
I apologize for adding patch 1. I will use page_pool_alloc_va and send
v6 with only patch 2.
^ permalink raw reply
* Re: [PATCH v2] nfc: nxp-nci: remove interrupt trigger type
From: patchwork-bot+netdevbpf @ 2026-02-07 5:20 UTC (permalink / raw)
To: Carl Lee; +Cc: krzk, netdev, linux-kernel, peter.shen, colin.huang2
In-Reply-To: <20260205-fc-nxp-nci-remove-interrupt-trigger-type-v2-1-79d2ed4a7e42@amd.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 05 Feb 2026 19:11:39 +0800 you wrote:
> From: Carl Lee <carl.lee@amd.com>
>
> For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and
> active high, not edge-triggered.
>
> Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail
> to trigger correctly.
>
> [...]
Here is the summary with links:
- [v2] nfc: nxp-nci: remove interrupt trigger type
https://git.kernel.org/netdev/net-next/c/57be33f85e36
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 v5 00/12] BIG TCP without HBH in IPv6
From: patchwork-bot+netdevbpf @ 2026-02-07 5:20 UTC (permalink / raw)
To: Alice Mikityanska
Cc: daniel, davem, edumazet, kuba, pabeni, lucien.xin,
willemdebruijn.kernel, dsahern, razor, shuah, stfomichev, netdev,
alice
In-Reply-To: <20260205133925.526371-1-alice.kernel@fastmail.im>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 15:39:13 +0200 you wrote:
> From: Alice Mikityanska <alice@isovalent.com>
>
> Resubmitting after the grace period.
>
> This series is part 1 of "BIG TCP for UDP tunnels". Due to the number of
> patches, I'm splitting it into two logical parts:
>
> [...]
Here is the summary with links:
- [net-next,v5,01/12] net/ipv6: Introduce payload_len helpers
https://git.kernel.org/netdev/net-next/c/b2936b4fd562
- [net-next,v5,02/12] net/ipv6: Drop HBH for BIG TCP on TX side
https://git.kernel.org/netdev/net-next/c/741d069aa488
- [net-next,v5,03/12] net/ipv6: Drop HBH for BIG TCP on RX side
https://git.kernel.org/netdev/net-next/c/81be30c1f5f2
- [net-next,v5,04/12] net/ipv6: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/1676ebba391d
- [net-next,v5,05/12] net/mlx5e: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/bda5896e469c
- [net-next,v5,06/12] net/mlx4: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/94379a588037
- [net-next,v5,07/12] ice: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/8b76102c5e00
- [net-next,v5,08/12] bnxt_en: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/3f1bff1d7fd2
- [net-next,v5,09/12] gve: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/275da93ce2b8
- [net-next,v5,10/12] net: mana: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/c0165fcb8d9f
- [net-next,v5,11/12] bng_en: Remove jumbo_remove step from TX path
https://git.kernel.org/netdev/net-next/c/28df1c69271c
- [net-next,v5,12/12] net/ipv6: Remove HBH helpers
https://git.kernel.org/netdev/net-next/c/35f66ce90037
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net-next,v2] bnge/bng_re: Add a new HSI
From: Jakub Kicinski @ 2026-02-07 5:14 UTC (permalink / raw)
To: vikas.gupta
Cc: Jakub Kicinski, andrew+netdev, bhargava.marreddy, siva.kallam,
vsrama-krishna.nemani, horms, jgg, pabeni, linux-kernel,
linux-rdma, leonro, edumazet, netdev, davem, michael.chan,
ajit.khaparde, rajashekar.hudumula, pavan.chebbi
In-Reply-To: <20260206052614.1676580-1-vikas.gupta@broadcom.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
bnge/bng_re: Add a new HSI
This commit adds a new HSI (Hardware Software Interface) for the BNGE and
ThorUltra RoCE drivers. The HSI is automatically generated and shared between
firmware and driver, replacing the existing BNXT HSI references.
> diff --git a/drivers/infiniband/hw/bng_re/bng_roce_hsi.h b/drivers/infiniband/hw/bng_re/bng_roce_hsi.h
> new file mode 100644
> index 000000000000..1c4666eb0c87
> --- /dev/null
> +++ b/drivers/infiniband/hw/bng_re/bng_roce_hsi.h
> @@ -0,0 +1,6450 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (c) 2026 Broadcom */
> +
> +/* DO NOT MODIFY!!! This file is automatically generated. */
> +
> +#ifndef __BNG_RE_HSI_H__
> +#define __BNG_RE_HSI_H__
[ ... ]
> +};
> +
> +#endif /* _ROCE_HSI_H_ */
^^^^^^^^^^^^^^^^
This isn't a bug, but the include guard comment doesn't match the actual macro
name. The file opens with '__BNG_RE_HSI_H__' but closes with a comment
referencing '_ROCE_HSI_H_'. The closing comment should read
'/* __BNG_RE_HSI_H__ */' to match.
While this doesn't affect compilation, it creates confusion for developers.
Compare with the related include/linux/bnge/hsi.h which correctly uses
matching guards throughout.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v2 4/4] selftests: drv-net: rss_ctx: test RSS contexts persist after ifdown/up
From: Jakub Kicinski @ 2026-02-07 5:12 UTC (permalink / raw)
To: Michael Chan
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260206052930.1882740-5-michael.chan@broadcom.com>
On Thu, 5 Feb 2026 21:29:30 -0800 Michael Chan wrote:
> diff --git a/tools/testing/selftests/drivers/net/hw/rss_ctx.py b/tools/testing/selftests/drivers/net/hw/rss_ctx.py
Please use:
ruff check $file
pylint --disable=R $file
and fix the new warnings.
This file predates my discovery of these tools so there are some
warnings already, but let's not add more.
> +@ksft_disruptive
> +def test_rss_context_persist_ifupdown(cfg, pre_down=False):
> + """
> + Test that RSS contexts and their associated ntuple filters persist across
> + an interface down/up cycle.
> +
> + """
> +
> + require_ntuple(cfg)
> +
> + qcnt = len(_get_rx_cnts(cfg))
> + if qcnt < 6:
> + try:
> + ethtool(f"-L {cfg.ifname} combined 6")
> + defer(ethtool, f"-L {cfg.ifname} combined {qcnt}")
> + except:
> + raise KsftSkipEx("Not enough queues for the test")
> +
> + ethtool(f"-X {cfg.ifname} equal 2")
> + defer(ethtool, f"-X {cfg.ifname} default")
> +
> + if pre_down:
> + ip(f"link set dev {cfg.ifname} down")
> +
> + try:
> + ctx1_id = ethtool_create(cfg, "-X", "context new start 2 equal 2")
> + defer(ethtool, f"-X {cfg.ifname} context {ctx1_id} delete")
> + except CmdExitFailure:
> + if pre_down:
> + ip(f"link set dev {cfg.ifname} up")
You should use defer for the ifup. You can save it and run it with
.exec():
ifup = defer(ip, f"link set dev {cfg.ifname} up")
if pre_down:
ip(f"link set dev {cfg.ifname} down")
try:
ctx1_id = ethtool_create(cfg, "-X", "context new start 2 equal 2")
defer(ethtool, f"-X {cfg.ifname} context {ctx1_id} delete")
except CmdExitFailure:
raise KsftSkipEx("Create context not supported with interface down")
....
if not pre_down:
ip(f"link set dev {cfg.ifname} down")
ifup.exec()
this ifup.exec() also removes ifup from the "defer queue".
> + raise KsftSkipEx("Create context not supported with interface down")
> + raise
> +
> + ctx2_id = ethtool_create(cfg, "-X", "context new start 4 equal 2")
> + defer(ethtool, f"-X {cfg.ifname} context {ctx2_id} delete")
> +
> + port_ctx2 = rand_port()
> + flow = f"flow-type tcp{cfg.addr_ipver} dst-ip {cfg.addr} dst-port {port_ctx2} context {ctx2_id}"
> + ntuple_id = ethtool_create(cfg, "-N", flow)
> + defer(ethtool, f"-N {cfg.ifname} delete {ntuple_id}")
> +
> + if not pre_down:
> + ip(f"link set dev {cfg.ifname} down")
> +
> + ip(f"link set dev {cfg.ifname} up")
You can add here:
wait_file(f"/sys/class/net/{cfg.ifname}/carrier",
lambda x: x.strip() == "1")
to wait for carrier before running the ping loop.
^ permalink raw reply
* Re: [PATCH v2 net-next] virtio_net: Improve RSS key size validation and use NETDEV_RSS_KEY_LEN
From: kernel test robot @ 2026-02-07 5:03 UTC (permalink / raw)
To: Srujana Challa, netdev, virtualization
Cc: llvm, oe-kbuild-all, pabeni, mst, jasowang, xuanzhuo, eperezma,
davem, edumazet, kuba, ndabilpuram, kshankar, schalla
In-Reply-To: <20260206120154.2548079-1-schalla@marvell.com>
Hi Srujana,
kernel test robot noticed the following build warnings:
[auto build test WARNING on net-next/main]
url: https://github.com/intel-lab-lkp/linux/commits/Srujana-Challa/virtio_net-Improve-RSS-key-size-validation-and-use-NETDEV_RSS_KEY_LEN/20260206-200801
base: net-next/main
patch link: https://lore.kernel.org/r/20260206120154.2548079-1-schalla%40marvell.com
patch subject: [PATCH v2 net-next] virtio_net: Improve RSS key size validation and use NETDEV_RSS_KEY_LEN
config: riscv-defconfig (https://download.01.org/0day-ci/archive/20260207/202602071211.N0SvyotM-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260207/202602071211.N0SvyotM-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602071211.N0SvyotM-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/net/virtio_net.c:6841:31: warning: result of comparison of constant 256 with expression of type 'u8' (aka 'unsigned char') is always false [-Wtautological-constant-out-of-range-compare]
6841 | } else if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) {
| ~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +6841 drivers/net/virtio_net.c
6699
6700 static int virtnet_probe(struct virtio_device *vdev)
6701 {
6702 int i, err = -ENOMEM;
6703 struct net_device *dev;
6704 struct virtnet_info *vi;
6705 u16 max_queue_pairs;
6706 int mtu = 0;
6707
6708 /* Find if host supports multiqueue/rss virtio_net device */
6709 max_queue_pairs = 1;
6710 if (virtio_has_feature(vdev, VIRTIO_NET_F_MQ) || virtio_has_feature(vdev, VIRTIO_NET_F_RSS))
6711 max_queue_pairs =
6712 virtio_cread16(vdev, offsetof(struct virtio_net_config, max_virtqueue_pairs));
6713
6714 /* We need at least 2 queue's */
6715 if (max_queue_pairs < VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN ||
6716 max_queue_pairs > VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX ||
6717 !virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
6718 max_queue_pairs = 1;
6719
6720 /* Allocate ourselves a network device with room for our info */
6721 dev = alloc_etherdev_mq(sizeof(struct virtnet_info), max_queue_pairs);
6722 if (!dev)
6723 return -ENOMEM;
6724
6725 /* Set up network device as normal. */
6726 dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE |
6727 IFF_TX_SKB_NO_LINEAR;
6728 dev->netdev_ops = &virtnet_netdev;
6729 dev->stat_ops = &virtnet_stat_ops;
6730 dev->features = NETIF_F_HIGHDMA;
6731
6732 dev->ethtool_ops = &virtnet_ethtool_ops;
6733 SET_NETDEV_DEV(dev, &vdev->dev);
6734
6735 /* Do we support "hardware" checksums? */
6736 if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
6737 /* This opens up the world of extra features. */
6738 dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
6739 if (csum)
6740 dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
6741
6742 if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
6743 dev->hw_features |= NETIF_F_TSO
6744 | NETIF_F_TSO_ECN | NETIF_F_TSO6;
6745 }
6746 /* Individual feature bits: what can host handle? */
6747 if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_TSO4))
6748 dev->hw_features |= NETIF_F_TSO;
6749 if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_TSO6))
6750 dev->hw_features |= NETIF_F_TSO6;
6751 if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_ECN))
6752 dev->hw_features |= NETIF_F_TSO_ECN;
6753 if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_USO))
6754 dev->hw_features |= NETIF_F_GSO_UDP_L4;
6755
6756 if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO)) {
6757 dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
6758 dev->hw_enc_features = dev->hw_features;
6759 }
6760 if (dev->hw_features & NETIF_F_GSO_UDP_TUNNEL &&
6761 virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO_CSUM)) {
6762 dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
6763 dev->hw_enc_features |= NETIF_F_GSO_UDP_TUNNEL_CSUM;
6764 }
6765
6766 dev->features |= NETIF_F_GSO_ROBUST;
6767
6768 if (gso)
6769 dev->features |= dev->hw_features;
6770 /* (!csum && gso) case will be fixed by register_netdev() */
6771 }
6772
6773 /* 1. With VIRTIO_NET_F_GUEST_CSUM negotiation, the driver doesn't
6774 * need to calculate checksums for partially checksummed packets,
6775 * as they're considered valid by the upper layer.
6776 * 2. Without VIRTIO_NET_F_GUEST_CSUM negotiation, the driver only
6777 * receives fully checksummed packets. The device may assist in
6778 * validating these packets' checksums, so the driver won't have to.
6779 */
6780 dev->features |= NETIF_F_RXCSUM;
6781
6782 if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) ||
6783 virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6))
6784 dev->features |= NETIF_F_GRO_HW;
6785 if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS))
6786 dev->hw_features |= NETIF_F_GRO_HW;
6787
6788 dev->vlan_features = dev->features;
6789 dev->xdp_features = NETDEV_XDP_ACT_BASIC | NETDEV_XDP_ACT_REDIRECT |
6790 NETDEV_XDP_ACT_XSK_ZEROCOPY;
6791
6792 /* MTU range: 68 - 65535 */
6793 dev->min_mtu = MIN_MTU;
6794 dev->max_mtu = MAX_MTU;
6795
6796 /* Configuration may specify what MAC to use. Otherwise random. */
6797 if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC)) {
6798 u8 addr[ETH_ALEN];
6799
6800 virtio_cread_bytes(vdev,
6801 offsetof(struct virtio_net_config, mac),
6802 addr, ETH_ALEN);
6803 eth_hw_addr_set(dev, addr);
6804 } else {
6805 eth_hw_addr_random(dev);
6806 dev_info(&vdev->dev, "Assigned random MAC address %pM\n",
6807 dev->dev_addr);
6808 }
6809
6810 /* Set up our device-specific information */
6811 vi = netdev_priv(dev);
6812 vi->dev = dev;
6813 vi->vdev = vdev;
6814 vdev->priv = vi;
6815
6816 INIT_WORK(&vi->config_work, virtnet_config_changed_work);
6817 INIT_WORK(&vi->rx_mode_work, virtnet_rx_mode_work);
6818
6819 if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF)) {
6820 vi->mergeable_rx_bufs = true;
6821 dev->xdp_features |= NETDEV_XDP_ACT_RX_SG;
6822 }
6823
6824 if (virtio_has_feature(vdev, VIRTIO_NET_F_HASH_REPORT))
6825 vi->has_rss_hash_report = true;
6826
6827 if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS))
6828 vi->has_rss = true;
6829
6830 if (vi->has_rss || vi->has_rss_hash_report) {
6831 vi->rss_key_size =
6832 virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));
6833
6834 /* Spec requires at least 40 bytes */
6835 if (vi->rss_key_size < VIRTIO_NET_RSS_MIN_KEY_SIZE) {
6836 dev_warn(&vdev->dev,
6837 "rss_max_key_size=%u is less than spec minimum %u, disabling RSS\n",
6838 vi->rss_key_size, VIRTIO_NET_RSS_MIN_KEY_SIZE);
6839 vi->has_rss = false;
6840 vi->has_rss_hash_report = false;
> 6841 } else if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) {
6842 dev_warn(&vdev->dev,
6843 "rss_max_key_size=%u exceeds driver limit %u, disabling RSS\n",
6844 vi->rss_key_size, VIRTIO_NET_RSS_MAX_KEY_SIZE);
6845 vi->has_rss = false;
6846 vi->has_rss_hash_report = false;
6847 } else {
6848 vi->rss_indir_table_size =
6849 virtio_cread16(vdev, offsetof(struct virtio_net_config,
6850 rss_max_indirection_table_length));
6851 vi->rss_hash_types_supported =
6852 virtio_cread32(vdev, offsetof(struct virtio_net_config,
6853 supported_hash_types));
6854 vi->rss_hash_types_supported &=
6855 ~(VIRTIO_NET_RSS_HASH_TYPE_IP_EX |
6856 VIRTIO_NET_RSS_HASH_TYPE_TCP_EX |
6857 VIRTIO_NET_RSS_HASH_TYPE_UDP_EX);
6858
6859 dev->hw_features |= NETIF_F_RXHASH;
6860 dev->xdp_metadata_ops = &virtnet_xdp_metadata_ops;
6861 }
6862 }
6863
6864 vi->rss_hdr = devm_kzalloc(&vdev->dev, virtnet_rss_hdr_size(vi), GFP_KERNEL);
6865 if (!vi->rss_hdr) {
6866 err = -ENOMEM;
6867 goto free;
6868 }
6869
6870 if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO) ||
6871 virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO))
6872 vi->hdr_len = sizeof(struct virtio_net_hdr_v1_hash_tunnel);
6873 else if (vi->has_rss_hash_report)
6874 vi->hdr_len = sizeof(struct virtio_net_hdr_v1_hash);
6875 else if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF) ||
6876 virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
6877 vi->hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
6878 else
6879 vi->hdr_len = sizeof(struct virtio_net_hdr);
6880
6881 if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO_CSUM))
6882 vi->rx_tnl_csum = true;
6883 if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO))
6884 vi->rx_tnl = true;
6885 if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO))
6886 vi->tx_tnl = true;
6887
6888 if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT) ||
6889 virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
6890 vi->any_header_sg = true;
6891
6892 if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
6893 vi->has_cvq = true;
6894
6895 mutex_init(&vi->cvq_lock);
6896
6897 if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
6898 mtu = virtio_cread16(vdev,
6899 offsetof(struct virtio_net_config,
6900 mtu));
6901 if (mtu < dev->min_mtu) {
6902 /* Should never trigger: MTU was previously validated
6903 * in virtnet_validate.
6904 */
6905 dev_err(&vdev->dev,
6906 "device MTU appears to have changed it is now %d < %d",
6907 mtu, dev->min_mtu);
6908 err = -EINVAL;
6909 goto free;
6910 }
6911
6912 dev->mtu = mtu;
6913 dev->max_mtu = mtu;
6914 }
6915
6916 virtnet_set_big_packets(vi, mtu);
6917
6918 if (vi->any_header_sg)
6919 dev->needed_headroom = vi->hdr_len;
6920
6921 /* Enable multiqueue by default */
6922 if (num_online_cpus() >= max_queue_pairs)
6923 vi->curr_queue_pairs = max_queue_pairs;
6924 else
6925 vi->curr_queue_pairs = num_online_cpus();
6926 vi->max_queue_pairs = max_queue_pairs;
6927
6928 /* Allocate/initialize the rx/tx queues, and invoke find_vqs */
6929 err = init_vqs(vi);
6930 if (err)
6931 goto free;
6932
6933 if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_NOTF_COAL)) {
6934 vi->intr_coal_rx.max_usecs = 0;
6935 vi->intr_coal_tx.max_usecs = 0;
6936 vi->intr_coal_rx.max_packets = 0;
6937
6938 /* Keep the default values of the coalescing parameters
6939 * aligned with the default napi_tx state.
6940 */
6941 if (vi->sq[0].napi.weight)
6942 vi->intr_coal_tx.max_packets = 1;
6943 else
6944 vi->intr_coal_tx.max_packets = 0;
6945 }
6946
6947 if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_VQ_NOTF_COAL)) {
6948 /* The reason is the same as VIRTIO_NET_F_NOTF_COAL. */
6949 for (i = 0; i < vi->max_queue_pairs; i++)
6950 if (vi->sq[i].napi.weight)
6951 vi->sq[i].intr_coal.max_packets = 1;
6952
6953 err = virtnet_init_irq_moder(vi);
6954 if (err)
6955 goto free;
6956 }
6957
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH V2 net] net: hns3: fix double free issue for tx spare buffer
From: patchwork-bot+netdevbpf @ 2026-02-07 5:00 UTC (permalink / raw)
To: Jijie Shao
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, horms, shenjian15,
liuyonglong, chenhao418, lantao5, huangdonghua3, yangshuaisong,
jonathan.cameron, salil.mehta, jacob.e.keller, netdev,
linux-kernel
In-Reply-To: <20260205121719.3285730-1-shaojijie@huawei.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 20:17:19 +0800 you wrote:
> From: Jian Shen <shenjian15@huawei.com>
>
> In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure
> is created for rollback. However, the tx_spare pointer in the original
> ring handle is incorrectly left pointing to the old backup memory.
>
> Later, if memory allocation fails in hns3_init_all_ring() during the setup,
> the error path attempts to free all newly allocated rings. Since tx_spare
> contains a stale (non-NULL) pointer from the backup, it is mistaken for
> a newly allocated buffer and is erroneously freed, leading to a double-free
> of the backup memory.
>
> [...]
Here is the summary with links:
- [V2,net] net: hns3: fix double free issue for tx spare buffer
https://git.kernel.org/netdev/net/c/6d2f142b1e4b
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 v2 02/14] net: bridge: mcast: track active state, adding tests
From: Jakub Kicinski @ 2026-02-07 4:58 UTC (permalink / raw)
To: Linus Lüssing
Cc: bridge, netdev, linux-kernel, Nikolay Aleksandrov, Ido Schimmel,
Andrew Lunn, Simon Horman, Paolo Abeni, Eric Dumazet,
David S . Miller, Kuniyuki Iwashima, Stanislav Fomichev,
Xiao Liang
In-Reply-To: <20260206030123.5430-3-linus.luessing@c0d3.blue>
On Fri, 6 Feb 2026 03:52:08 +0100 Linus Lüssing wrote:
> Before making any significant changes to the internals of the Linux
> bridge add some tests regarding the multicast activity. This is
> also to verify that we have the semantics of the new
> *_MCAST_ACTIVE_{V4,V6} netlink attributes as expected.
shellcheck has a bunch of complains here, including these two warnings:
+In bridge_mdb_active.sh line 124:
+ if [ $ret -eq 0 -a $state -eq 0 ] || [ $ret -ne 0 -a $state -eq 1 ]; then
+ ^--^ SC2086 (info): Double quote to prevent globbing and word splitting.
+ ^-- SC2166 (warning): Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
+ ^-- SC2166 (warning): Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
> .../net/forwarding/bridge_mdb_active.sh | 682 ++++++++++++++++++
Is there a reason this test is not included in the makefile?
--
pw-bot: cr
^ permalink raw reply
* Re: [net-next,v2,05/14] net: bridge: mcast: track active state, foreign IGMP/MLD querier disappearance
From: Jakub Kicinski @ 2026-02-07 4:56 UTC (permalink / raw)
To: linus.luessing
Cc: Jakub Kicinski, razor, kuniyu, davem, edumazet, idosch, sdf,
shaw.leon, netdev, bridge, horms, pabeni, andrew+netdev,
linux-kernel
In-Reply-To: <20260206030123.5430-6-linus.luessing@c0d3.blue>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: bridge: mcast: track active state, foreign IGMP/MLD querier disappearance
This change ensures that the new multicast active state variable is unset
again after a foreign IGMP/MLD querier has disappeared (default: 255
seconds). If no new, other IGMP/MLD querier took over then we can't
reliably receive IGMP/MLD reports anymore and in turn can't ensure the
completeness of our MDB anymore either.
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index d5c623dce7eb..0fc29875db9c 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1826,6 +1826,10 @@ static void br_multicast_querier_expired(struct net_bridge_mcast *brmctx,
> br_multicast_start_querier(brmctx, query);
>
> out:
> + /* another IGMP/MLD querier disappeared, set multicast state to inactive
> + * if our own querier is disabled, too
> + */
> + br_multicast_update_active(brmctx);
> spin_unlock(&brmctx->br->multicast_lock);
> }
This isn't a bug, but I noticed a couple of unaddressed review comments
from Ido Schimmel's feedback on v1 back in May 2025 that don't appear to
have been incorporated into this v2 series.
In __br_multicast_querier_exists() in net/bridge/br_private.h around line
1164, the 'is_ipv6' bool parameter is marked const. Since this is a
pass-by-value parameter, the const qualifier doesn't provide any benefit.
Should it be removed?
Reference: https://lore.kernel.org/all/aDNPxdmDPYwasUEM@shredder/
Also in br_multicast_querier_exists() in net/bridge/br_private.h around
line 1182, the function takes a struct ethhdr *eth parameter but only uses
eth->h_proto. Would it make more sense to either make the 'eth' parameter
const, or just pass the EtherType (__be16) directly instead of the entire
struct pointer?
Reference: https://lore.kernel.org/all/aDNPxdmDPYwasUEM@shredder/
^ permalink raw reply
* Re: [PATCH net-next 0/2] dpll: zl3073x: Include current frequency in supported frequencies list
From: patchwork-bot+netdevbpf @ 2026-02-07 4:50 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Prathosh.Satish, vadim.fedorenko, arkadiusz.kubalewski,
jiri, linux-kernel
In-Reply-To: <20260205154350.3180465-1-ivecera@redhat.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 16:43:48 +0100 you wrote:
> This series ensures that the current operating frequency of a DPLL pin
> is always reported in its supported frequencies list.
>
> Problem:
> When a ZL3073x DPLL pin is registered, its supported frequencies are
> read from the firmware node's "supported-frequencies-hz" property.
> However, if the firmware node is missing, or doesn't include the
> current operating frequency, the pin reports a frequency that isn't
> in its supported list. This inconsistency can confuse userspace tools
> that expect the current frequency to be among the supported values.
>
> [...]
Here is the summary with links:
- [net-next,1/2] dpll: zl3073x: Add output pin frequency helper
https://git.kernel.org/netdev/net-next/c/24e4336a87f5
- [net-next,2/2] dpll: zl3073x: Include current frequency in supported frequencies list
https://git.kernel.org/netdev/net-next/c/85a9aaac4a38
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] dpll: zl3073x: Fix output pin phase adjustment sign
From: patchwork-bot+netdevbpf @ 2026-02-07 4:50 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Prathosh.Satish, vadim.fedorenko, arkadiusz.kubalewski,
jiri, linux-kernel
In-Reply-To: <20260205181055.129768-1-ivecera@redhat.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 19:10:55 +0100 you wrote:
> The output pin phase adjustment functions incorrectly negate the phase
> compensation value.
>
> Per the ZL3073x datasheet, the output phase compensation register is
> simply a signed two's complement integer where:
> - Positive values move the phase later in time
> - Negative values move the phase earlier in time
>
> [...]
Here is the summary with links:
- [net] dpll: zl3073x: Fix output pin phase adjustment sign
https://git.kernel.org/netdev/net/c/5d41f95f5d0b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2 0/4] mptcp: misc fixes for v6.19-rc8
From: patchwork-bot+netdevbpf @ 2026-02-07 4:50 UTC (permalink / raw)
To: Matthieu Baerts
Cc: martineau, geliang, davem, edumazet, kuba, pabeni, horms, netdev,
mptcp, linux-kernel, stable, syzbot+f56f7d56e2c6e11a01b6, rdunlap,
donald.hunter, shuah, linux-kselftest
In-Reply-To: <20260205-net-mptcp-misc-fixes-6-19-rc8-v2-0-c2720ce75c34@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 05 Feb 2026 18:34:20 +0100 you wrote:
> Here are various unrelated fixes:
>
> - Patch 1: when removing an MPTCP in-kernel PM endpoint, always mark the
> corresponding ID as "available". Syzbot found a corner case where it
> is not marked as such. A fix for up to v5.10.
>
> - Patch 2: Linked to the previous patch, the variable name was confusing
> and was probably partly responsible for the issue fixed by patch 1. No
> "Fixes" tag: no need to backport that for the moment, but better to
> avoid confusion now.
>
> [...]
Here is the summary with links:
- [net,v2,1/4] mptcp: pm: in-kernel: always set ID as avail when rm endp
https://git.kernel.org/netdev/net/c/d191101dee25
- [net,v2,2/4] mptcp: pm: in-kernel: clarify mptcp_pm_remove_anno_addr()
https://git.kernel.org/netdev/net/c/364a7084df9f
- [net,v2,3/4] mptcp: fix kdoc warnings
https://git.kernel.org/netdev/net/c/136f1e168f49
- [net,v2,4/4] selftests: mptcp: connect: fix maybe-uninitialize warn
https://git.kernel.org/netdev/net/c/53e553369167
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 v5 2/2] virtio_net: add page_pool support for buffer allocation
From: Jakub Kicinski @ 2026-02-07 4:41 UTC (permalink / raw)
To: Vishwanath Seshagiri
Cc: Michael S . Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Andrew Lunn, David S . Miller, Eric Dumazet, Paolo Abeni,
David Wei, Matteo Croce, Ilias Apalodimas, netdev, virtualization,
linux-kernel, kernel-team
In-Reply-To: <20260206002715.1885869-3-vishs@meta.com>
On Thu, 5 Feb 2026 16:27:15 -0800 Vishwanath Seshagiri wrote:
> + page = page_pool_alloc_frag(rq->page_pool, &offset, len + room, gfp);
> + if (unlikely(!page))
> return -ENOMEM;
>
> + buf = page_address(page) + offset;
Please take a look at page_pool_alloc_va()
I mean all the way down until you reach page_pool_alloc_netmem()
and realize the helper you're adding in patch 1 is a solved problem
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2] net: ti: icssg: Remove dedicated workqueue for ndo_set_rx_mode callback
From: patchwork-bot+netdevbpf @ 2026-02-07 4:40 UTC (permalink / raw)
To: Kevin Hao
Cc: netdev, danishanwar, rogerq, andrew+netdev, davem, edumazet, kuba,
pabeni, m-malladi, jacob.e.keller, vadim.fedorenko, h-mittal1,
horms, byungchul, elfring, linux-arm-kernel
In-Reply-To: <20260205-icssg-prueth-workqueue-v2-1-cf5cf97efb37@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 05 Feb 2026 14:25:09 +0800 you wrote:
> Currently, both the icssg-prueth and icssg-prueth-sr1 drivers create
> a dedicated 'emac->cmd_wq' workqueue.
>
> In the icssg-prueth-sr1 driver, this workqueue is not utilized at all.
>
> In the icssg-prueth driver, the workqueue is only used to execute the
> actual processing of ndo_set_rx_mode. However, creating a dedicated
> workqueue for such a simple use case is unnecessary. To simplify the
> code, switch to using the system default workqueue instead.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: ti: icssg: Remove dedicated workqueue for ndo_set_rx_mode callback
https://git.kernel.org/netdev/net-next/c/b6e2db0ed9b9
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] ipv6: do not use skb_header_pointer() in icmpv6_filter()
From: patchwork-bot+netdevbpf @ 2026-02-07 4:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, kuniyu, netdev, eric.dumazet
In-Reply-To: <20260205211909.4115285-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 21:19:09 +0000 you wrote:
> Prefer pskb_may_pull() to avoid a stack canary in raw6_local_deliver().
>
> Note: skb->head can change, hence we reload ip6h pointer in
> ipv6_raw_deliver()
>
> $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-86 (-86)
> Function old new delta
> raw6_local_deliver 780 694 -86
> Total: Before=24889784, After=24889698, chg -0.00%
>
> [...]
Here is the summary with links:
- [net-next] ipv6: do not use skb_header_pointer() in icmpv6_filter()
https://git.kernel.org/netdev/net-next/c/a14d93179045
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] tcp: inline tcp_filter()
From: patchwork-bot+netdevbpf @ 2026-02-07 4:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, netdev,
eric.dumazet
In-Reply-To: <20260205164329.3401481-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 16:43:29 +0000 you wrote:
> This helper is already (auto)inlined from IPv4 TCP stack.
>
> Make it an inline function to benefit IPv6 as well.
>
> $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
> add/remove: 0/2 grow/shrink: 1/0 up/down: 30/-49 (-19)
> Function old new delta
> tcp_v6_rcv 3448 3478 +30
> __pfx_tcp_filter 16 - -16
> tcp_filter 33 - -33
> Total: Before=24891904, After=24891885, chg -0.00%
>
> [...]
Here is the summary with links:
- [net-next] tcp: inline tcp_filter()
https://git.kernel.org/netdev/net-next/c/a35b6e4863d8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net-next,7/9] mlx5: psp: implement deferred tx key deletion
From: Jakub Kicinski @ 2026-02-07 4:32 UTC (permalink / raw)
To: daniel.zahka
Cc: Jakub Kicinski, linux-kselftest, tariqt, shuah, borisp, leon,
davem, horms, andrew+netdev, netdev, saeedm, edumazet,
willemdebruijn.kernel, donald.hunter, pabeni, mbloch
In-Reply-To: <20260204-psp-v1-7-5f034e2dfa36@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
mlx5: psp: implement deferred tx key deletion
This patch implements the deferred tx key deletion API for mlx5. The
mlx5e_psp_tx_grace_begin() function records WQE counts on each tx queue,
and mlx5e_psp_tx_grace_end() returns success only after all tx queues
have advanced a full ring cycle past the snapshot point.
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.h b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.h
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.h
> @@ -22,10 +22,17 @@ struct mlx5e_psp_stats {
> u64 psp_tx_bytes_drop;
> };
>
> +struct mlx5e_psp_tx_snapshot {
> + int num_channels;
> + int num_tc;
> + u64 wqes[];
> +};
> +
> struct mlx5e_psp {
> struct psp_dev *psp;
> struct psp_dev_caps caps;
> struct mlx5e_psp_fs *fs;
> + struct mlx5e_psp_tx_snapshot *tx_snapshot;
> atomic_t tx_key_cnt;
> atomic_t tx_drop;
> };
Can the tx_snapshot allocation be leaked during device teardown?
If mlx5e_psp_tx_grace_begin() is called and allocates tx_snapshot, but
mlx5e_psp_cleanup() runs before mlx5e_psp_tx_grace_end() frees it:
mlx5e_psp_cleanup()
kfree(psp); // psp->tx_snapshot not freed
The tx_snapshot memory would be leaked. Should mlx5e_psp_cleanup() free
psp->tx_snapshot before freeing psp?
^ permalink raw reply
* Re: [net-next,1/9] psp: support rx rekey operation
From: Jakub Kicinski @ 2026-02-07 4:32 UTC (permalink / raw)
To: daniel.zahka
Cc: Jakub Kicinski, linux-kselftest, tariqt, shuah, borisp, leon,
davem, horms, andrew+netdev, netdev, saeedm, edumazet,
willemdebruijn.kernel, donald.hunter, pabeni, mbloch
In-Reply-To: <20260204-psp-v1-1-5f034e2dfa36@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
psp: support rx rekey operation
This patch adds support for rx-assoc netlink operation on an already keyed
socket, enabling rx rekey by splicing a new psp_assoc object with newly
generated rx state and reused tx state.
> diff --git a/net/psp/psp_sock.c b/net/psp/psp_sock.c
> index f785672b7df6..3a8abd023f99 100644
> --- a/net/psp/psp_sock.c
> +++ b/net/psp/psp_sock.c
[ ... ]
> @@ -129,30 +130,42 @@ void psp_sk_assoc_free(struct sock *sk)
> psp_assoc_put(pas);
> }
>
> -int psp_sock_assoc_set_rx(struct sock *sk, struct psp_assoc *pas,
> - struct psp_key_parsed *key,
> - struct netlink_ext_ack *extack)
> +static void psp_sock_rx_rekey(struct psp_assoc *pas, struct psp_assoc *prev)
> {
> - int err;
> + lockdep_assert_held(&pas->psd->lock);
> +
> + pas->peer_tx = prev->peer_tx;
> + pas->upgrade_seq = prev->upgrade_seq;
> +
> + /* steal refcount from sk->psp_assoc */
> + pas->prev = prev;
> +
> + memcpy(&pas->tx, &prev->tx, sizeof(pas->tx));
> + memcpy(pas->drv_data, prev->drv_data, pas->psd->caps->assoc_drv_spc);
Is there a check that prev->psd == pas->psd before this memcpy?
The psp_assoc_device_get_locked() pre_doit handler obtains the PSP device from
the socket's current destination route via psp_dev_get_for_sock(), but this
may differ from the device used when the existing association (prev) was
created if the route changed.
The memcpy copies pas->psd->caps->assoc_drv_spc bytes from prev->drv_data, but
if prev->psd has a smaller assoc_drv_spc, this could read beyond the bounds of
prev->drv_data.
For comparison, psp_sock_assoc_set_tx() has explicit device validation:
if (pas->psd != psd)
NL_SET_ERR_MSG(extack, "Rx key from different device");
Should psp_sock_rx_rekey() have a similar check?
> + prev->tx_moved = true;
^ permalink raw reply
* Re: [PATCH net-next 7/9] mlx5: psp: implement deferred tx key deletion
From: Jakub Kicinski @ 2026-02-07 4:30 UTC (permalink / raw)
To: Daniel Zahka
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Donald Hunter, Boris Pismenny, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, Shuah Khan,
Willem de Bruijn, netdev, linux-kselftest
In-Reply-To: <20260204-psp-v1-7-5f034e2dfa36@gmail.com>
On Wed, 04 Feb 2026 07:20:11 -0800 Daniel Zahka wrote:
> Implement the deferred tx key deletion api. In the case of mlx5,
> mlx5e_psp_tx_grace_begin() records the number of wqes retired on each
> tx queue, and then mlx5e_psp_tx_grace_end() returns 0 only if
> all tx queues have advanced a full ring cycle past the point where
> they were snapshotted.
Either Friday night enlightenment or I'm very tired -- but I wonder if
we can do with BQL, without touching the driver at all?
struct dql {
/* Fields accessed in enqueue path (dql_queued) */
unsigned int num_queued; /* Total ever queued */
...
/* Fields accessed only by completion path (dql_completed) */
unsigned int num_completed; /* Total ever completed */
...
};
These are free running counters of how many bytes were queued to
the driver and how many driver finished xmit'ing.
^ permalink raw reply
* Re: [PATCH net-next 1/9] psp: support rx rekey operation
From: Jakub Kicinski @ 2026-02-07 4:24 UTC (permalink / raw)
To: Daniel Zahka
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Donald Hunter, Boris Pismenny, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, Shuah Khan,
Willem de Bruijn, netdev, linux-kselftest
In-Reply-To: <20260204-psp-v1-1-5f034e2dfa36@gmail.com>
On Wed, 04 Feb 2026 07:20:05 -0800 Daniel Zahka wrote:
> --- a/include/net/psp/types.h
> +++ b/include/net/psp/types.h
> @@ -139,6 +139,9 @@ struct psp_assoc {
>
> u32 upgrade_seq;
>
> + struct psp_assoc *prev;
> +
> + bool tx_moved;
> struct psp_key_parsed tx;
> struct psp_key_parsed rx;
IIUC think tx_moved is going away in v2, but please double check
the layout here with pahole -C psp_assoc. We the fastpath fields
in the first cacheline (or two?) The tx_moved the way it's placed
would create a hole, and hopefully for success path we don't have
to check prev at all.
^ permalink raw reply
* Re: [PATCH net-next 0/9] psp: support rekeying psp protected tcp connections
From: Jakub Kicinski @ 2026-02-07 4:21 UTC (permalink / raw)
To: Daniel Zahka
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Donald Hunter, Boris Pismenny, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, Shuah Khan,
Willem de Bruijn, netdev, linux-kselftest
In-Reply-To: <20260204-psp-v1-0-5f034e2dfa36@gmail.com>
On Wed, 04 Feb 2026 07:20:04 -0800 Daniel Zahka wrote:
> Daniel Zahka (9):
> psp: support rx rekey operation
> psp: move code from psp_sock_assoc_set_tx() into helper functions
> psp: support tx rekey operation
> psp: refactor psp_dev_tx_key_del()
> psp: add driver api for deferred tx key deletion
> psp: add core tracked stats for deferred key deletion
> mlx5: psp: implement deferred tx key deletion
> selftests: drv-net: psp: lift psp connection setup out of _data_basic_send() testcase
> selftests: drv-net: psp: add tests for rekeying connections
Sorry to say but my immediate reaction when seeing this on the list
on Wednesday was "wait, no packetdrill tests?.. we never finalized
and upstreamed packet drill tests.."
Let's get that wrapped up first, then we can move onto more features.
^ permalink raw reply
* Re: [PATCH net-next] net_sched: sch_fq: rework fq_gc() to avoid stack canary
From: patchwork-bot+netdevbpf @ 2026-02-07 4:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260204190034.76277-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 4 Feb 2026 19:00:34 +0000 you wrote:
> Using kmem_cache_free_bulk() in fq_gc() was not optimal.
>
> 1) It needs an array.
> 2) It is only saving cpu cycles for large batches.
>
> The automatic array forces a stack canary, which is expensive.
>
> [...]
Here is the summary with links:
- [net-next] net_sched: sch_fq: rework fq_gc() to avoid stack canary
https://git.kernel.org/netdev/net-next/c/2214aab26811
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] hinic3: select CONFIG_DIMLIB
From: patchwork-bot+netdevbpf @ 2026-02-07 4:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: gongfan1, andrew+netdev, davem, edumazet, kuba, pabeni, zhuyikai1,
arnd, guoxin09, gur.stavi, netdev, linux-kernel
In-Reply-To: <20260205161530.1308504-1-arnd@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 5 Feb 2026 17:13:48 +0100 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The driver started using dimlib but fails to select the corresponding
> symbol, which results in a link failure:
>
> x86_64-linux-ld: drivers/net/ethernet/huawei/hinic3/hinic3_irq.o: in function `hinic3_poll':
> hinic3_irq.c:(.text+0x179): undefined reference to `net_dim'
> x86_64-linux-ld: drivers/net/ethernet/huawei/hinic3/hinic3_irq.o: in function `hinic3_rx_dim_work':
> hinic3_irq.c:(.text+0x1fb): undefined reference to `net_dim_get_rx_moderation'
>
> [...]
Here is the summary with links:
- [net-next] hinic3: select CONFIG_DIMLIB
https://git.kernel.org/netdev/net-next/c/2d593cf14670
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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