* Re: [PATCH net] vsock/test: fix send_buf()/recv_buf() EINTR handling
From: patchwork-bot+netdevbpf @ 2026-04-07 1:50 UTC (permalink / raw)
To: Stefano Garzarella; +Cc: netdev, davem, avkrasnov, linux-kernel, virtualization
In-Reply-To: <20260403093251.30662-1-sgarzare@redhat.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 3 Apr 2026 11:32:51 +0200 you wrote:
> From: Stefano Garzarella <sgarzare@redhat.com>
>
> When send() or recv() returns -1 with errno == EINTR, the code skips
> the break but still adds the return value to nwritten/nread, making it
> decrease by 1. This leads to wrong buffer offsets and wrong bytes count.
>
> Fix it by explicitly continuing the loop on EINTR, so the return value
> is only added when it is positive.
>
> [...]
Here is the summary with links:
- [net] vsock/test: fix send_buf()/recv_buf() EINTR handling
https://git.kernel.org/netdev/net/c/24ad7ff66889
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] ip6_tunnel: use generic for_each_ip_tunnel_rcu macro
From: patchwork-bot+netdevbpf @ 2026-04-07 1:50 UTC (permalink / raw)
To: Yue Haibing
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, netdev,
linux-kernel
In-Reply-To: <20260403084619.4107978-1-yuehaibing@huawei.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 3 Apr 2026 16:46:19 +0800 you wrote:
> Remove the locally defined for_each_ip6_tunnel_rcu macro and use
> the generic for_each_ip_tunnel_rcu from linux/if_tunnel.h instead.
>
> This eliminates code duplication and ensures consistency across
> the kernel tunnel implementations.
>
> Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
>
> [...]
Here is the summary with links:
- [net-next] ip6_tunnel: use generic for_each_ip_tunnel_rcu macro
https://git.kernel.org/netdev/net-next/c/2f60df9e61aa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [PATCH] bpf: add is_locked_tcp_sock guard for sock_ops rtt_min access
From: Werner Kasselman @ 2026-04-07 1:56 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Jiayuan Chen, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, John Fastabend, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lawrence Brakmo, bpf@vger.kernel.org,
netdev@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <2026471147.8A6S.martin.lau@linux.dev>
Thanks for the review.
You are right that this is not limited to the SYN-ACK header-option paths.
The same unguarded ctx->rtt_min access is reachable from request_sock-backed
sock_ops invocations through tcp_call_bpf(), including BPF_SOCK_OPS_RWND_INIT,
BPF_SOCK_OPS_TIMEOUT_INIT, and BPF_SOCK_OPS_NEEDS_ECN. I'll update the
changelog to describe the affected paths more accurately.
I also agree that this should not duplicate the existing guarded ctx-access
sequence. I'll rework the change to reuse a common helper/macro instead of
open-coding another copy, and I'll add a selftest as a subtest of [1] after
[1] lands.
Thanks,
Werner
-----Original Message-----
From: Martin KaFai Lau <martin.lau@linux.dev>
Sent: Tuesday, 7 April 2026 11:26 AM
To: Werner Kasselman <werner@verivus.ai>
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>; Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>; Andrii Nakryiko <andrii@kernel.org>; John Fastabend <john.fastabend@gmail.com>; David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Lawrence Brakmo <brakmo@fb.com>; bpf@vger.kernel.org; netdev@vger.kernel.org; stable@vger.kernel.org
Subject: Re: [PATCH] bpf: add is_locked_tcp_sock guard for sock_ops rtt_min access
On Mon, Apr 06, 2026 at 10:49:56PM +0000, Werner Kasselman wrote:
> sock_ops_convert_ctx_access() generates BPF instructions to inline
> context field accesses for BPF_PROG_TYPE_SOCK_OPS programs. For
> tcp_sock-specific fields like snd_cwnd, srtt_us, etc., it uses the
> SOCK_OPS_GET_TCP_SOCK_FIELD() macro which checks is_locked_tcp_sock
> and returns 0 when the socket is not a locked full TCP socket.
>
> However, the rtt_min field bypasses this guard entirely: it emits a
> raw two-instruction load sequence (load sk pointer, then load from
> tcp_sock->rtt_min offset) without checking is_locked_tcp_sock first.
>
> This is a problem because bpf_skops_hdr_opt_len() and
> bpf_skops_write_hdr_opt() in tcp_output.c set sock_ops.sk to a
> tcp_request_sock (cast from request_sock) during SYN-ACK processing,
> with is_fullsock=0 and is_locked_tcp_sock=0. If a SOCK_OPS program
> with BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG reads ctx->rtt_min in this
> callback, the generated code treats the tcp_request_sock pointer as a
> tcp_sock and reads at offsetof(struct tcp_sock, rtt_min) -- which is
> well past the end of the tcp_request_sock allocation, causing an
> out-of-bounds slab read.
This is not limited to hdr related CB flags.
It also happens to earlier CB flags that have a request_sock, such as BPF_SOCK_OPS_RWND_INIT.
>
> The rtt_min field was introduced in the same commit as the other
> tcp_sock fields but was given hand-rolled access code because it reads
> a sub-field (rtt_min.s[0].v, a minmax_sample) rather than a direct
> struct member, making it incompatible with the SOCK_OPS_GET_FIELD()
> macro. This hand-rolled code omitted the is_fullsock guard that the
> macro provides. The guard was later renamed to is_locked_tcp_sock in
> commit fd93eaffb3f9 ("bpf: Prevent unsafe access to the sock fields in the BPF timestamping callback").
>
> Add the is_locked_tcp_sock guard to the rtt_min case, replicating the
> exact instruction pattern used by SOCK_OPS_GET_FIELD() including
> proper handling of the dst_reg==src_reg case with temp register
> save/restore. Use offsetof(struct minmax_sample, v) for the sub-field
> offset to match the style in bpf_tcp_sock_convert_ctx_access().
>
> Found via AST-based call-graph analysis using sqry.
>
> Fixes: 44f0e43037d3 ("bpf: Add support for reading sk_state and more")
> Cc: stable@vger.kernel.org
> Signed-off-by: Werner Kasselman <werner@verivus.com>
> ---
> net/core/filter.c | 47
> ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c index
> 78b548158fb0..58f0735b18d9 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -10830,13 +10830,54 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type,
> BUILD_BUG_ON(sizeof(struct minmax) <
> sizeof(struct minmax_sample));
>
> + /* Unlike other tcp_sock fields that use
> + * SOCK_OPS_GET_TCP_SOCK_FIELD(), rtt_min requires a
> + * custom access pattern because it reads a sub-field
> + * (rtt_min.s[0].v) rather than a direct struct member.
> + * We must still guard the access with is_locked_tcp_sock
> + * to prevent an OOB read when sk points to a
> + * tcp_request_sock (e.g., during SYN-ACK processing via
> + * bpf_skops_hdr_opt_len/bpf_skops_write_hdr_opt).
> + */
> + off = offsetof(struct tcp_sock, rtt_min) +
> + offsetof(struct minmax_sample, v);
> + {
> + int fullsock_reg = si->dst_reg, reg = BPF_REG_9, jmp = 2;
> +
> + if (si->dst_reg == reg || si->src_reg == reg)
> + reg--;
> + if (si->dst_reg == reg || si->src_reg == reg)
> + reg--;
> + if (si->dst_reg == si->src_reg) {
> + *insn++ = BPF_STX_MEM(BPF_DW, si->src_reg, reg,
> + offsetof(struct bpf_sock_ops_kern,
> + temp));
> + fullsock_reg = reg;
> + jmp += 2;
> + }
> + *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(
> + struct bpf_sock_ops_kern,
> + is_locked_tcp_sock),
> + fullsock_reg, si->src_reg,
> + offsetof(struct bpf_sock_ops_kern,
> + is_locked_tcp_sock));
> + *insn++ = BPF_JMP_IMM(BPF_JEQ, fullsock_reg, 0, jmp);
> + if (si->dst_reg == si->src_reg)
> + *insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg,
> + offsetof(struct bpf_sock_ops_kern,
> + temp));
> *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(
> struct bpf_sock_ops_kern, sk),
> si->dst_reg, si->src_reg,
> offsetof(struct bpf_sock_ops_kern, sk));
> - *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->dst_reg,
> - offsetof(struct tcp_sock, rtt_min) +
> - sizeof_field(struct minmax_sample, t));
> + *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->dst_reg, off);
> + if (si->dst_reg == si->src_reg) {
> + *insn++ = BPF_JMP_A(1);
> + *insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg,
> + offsetof(struct bpf_sock_ops_kern,
> + temp));
There is an existing bug in this copy-and-paste codes [1] and now is repeated here, so please find a way to refactor it to be reusable instead of duplicating it.
This also needs a test. It should be a subtest of [1], so [1] need to land first.
[1]: https://lore.kernel.org/bpf/20260406031330.187630-1-jiayuan.chen@linux.dev/
^ permalink raw reply
* Re: [PATCH 1/3] [v4, net-next] net: ethernet: ti-cpsw:: rename soft_reset() function
From: Jakub Kicinski @ 2026-04-07 2:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Simon Horman, Ilias Apalodimas, Arnd Bergmann, Netdev,
Andrew Lunn, David S . Miller, Eric Dumazet, Paolo Abeni,
Grygorii Strashko, Murali Karicheri, Siddharth Vadapalli,
Roger Quadros, Vladimir Oltean, Alexander Sverdlin, Ioana Ciornei,
Linux-OMAP, Kevin Hao, Daniel Zahka, linux-kernel
In-Reply-To: <64384fd1-edb3-4c7a-9ba8-56385a303d35@app.fastmail.com>
On Sun, 05 Apr 2026 21:31:28 +0200 Arnd Bergmann wrote:
> On Sat, Apr 4, 2026, at 11:11, Simon Horman wrote:
> > On Thu, Apr 02, 2026 at 09:16:29PM +0200, Arnd Bergmann wrote:
> >> On Thu, Apr 2, 2026, at 21:13, Ilias Apalodimas wrote:
> >>
> >> Before the c5013ac1dd0e1 commit, this was a 'static inline' function,
> >> which is allowed to clash with other identifiers. Making it a global
> >> symbol during the move was a problem.
> >
> > If we are going to treat this as a fix then probably it should be separated
> > from the rest of the patchset and routed via net. With the rump patchset
> > re-submitted to net-next once dependencies are in place.
>
> I'll drop patch 1 then and send the other two when I get the next
> regression with duplicate objects in a couple of releases. I'm
> travelling at the moment and won't have time to rebase and test
> before the merge window.
>
> It's no longer urgent since both cpsw and dpaa2 have been broken for
> years now since I first reported the regression.
Seems borderline, let me take it via net-next without the Fixes tag.
^ permalink raw reply
* Re: [PATCH] net/nfc: bound SENSF response copy length
From: Pengpeng Hou @ 2026-04-07 3:30 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Kees Cook, linux-kernel, pengpeng
In-Reply-To: <20260322031922.57949-1-pengpeng@iscas.ac.cn>
Hi Simon,
Thanks, you're right about the net targeting, the NFC: digital:
prefix, and the missing Fixes tag.
You are also right that a valid full SENSF_RES can be 19 bytes long.
So instead of rejecting resp->len > NFC_SENSF_RES_MAXSIZE, v2 only
rejects payloads larger than struct digital_sensf_res, then clamps the
copy into the 18-byte sensf_res buffer inside struct nfc_target.
That keeps valid 19-byte responses working while still fixing the stack
overwrite in the target copy path. The lower-bound check remains on the
pre-skb_pull() frame length, and v2 only adds the post-pull upper bound
before treating the payload as struct digital_sensf_res.
Thanks,
Pengpeng
^ permalink raw reply
* Re: [PATCH net-next v9 4/4] net: stmmac: Add BCM8958x driver to build system
From: Jakub Kicinski @ 2026-04-07 2:08 UTC (permalink / raw)
To: Jitendra Vegiraju
Cc: netdev, alexandre.torgue, davem, edumazet, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
horms, sdf, me, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan,
wens, vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-5-jitendra.vegiraju@broadcom.com>
On Thu, 2 Apr 2026 14:36:29 -0700 Jitendra Vegiraju wrote:
> +BROADCOM BCM8958X ETHERNET DRIVER
> +M: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> +R: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
Should be:
L: <bcm-kernel-feedback-list@broadcom.com>
It's not a parson.
Before you ask - FWIW what other subsystems allow in MAINTAINERS
is irrelevant.
> +L: netdev@vger.kernel.org
^ permalink raw reply
* Re: [PATCH net-next v9 1/4] net: stmmac: Add DW25GMAC support in stmmac core driver
From: Jakub Kicinski @ 2026-04-07 2:09 UTC (permalink / raw)
To: jitendra.vegiraju
Cc: Jakub Kicinski, netdev, alexandre.torgue, davem, edumazet, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
horms, sdf, me, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan,
wens, vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-2-jitendra.vegiraju@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.
---
Subject: net: stmmac: Add DW25GMAC support in stmmac core driver
This commit introduces support for the DW25GMAC hardware in the stmmac
core driver, which uses a new Hyper-DMA (HDMA) architecture. It adds a
new DMA ops instance mapping virtual DMA channels to physical DMA
channels and sets up the basic device configurations.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dw25gmac.c b/drivers/net/ethernet/stmicro/stmmac/dw25gmac.c
> new file mode 100644
> index 0000000000000..82eb22bff73e0
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dw25gmac.c
[ ... ]
> +static int rd_dma_ch_ind(void __iomem *ioaddr, u8 mode, u32 channel)
> +{
> + u32 reg_val = 0;
> +
> + reg_val |= FIELD_PREP(XXVGMAC_MODE_SELECT, mode);
> + reg_val |= FIELD_PREP(XXVGMAC_ADDR_OFFSET, channel);
> + reg_val |= XXVGMAC_CMD_TYPE | XXVGMAC_OB;
> + writel(reg_val, ioaddr + XXVGMAC_DMA_CH_IND_CONTROL);
> + return readl(ioaddr + XXVGMAC_DMA_CH_IND_DATA);
> +}
Does this readl() need to wait for the hardware to clear the XXVGMAC_OB
(Operation Busy) bit? Returning immediately might read uninitialized or
stale data if the hardware hasn't finished the fetch.
> +
> +static void wr_dma_ch_ind(void __iomem *ioaddr, u8 mode, u32 channel, u32 val)
> +{
> + u32 reg_val = 0;
> +
> + writel(val, ioaddr + XXVGMAC_DMA_CH_IND_DATA);
> + reg_val |= FIELD_PREP(XXVGMAC_MODE_SELECT, mode);
> + reg_val |= FIELD_PREP(XXVGMAC_ADDR_OFFSET, channel);
> + reg_val |= XGMAC_OB;
This isn't a bug, but should this use the XXVGMAC_OB macro instead of
XGMAC_OB here for consistency?
> + writel(reg_val, ioaddr + XXVGMAC_DMA_CH_IND_CONTROL);
> +}
Similarly, does this function need to poll for the busy bit to clear after
the writel()? If back-to-back operations occur, the next indirect write
might overwrite the control and data registers while the hardware is still
processing this request.
[ ... ]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> index f02b434bbd505..64c38de294da2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
[ ... ]
> -int dwxgmac2_setup(struct stmmac_priv *priv)
> +static void dwxgmac2_common_setup(struct stmmac_priv *priv, char *mac_name)
> {
This isn't a bug, but should mac_name be declared as const char * since it
is passed string literals like "XGMAC2" and "DW25GMAC"? This avoids
discarded-qualifiers compiler warnings.
> struct mac_device_info *mac = priv->hw;
>
> - dev_info(priv->device, "\tXGMAC2\n");
> + dev_info(priv->device, "\t%s\n", mac_name);
[ ... ]
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v9 2/4] net: stmmac: Integrate dw25gmac into hwif handling
From: Jakub Kicinski @ 2026-04-07 2:09 UTC (permalink / raw)
To: jitendra.vegiraju
Cc: Jakub Kicinski, netdev, alexandre.torgue, davem, edumazet, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
horms, sdf, me, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan,
wens, vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-3-jitendra.vegiraju@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.
---
net: stmmac: Integrate dw25gmac into hwif handling
Integrate dw25gmac support into stmmac hardware interface handling.
Added a new entry to the stmmac_hw table in hwif.c.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> index 511b0fd5e8343..a69f558c0db06 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> @@ -287,6 +287,26 @@ static const struct stmmac_hwif_entry {
> .mmc = &dwxgmac_mmc_ops,
> .est = &dwmac510_est_ops,
> .setup = dwxlgmac2_setup,
> + }, {
> + .core_type = DWMAC_CORE_25GMAC,
> + .min_id = DW25GMAC_CORE_3_20,
Are there other areas where the core capabilities will be misidentified?
Throughout stmmac_main.c and stmmac_ethtool.c, hardware features branch
explicitly on core_type == DWMAC_CORE_XGMAC instead of including
DWMAC_CORE_25GMAC.
This seems to cause a few side effects:
- stmmac_ethtool_get_drvinfo() misreports the driver as MAC100_ETHTOOL_NAME
(st_mac100).
- stmmac_main.c enforces legacy MTU limits rather than XGMAC_JUMBO_LEN.
- stmmac_dma_cap_show() debugfs output treats the 25GMAC count of multiple
MAC address registers as a simple boolean and omits Timestamp System Time
Source details.
Does this also break MDIO communication for the PHY?
In stmmac_mdio_register(), XGMAC MDIO accessors are assigned strictly if
priv->plat->core_type == DWMAC_CORE_XGMAC. Because 25GMAC is omitted, it
falls into the else block and assigns legacy GMAC callbacks like
stmmac_mdio_read_c22().
The GMAC accessors format the control word using GMAC bitfields (checking
MII_ADDR_GBUSY at bit 0), while the XGMAC register layout expects
MII_XGMAC_BUSY at bit 22.
Could this misconfiguration write invalid bit patterns to the register and
wait on the wrong bit?
> + .regs = {
> + .ptp_off = PTP_XGMAC_OFFSET,
> + .mmc_off = MMC_XGMAC_OFFSET,
> + .est_off = EST_XGMAC_OFFSET,
Will this misconfigure the Time-to-Output Value for EST (802.3 Qbv)?
In stmmac_est.c, est_configure() and est_irq_status() use
if (priv->plat->core_type == DWMAC_CORE_XGMAC) to differentiate XGMAC from
GMAC5.
Without 25GMAC in that check, it falls through to the GMAC5 logic, applying
the EST_GMAC5_PTOV mask (bits 31:24) instead of the EST_XGMAC_PTOV mask
(bits 31:23) to the EST control register at EST_XGMAC_OFFSET.
> + },
> + .desc = &dwxgmac210_desc_ops,
> + .dma = &dw25gmac400_dma_ops,
> + .mac = &dwxgmac210_ops,
Does adding these ops introduce a buffer overflow during ethtool register
dumps?
Since stmmac_ethtool_get_regs_len() does not match DWMAC_CORE_25GMAC, it
falls back to returning REG_SPACE_SIZE (4192 bytes, or 1048 u32 elements).
However, these ops use the dwxgmac2_dump_regs() and dwxgmac2_dma_dump_regs()
callbacks, which write far beyond the 1048-element buffer:
- dwxgmac2_dump_regs() writes up to index XGMAC_MAC_REGSIZE (1309 elements).
- dwxgmac2_dma_dump_regs() writes from XGMAC_DMA_MODE / 4 (3072) to
XGMAC_REGSIZE (3647 elements).
Will this corrupt kernel memory when a privileged user runs ethtool -d?
> + .vlan = &dwxgmac210_vlan_ops,
> + .hwtimestamp = &stmmac_ptp,
> + .ptp = &stmmac_ptp_clock_ops,
> + .mode = NULL,
> + .tc = &dwmac510_tc_ops,
> + .mmc = &dwxgmac_mmc_ops,
> + .est = &dwmac510_est_ops,
> + .setup = dw25gmac_setup,
> + .quirks = NULL,
> },
> };
^ permalink raw reply
* Re: [PATCH net-next v9 3/4] net: stmmac: Add PCI glue driver for BCM8958x
From: Jakub Kicinski @ 2026-04-07 2:10 UTC (permalink / raw)
To: jitendra.vegiraju
Cc: Jakub Kicinski, netdev, alexandre.torgue, davem, edumazet, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
horms, sdf, me, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan,
wens, vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-4-jitendra.vegiraju@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.
---
Date: Thu Apr 2 21:36:28 2026 +0000
net: stmmac: Add PCI glue driver for BCM8958x
Add pci ethernet driver support for Broadcom BCM8958x soc devices used
in automotive applications. This device features a pcie ethernet mac
directly attached to an integrated ethernet switch using an xgmii interface.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-brcm.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-brcm.c
> new file mode 100644
> index 0000000000000..e8c6b4b618acb
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-brcm.c
[ ... ]
> +static const struct software_node *brcm_swnodes[] = {
> + &parent_swnode,
> + &fixed_link_swnode,
> + NULL
> +};
Will this statically allocated global software node array cause issues if
multiple devices are present?
If a second device is probed, software_node_register_node_group might fail
with an error. Additionally, if one device is unbound, unregistering the
group could destroy the global nodes, causing a use-after-free for any other
active instances.
Could these software nodes be dynamically allocated per-device?
[ ... ]
> +static int brcm_drv_init(struct device *dev, void *bsp_priv)
> +{
> + struct brcm_priv_data *brcm_priv = (struct brcm_priv_data *)bsp_priv;
> + struct pci_dev *pdev = to_pci_dev(dev);
> + int vector;
> + int ret;
> +
> + /* This device is directly attached to the switch chip internal to the
> + * SoC using XGMII interface. Since no MDIO is present, register
> + * fixed-link software_node to create phylink.
> + */
> + ret = software_node_register_node_group(brcm_swnodes);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to register software_node\n");
> + device_set_node(dev, software_node_fwnode(&parent_swnode));
Does device_set_node overwrite the device's primary firmware node here?
Using device_set_node can destroy existing acpi or device tree companion
nodes. Would it be safer to use device_add_software_node instead to attach
the node without overwriting the primary firmware node?
> +
> + pci_write_config_dword(pdev, XGMAC_PCIE_CFG_MSIX_ADDR_MATCH_LOW,
> + XGMAC_PCIE_CFG_MSIX_ADDR_MATCH_LO_VALUE);
> + pci_write_config_dword(pdev, XGMAC_PCIE_CFG_MSIX_ADDR_MATCH_HIGH,
> + XGMAC_PCIE_CFG_MSIX_ADDR_MATCH_HI_VALUE);
> +
> + misc_iowrite(brcm_priv, XGMAC_PCIE_MISC_MSIX_ADDR_MATCH_LO_OFFSET,
> + XGMAC_PCIE_MISC_MSIX_ADDR_MATCH_LO_VALUE);
> + misc_iowrite(brcm_priv, XGMAC_PCIE_MISC_MSIX_ADDR_MATCH_HI_OFFSET,
> + XGMAC_PCIE_MISC_MSIX_ADDR_MATCH_HI_VALUE);
[ ... ]
> +static void brcm_drv_exit_cleanup(struct device *dev, void *bsp_priv)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + device_set_node(&pdev->dev, NULL);
> + software_node_unregister_node_group(brcm_swnodes);
> +}
If device_set_node is called with NULL, will it leave the device permanently
mangled without its original firmware node upon unbind?
[ ... ]
> +static int brcm_pci_resume(struct device *dev, void *bsp_priv)
> +{
> + /* Enable Switch Link */
> + misc_iowrite(bsp_priv, XGMAC_PCIE_MISC_MII_CTRL_OFFSET,
> + XGMAC_PCIE_MISC_MII_CTRL_PAUSE_RX |
> + XGMAC_PCIE_MISC_MII_CTRL_PAUSE_TX |
> + XGMAC_PCIE_MISC_MII_CTRL_LINK_UP);
> +
> + return stmmac_pci_plat_resume(dev, bsp_priv);
> +}
Will the hardware state configured in brcm_drv_init be fully restored after
a suspend and resume cycle?
When a pci device resumes from suspend, its internal state is typically reset
to defaults. Since the pci core's pci_save_state does not save arbitrary mmio
registers or custom extended configuration registers, it appears the msi-x
routing and address match configurations programmed during probe might be
lost.
Could this cause the msi-x interrupts to stop working after resume?
^ permalink raw reply
* Re: [PATCH net-next v9 4/4] net: stmmac: Add BCM8958x driver to build system
From: Jakub Kicinski @ 2026-04-07 2:10 UTC (permalink / raw)
To: jitendra.vegiraju
Cc: Jakub Kicinski, netdev, alexandre.torgue, davem, edumazet, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
horms, sdf, me, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan,
wens, vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-5-jitendra.vegiraju@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.
---
net: stmmac: Add BCM8958x driver to build system
This commit adds the PCI driver for the Broadcom BCM8958x to the Linux build
system. It enables the configuration option and updates the MAINTAINERS file.
While reviewing this patch, I noticed a potential regression introduced in the
previous patch of the series (net: stmmac: Add PCI glue driver for BCM8958x)
that is enabled here.
The driver defines a global static array of software nodes (brcm_swnodes)
and registers it in brcm_drv_init() using software_node_register_node_group().
Since PCI drivers must support multiple device instances concurrently, what
happens if there are multiple BCM8958x PCI devices present?
If the second instance's probe attempts to register the exact same software
node pointers, software_node_register() will return -EEXIST. The failure
path in software_node_register_node_group() then unconditionally unregisters
all nodes in the group.
Could this unregister the software nodes that the first probed device
successfully registered and is actively using, leaving the first device with
dangling fwnode pointers and leading to a use-after-free? Would it be safer
to dynamically allocate the software nodes per device instance?
[ ... ]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index dc55aec915a27..a1e39f65cd42e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -51,4 +51,5 @@ obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
> obj-$(CONFIG_DWMAC_INTEL) += dwmac-intel.o
> obj-$(CONFIG_DWMAC_LOONGSON) += dwmac-loongson.o
> obj-$(CONFIG_DWMAC_MOTORCOMM) += dwmac-motorcomm.o
> +obj-$(CONFIG_DWMAC_BRCM) += dwmac-brcm.o
This isn't a bug, but it looks like spaces are used here for alignment instead
of a tab. The surrounding entries all use a tab character before the
assignment operator.
^ permalink raw reply
* Re: [PATCH net-next v2] eth: remove the driver for acenic / tigon1&2
From: patchwork-bot+netdevbpf @ 2026-04-07 2:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, jes,
gregkh, helgaas, chenhuacai, kernel, tsbogend, James.Bottomley,
deller, maddy, mpe, npiggin, chleroy, hca, gor, agordeev,
borntraeger, svens, ebiggers, ardb, tiwai, tytso, enelsonmoore,
martin.petersen, jirislaby, geert, vineethr, lirongqing, kshk,
vadim.fedorenko, wangruikang, dong100, hkallweit1, kees,
loongarch, linux-mips, linux-parisc, linuxppc-dev, linux-s390
In-Reply-To: <20260403220501.2263835-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 3 Apr 2026 15:05:01 -0700 you wrote:
> The entire git history for this driver looks like tree-wide
> and automated cleanups. There's even more coming now with
> AI, so let's try to delete it instead.
>
> Acked-by: Jes Sorensen <jes@trained-monkey.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> [...]
Here is the summary with links:
- [net-next,v2] eth: remove the driver for acenic / tigon1&2
https://git.kernel.org/netdev/net-next/c/e6b7e1a10cba
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net v2] NFC: digital: bound SENSF response copy into nfc_target
From: Pengpeng Hou @ 2026-04-07 1:57 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kees Cook, linux-kernel, pengpeng
In-Reply-To: <20260322031922.57949-1-pengpeng@iscas.ac.cn>
digital_in_recv_sensf_res() copies the received SENSF response into
struct nfc_target without bounding the copy to target.sensf_res. A full
on-wire digital_sensf_res is 19 bytes long, while nfc_target stores 18
bytes, so oversized or full-length frames can overwrite adjacent stack
fields before digital_target_found() sees the target.
Reject payloads larger than struct digital_sensf_res and clamp the copy
into target.sensf_res so valid 19-byte responses keep working while the
fixed destination buffer stays bounded.
Fixes: 8c0695e4998dd268ff2a05951961247b7e015651 ("NFC Digital: Add NFC-F technology support")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- target the net tree and use the NFC: digital: prefix
- add the missing Fixes tag
- preserve valid 19-byte SENSF responses by clamping the copy into
struct nfc_target
- reject only payloads larger than struct digital_sensf_res
net/nfc/digital_technology.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/nfc/digital_technology.c b/net/nfc/digital_technology.c
index 63f1b721c71d..abf544d917f3 100644
--- a/net/nfc/digital_technology.c
+++ b/net/nfc/digital_technology.c
@@ -767,13 +767,18 @@ static void digital_in_recv_sensf_res(struct nfc_digital_dev *ddev, void *arg,
}
skb_pull(resp, 1);
+ if (resp->len > sizeof(struct digital_sensf_res)) {
+ rc = -EIO;
+ goto exit;
+ }
memset(&target, 0, sizeof(struct nfc_target));
sensf_res = (struct digital_sensf_res *)resp->data;
- memcpy(target.sensf_res, sensf_res, resp->len);
- target.sensf_res_len = resp->len;
+ target.sensf_res_len = min_t(unsigned int, resp->len,
+ sizeof(target.sensf_res));
+ memcpy(target.sensf_res, sensf_res, target.sensf_res_len);
memcpy(target.nfcid2, sensf_res->nfcid2, NFC_NFCID2_MAXSIZE);
target.nfcid2_len = NFC_NFCID2_MAXSIZE;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v3 0/5] NFC support for five Qualcomm SDM845 phones
From: patchwork-bot+netdevbpf @ 2026-04-07 2:10 UTC (permalink / raw)
To: David Heidelberg
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, amartinz,
andrew+netdev, davem, edumazet, kuba, pabeni, casey.connolly,
amartinz, petr.hodina, l.j.beemster, netdev, linux-arm-msm,
oe-linux-nfc, devicetree, linux-kernel, phone-devel, krzk
In-Reply-To: <20260403-oneplus-nfc-v3-0-fbdce57d63c1@ixit.cz>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 03 Apr 2026 15:58:45 +0200 you wrote:
> - OnePlus 6 / 6T
> - Pixel 3 / 3 XL
> - SHIFT 6MQ
>
> Verified with NFC card using neard:
>
> systemctl enable --now neard
> nfctool --device nfc0 -1
> nfctool -d nfc0 -p
> gdbus introspect --system --dest org.neard --object-path /org/neard/nfc0/tag0/record0
>
> [...]
Here is the summary with links:
- [v3,1/5] dt-bindings: nfc: nxp,nci: Document PN557 compatible
https://git.kernel.org/netdev/net-next/c/e72058a4bed0
- [v3,2/5] arm64: dts: qcom: sdm845-oneplus: Enable NFC
(no matching commit)
- [v3,3/5] arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state
(no matching commit)
- [v3,4/5] arm64: dts: qcom: sdm845-shift-axolotl: Enable NFC
(no matching commit)
- [v3,5/5] arm64: dts: qcom: sdm845-google-common: Enable NFC
(no matching commit)
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] net: macb: Use netif_napi_add_tx() instead of netif_napi_add() for TX NAPI
From: patchwork-bot+netdevbpf @ 2026-04-07 2:10 UTC (permalink / raw)
To: Kevin Hao
Cc: nicolas.ferre, claudiu.beznea, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev
In-Reply-To: <20260403-macb-napi-tx-v1-1-08126a60c65e@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 03 Apr 2026 22:23:39 +0800 you wrote:
> The TX NAPI should be registered via netif_napi_add_tx() to avoid
> unnecessarily polluting the napi_hash table.
>
> Signed-off-by: Kevin Hao <haokexin@gmail.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> [...]
Here is the summary with links:
- [net-next] net: macb: Use netif_napi_add_tx() instead of netif_napi_add() for TX NAPI
https://git.kernel.org/netdev/net-next/c/c321b5676d0c
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 0/5] mptcp: support MSG_EOR and small cleanups
From: patchwork-bot+netdevbpf @ 2026-04-07 2:20 UTC (permalink / raw)
To: Matthieu Baerts
Cc: martineau, geliang, davem, edumazet, kuba, pabeni, horms, netdev,
mptcp, linux-kernel, yangang, ncardwell, kuniyu, dsahern, shuah,
linux-kselftest
In-Reply-To: <20260403-net-next-mptcp-msg_eor-misc-v1-0-b0b33bea3fed@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 03 Apr 2026 13:29:26 +0200 you wrote:
> This series contains various unrelated patches:
>
> - Patches 1 & 2: support MSG_EOR instead of ignoring it.
>
> - Patch 3: avoid duplicated code in TCP and MPTCP by using a new helper.
>
> - Patch 4: remove duplicated condition.
>
> [...]
Here is the summary with links:
- [net-next,1/5] mptcp: reduce 'overhead' from u16 to u8
https://git.kernel.org/netdev/net-next/c/00d46be3c319
- [net-next,2/5] mptcp: preserve MSG_EOR semantics in sendmsg path
https://git.kernel.org/netdev/net-next/c/7fb2f5f96499
- [net-next,3/5] tcp: add recv_should_stop helper
https://git.kernel.org/netdev/net-next/c/eb477fdd6803
- [net-next,4/5] mptcp: pm: in-kernel: remove mptcp_pm_has_addr_attr_id
(no matching commit)
- [net-next,5/5] selftests: mptcp: join: recreate signal endp with same ID
https://git.kernel.org/netdev/net-next/c/c4a5cb2f00f9
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 1/3] [v4, net-next] net: ethernet: ti-cpsw:: rename soft_reset() function
From: patchwork-bot+netdevbpf @ 2026-04-07 2:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
grygorii.strashko, ilias.apalodimas, m-karicheri2, s-vadapalli,
rogerq, vladimir.oltean, alexander.sverdlin, ioana.ciornei,
linux-omap, arnd, haokexin, daniel.zahka, linux-kernel
In-Reply-To: <20260402184726.3746487-1-arnd@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 20:46:53 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> While looking at the glob symbols shared between the cpsw drivers,
> I noticed that soft_reset() is the only one that is missing a proper
> namespace prefix, and will pollute the kernel namespace, so rename
> it to be consistent with the other symbols.
>
> [...]
Here is the summary with links:
- [1/3,v4,net-next] net: ethernet: ti-cpsw:: rename soft_reset() function
https://git.kernel.org/netdev/net-next/c/961f3c535608
- [2/3,v4,net-next] net: ethernet: ti-cpsw: fix linking built-in code to modules
https://git.kernel.org/netdev/net-next/c/df75bd552a87
- [3/3,v4,net-next] dpaa2: avoid linking objects into multiple modules
https://git.kernel.org/netdev/net-next/c/ede3136e5655
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 v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825
From: Jakub Kicinski @ 2026-04-07 2:23 UTC (permalink / raw)
To: Grzegorz Nitka
Cc: netdev, linux-kernel, intel-wired-lan, poros, richardcochran,
andrew+netdev, przemyslaw.kitszel, anthony.l.nguyen,
Prathosh.Satish, ivecera, jiri, arkadiusz.kubalewski,
vadim.fedorenko, donald.hunter, horms, pabeni, davem, edumazet
In-Reply-To: <20260402230626.3826719-1-grzegorz.nitka@intel.com>
On Fri, 3 Apr 2026 01:06:18 +0200 Grzegorz Nitka wrote:
> This series adds TX reference clock support for E825 devices and exposes
> TX clock selection and synchronization status via the Linux DPLL
> subsystem.
> E825 hardware contains a dedicated Tx clock (TXC) domain that is
> distinct
> from PPS and EEC. TX reference clock selection is device‑wide, shared
> across ports, and mediated by firmware as part of the link bring‑up
> process. As a result, TX clock selection intent may differ from the
> effective hardware configuration, and software must verify the outcome
> after link‑up.
> To support this, the series introduces TXC support incrementally across
> the DPLL core and the ice driver:
>
> - add a new DPLL type (TXC) to represent transmit clock generators;
I'm not grasping why this is needed, isn't it part of any EEC system
that the DPLL can drive the TXC? Is your system going to expose multiple
DPLLs now for one NIC?
> - relax DPLL pin registration rules for firmware‑described shared pins
> and extend pin notifications with a source identifier;
> - allow dynamic state control of SyncE reference pins where hardware
> supports it;
> - add CPI infrastructure for PHY‑side TX clock control on E825C;
> - introduce a TXC DPLL device and TX reference clock pins (EXT_EREF0 and
> SYNCE) in the ice driver;
> - extend the Restart Auto‑Negotiation command to carry a TX reference
> clock index;
> - implement hardware‑backed TX reference clock switching, post‑link
> - verification, and TX synchronization reporting.
>
> TXCLK pins report TX reference topology only. Actual synchronization
> success is reported via the TXC DPLL lock status, which is updated after
> hardware verification: external Tx references report LOCKED, while the
> internal ENET/TXCO source reports UNLOCKED.
> This provides reliable TX reference selection and observability on E825
> devices using standard DPLL interfaces, without conflating user intent
> with effective hardware behavior.
^ permalink raw reply
* [PATCH bpf v3 0/2] bpf: Fix SOCK_OPS_GET_SK same-register OOB read in sock_ops and add selftest
From: Jiayuan Chen @ 2026-04-07 2:26 UTC (permalink / raw)
To: bpf
Cc: werner, Jiayuan Chen, Martin KaFai Lau, Daniel Borkmann,
John Fastabend, Stanislav Fomichev, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan, Sun Jian,
linux-kernel, netdev, linux-kselftest
When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg,
the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the
destination register in the !fullsock / !locked_tcp_sock path, leading to
OOB read (GET_SK) and kernel pointer leak (GET_FIELD).
Patch 1: Fix both macros by adding BPF_MOV64_IMM(si->dst_reg, 0) in the
!fullsock landing pad.
Patch 2: Add selftests covering same-register and different-register cases
for both GET_SK and GET_FIELD.
[1] https://lore.kernel.org/bpf/6fe1243e-149b-4d3b-99c7-fcc9e2f75787@std.uestc.edu.cn/T/#u
Changes since v2:
https://lore.kernel.org/bpf/20260406031330.187630-1-jiayuan.chen@linux.dev/
- Addressed selftest review from Martin KaFai Lau: removed unused skel
parameter, renamed to test_ns_ for automatic netns, ASSERT_GE -> ASSERT_OK_FD
- Add reviewed-by tags.
Changes since v1:
https://lore.kernel.org/bpf/20260404141010.247536-1-jiayuan.chen@linux.dev/
- Fixed the same bug in SOCK_OPS_GET_FIELD() (pointed out by AI review)
- Added SOCK_OPS_GET_FIELD same-register and GET_SK different-register
subtests
Jiayuan Chen (2):
bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops
selftests/bpf: Add tests for sock_ops ctx access with same src/dst
register
net/core/filter.c | 6 +-
.../bpf/prog_tests/sock_ops_get_sk.c | 76 ++++++++++++
.../selftests/bpf/progs/sock_ops_get_sk.c | 117 ++++++++++++++++++
3 files changed, 197 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
create mode 100644 tools/testing/selftests/bpf/progs/sock_ops_get_sk.c
--
2.43.0
^ permalink raw reply
* [PATCH] devlink: Fix incorrect skb socket family dumping
From: lirongqing @ 2026-04-07 2:27 UTC (permalink / raw)
To: Jiri Pirko, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Mateusz Polchlopek, Tony Nguyen,
Przemek Kitszel, netdev, linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
The devlink_fmsg_dump_skb function was incorrectly using the socket
type (sk->sk_type) instead of the socket family (sk->sk_family)
when filling the "family" field in the fast message dump.
This patch fixes this to properly display the socket family.
Fixes: 3dbfde7f6bc7b8 ("devlink: add devlink_fmsg_dump_skb() function")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/devlink/health.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/devlink/health.c b/net/devlink/health.c
index 449c761..ea7a334 100644
--- a/net/devlink/health.c
+++ b/net/devlink/health.c
@@ -1327,7 +1327,7 @@ void devlink_fmsg_dump_skb(struct devlink_fmsg *fmsg, const struct sk_buff *skb)
if (sk) {
devlink_fmsg_pair_nest_start(fmsg, "sk");
devlink_fmsg_obj_nest_start(fmsg);
- devlink_fmsg_put(fmsg, "family", sk->sk_type);
+ devlink_fmsg_put(fmsg, "family", sk->sk_family);
devlink_fmsg_put(fmsg, "type", sk->sk_type);
devlink_fmsg_put(fmsg, "proto", sk->sk_protocol);
devlink_fmsg_obj_nest_end(fmsg);
--
2.9.4
^ permalink raw reply related
* [PATCH bpf v3 1/2] bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops
From: Jiayuan Chen @ 2026-04-07 2:26 UTC (permalink / raw)
To: bpf
Cc: werner, Jiayuan Chen, Quan Sun, Yinhao Hu, Kaiyan Mei,
Dongliang Mu, Emil Tsalapatis, Martin KaFai Lau, Daniel Borkmann,
John Fastabend, Stanislav Fomichev, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan, Sun Jian,
linux-kernel, netdev, linux-kselftest
In-Reply-To: <20260407022720.162151-1-jiayuan.chen@linux.dev>
When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg,
the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the
destination register in the !fullsock / !locked_tcp_sock path.
Both macros borrow a temporary register to check is_fullsock /
is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the
ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with
a request_sock), dst_reg should be zeroed but is not, leaving the stale
ctx pointer:
- SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks
as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer,
leading to stack-out-of-bounds access in helpers like
bpf_skc_to_tcp6_sock().
- SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the
verifier believes is a SCALAR_VALUE, leaking a kernel pointer.
Fix both macros by:
- Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the
added instruction.
- Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register
restore in the !fullsock path, placed after the restore because
dst_reg == src_reg means we need src_reg intact to read ctx->temp.
Fixes: fd09af010788 ("bpf: sock_ops ctx access may stomp registers in corner case")
Fixes: 84f44df664e9 ("bpf: sock_ops sk access may stomp registers when dst_reg = src_reg")
Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn>
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Closes: https://lore.kernel.org/bpf/6fe1243e-149b-4d3b-99c7-fcc9e2f75787@std.uestc.edu.cn/T/#u
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
net/core/filter.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 78b548158fb05..53ce06ed4a88e 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -10581,10 +10581,11 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type,
si->dst_reg, si->dst_reg, \
offsetof(OBJ, OBJ_FIELD)); \
if (si->dst_reg == si->src_reg) { \
- *insn++ = BPF_JMP_A(1); \
+ *insn++ = BPF_JMP_A(2); \
*insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg, \
offsetof(struct bpf_sock_ops_kern, \
temp)); \
+ *insn++ = BPF_MOV64_IMM(si->dst_reg, 0); \
} \
} while (0)
@@ -10618,10 +10619,11 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type,
si->dst_reg, si->src_reg, \
offsetof(struct bpf_sock_ops_kern, sk));\
if (si->dst_reg == si->src_reg) { \
- *insn++ = BPF_JMP_A(1); \
+ *insn++ = BPF_JMP_A(2); \
*insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg, \
offsetof(struct bpf_sock_ops_kern, \
temp)); \
+ *insn++ = BPF_MOV64_IMM(si->dst_reg, 0); \
} \
} while (0)
--
2.43.0
^ permalink raw reply related
* [PATCH bpf v3 2/2] selftests/bpf: Add tests for sock_ops ctx access with same src/dst register
From: Jiayuan Chen @ 2026-04-07 2:26 UTC (permalink / raw)
To: bpf
Cc: werner, Jiayuan Chen, Sun Jian, Martin KaFai Lau, Daniel Borkmann,
John Fastabend, Stanislav Fomichev, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan,
linux-kernel, netdev, linux-kselftest
In-Reply-To: <20260407022720.162151-1-jiayuan.chen@linux.dev>
Add selftests to verify SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() correctly
return NULL/zero when dst_reg == src_reg and is_fullsock == 0.
Three subtests are included:
- get_sk: ctx->sk with same src/dst register (SOCK_OPS_GET_SK)
- get_field: ctx->snd_cwnd with same src/dst register (SOCK_OPS_GET_FIELD)
- get_sk_diff_reg: ctx->sk with different src/dst register (baseline)
Each BPF program uses inline asm (__naked) to force specific register
allocation, reads is_fullsock first, then loads the field using the same
(or different) register. The test triggers TCP_NEW_SYN_RECV via a TCP
handshake and checks that the result is NULL/zero when is_fullsock == 0.
Reviewed-by: Sun Jian <sun.jian.kdev@gmail.com>
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
.../bpf/prog_tests/sock_ops_get_sk.c | 76 ++++++++++++
.../selftests/bpf/progs/sock_ops_get_sk.c | 117 ++++++++++++++++++
2 files changed, 193 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
create mode 100644 tools/testing/selftests/bpf/progs/sock_ops_get_sk.c
diff --git a/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c b/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
new file mode 100644
index 0000000000000..343d92c4df30d
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/sock_ops_get_sk.c
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <test_progs.h>
+#include "cgroup_helpers.h"
+#include "network_helpers.h"
+#include "sock_ops_get_sk.skel.h"
+
+/* See progs/sock_ops_get_sk.c for the bug description. */
+static void run_sock_ops_test(int cgroup_fd, int prog_fd)
+{
+ int server_fd, client_fd, err;
+
+ err = bpf_prog_attach(prog_fd, cgroup_fd, BPF_CGROUP_SOCK_OPS, 0);
+ if (!ASSERT_OK(err, "prog_attach"))
+ return;
+
+ server_fd = start_server(AF_INET, SOCK_STREAM, NULL, 0, 0);
+ if (!ASSERT_OK_FD(server_fd, "start_server"))
+ goto detach;
+
+ /* Trigger TCP handshake which causes TCP_NEW_SYN_RECV state where
+ * is_fullsock == 0 and is_locked_tcp_sock == 0.
+ */
+ client_fd = connect_to_fd(server_fd, 0);
+ if (!ASSERT_OK_FD(client_fd, "connect_to_fd"))
+ goto close_server;
+
+ close(client_fd);
+
+close_server:
+ close(server_fd);
+detach:
+ bpf_prog_detach(cgroup_fd, BPF_CGROUP_SOCK_OPS);
+}
+
+void test_ns_sock_ops_get_sk(void)
+{
+ struct sock_ops_get_sk *skel;
+ int cgroup_fd;
+
+ cgroup_fd = test__join_cgroup("/sock_ops_get_sk");
+ if (!ASSERT_OK_FD(cgroup_fd, "join_cgroup"))
+ return;
+
+ skel = sock_ops_get_sk__open_and_load();
+ if (!ASSERT_OK_PTR(skel, "skel_open_load"))
+ goto close_cgroup;
+
+ /* Test SOCK_OPS_GET_SK with same src/dst register */
+ if (test__start_subtest("get_sk")) {
+ run_sock_ops_test(cgroup_fd,
+ bpf_program__fd(skel->progs.sock_ops_get_sk_same_reg));
+ ASSERT_EQ(skel->bss->null_seen, 1, "null_seen");
+ ASSERT_EQ(skel->bss->bug_detected, 0, "bug_not_detected");
+ }
+
+ /* Test SOCK_OPS_GET_FIELD with same src/dst register */
+ if (test__start_subtest("get_field")) {
+ run_sock_ops_test(cgroup_fd,
+ bpf_program__fd(skel->progs.sock_ops_get_field_same_reg));
+ ASSERT_EQ(skel->bss->field_null_seen, 1, "field_null_seen");
+ ASSERT_EQ(skel->bss->field_bug_detected, 0, "field_bug_not_detected");
+ }
+
+ /* Test SOCK_OPS_GET_SK with different src/dst register */
+ if (test__start_subtest("get_sk_diff_reg")) {
+ run_sock_ops_test(cgroup_fd,
+ bpf_program__fd(skel->progs.sock_ops_get_sk_diff_reg));
+ ASSERT_EQ(skel->bss->diff_reg_null_seen, 1, "diff_reg_null_seen");
+ ASSERT_EQ(skel->bss->diff_reg_bug_detected, 0, "diff_reg_bug_not_detected");
+ }
+
+ sock_ops_get_sk__destroy(skel);
+close_cgroup:
+ close(cgroup_fd);
+}
diff --git a/tools/testing/selftests/bpf/progs/sock_ops_get_sk.c b/tools/testing/selftests/bpf/progs/sock_ops_get_sk.c
new file mode 100644
index 0000000000000..3a0689f8ce7ca
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/sock_ops_get_sk.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "vmlinux.h"
+#include <bpf/bpf_helpers.h>
+#include "bpf_misc.h"
+
+/*
+ * Test the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros in
+ * sock_ops_convert_ctx_access() when dst_reg == src_reg.
+ *
+ * When dst_reg == src_reg, the macros borrow a temporary register to load
+ * is_fullsock / is_locked_tcp_sock, because dst_reg holds the ctx pointer
+ * and cannot be clobbered before ctx->sk / ctx->field is read. If
+ * is_fullsock == 0 (e.g., TCP_NEW_SYN_RECV with a request_sock), the macro
+ * must still zero dst_reg so the verifier's PTR_TO_SOCKET_OR_NULL /
+ * SCALAR_VALUE type is correct at runtime. A missing clear leaves a stale
+ * ctx pointer in dst_reg that passes NULL checks (GET_SK) or leaks a kernel
+ * address as a scalar (GET_FIELD).
+ *
+ * When dst_reg != src_reg, dst_reg itself is used to load is_fullsock, so
+ * the JEQ (dst_reg == 0) naturally leaves it zeroed on the !fullsock path.
+ */
+
+int bug_detected;
+int null_seen;
+
+SEC("sockops")
+__naked void sock_ops_get_sk_same_reg(void)
+{
+ asm volatile (
+ "r7 = *(u32 *)(r1 + %[is_fullsock_off]);"
+ "r1 = *(u64 *)(r1 + %[sk_off]);"
+ "if r7 != 0 goto 2f;"
+ "if r1 == 0 goto 1f;"
+ "r1 = %[bug_detected] ll;"
+ "r2 = 1;"
+ "*(u32 *)(r1 + 0) = r2;"
+ "goto 2f;"
+ "1:"
+ "r1 = %[null_seen] ll;"
+ "r2 = 1;"
+ "*(u32 *)(r1 + 0) = r2;"
+ "2:"
+ "r0 = 1;"
+ "exit;"
+ :
+ : __imm_const(is_fullsock_off, offsetof(struct bpf_sock_ops, is_fullsock)),
+ __imm_const(sk_off, offsetof(struct bpf_sock_ops, sk)),
+ __imm_addr(bug_detected),
+ __imm_addr(null_seen)
+ : __clobber_all);
+}
+
+/* SOCK_OPS_GET_FIELD: same-register, is_locked_tcp_sock == 0 path. */
+int field_bug_detected;
+int field_null_seen;
+
+SEC("sockops")
+__naked void sock_ops_get_field_same_reg(void)
+{
+ asm volatile (
+ "r7 = *(u32 *)(r1 + %[is_fullsock_off]);"
+ "r1 = *(u32 *)(r1 + %[snd_cwnd_off]);"
+ "if r7 != 0 goto 2f;"
+ "if r1 == 0 goto 1f;"
+ "r1 = %[field_bug_detected] ll;"
+ "r2 = 1;"
+ "*(u32 *)(r1 + 0) = r2;"
+ "goto 2f;"
+ "1:"
+ "r1 = %[field_null_seen] ll;"
+ "r2 = 1;"
+ "*(u32 *)(r1 + 0) = r2;"
+ "2:"
+ "r0 = 1;"
+ "exit;"
+ :
+ : __imm_const(is_fullsock_off, offsetof(struct bpf_sock_ops, is_fullsock)),
+ __imm_const(snd_cwnd_off, offsetof(struct bpf_sock_ops, snd_cwnd)),
+ __imm_addr(field_bug_detected),
+ __imm_addr(field_null_seen)
+ : __clobber_all);
+}
+
+/* SOCK_OPS_GET_SK: different-register, is_fullsock == 0 path. */
+int diff_reg_bug_detected;
+int diff_reg_null_seen;
+
+SEC("sockops")
+__naked void sock_ops_get_sk_diff_reg(void)
+{
+ asm volatile (
+ "r7 = r1;"
+ "r6 = *(u32 *)(r7 + %[is_fullsock_off]);"
+ "r2 = *(u64 *)(r7 + %[sk_off]);"
+ "if r6 != 0 goto 2f;"
+ "if r2 == 0 goto 1f;"
+ "r1 = %[diff_reg_bug_detected] ll;"
+ "r3 = 1;"
+ "*(u32 *)(r1 + 0) = r3;"
+ "goto 2f;"
+ "1:"
+ "r1 = %[diff_reg_null_seen] ll;"
+ "r3 = 1;"
+ "*(u32 *)(r1 + 0) = r3;"
+ "2:"
+ "r0 = 1;"
+ "exit;"
+ :
+ : __imm_const(is_fullsock_off, offsetof(struct bpf_sock_ops, is_fullsock)),
+ __imm_const(sk_off, offsetof(struct bpf_sock_ops, sk)),
+ __imm_addr(diff_reg_bug_detected),
+ __imm_addr(diff_reg_null_seen)
+ : __clobber_all);
+}
+
+char _license[] SEC("license") = "GPL";
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] net/mlx5: Update the list of the PCI supported devices
From: patchwork-bot+netdevbpf @ 2026-04-07 2:30 UTC (permalink / raw)
To: Tariq Toukan
Cc: edumazet, kuba, pabeni, andrew+netdev, davem, saeedm, leon,
mbloch, netdev, linux-rdma, linux-kernel, gal, michaelgur, stable,
phaddad
In-Reply-To: <20260403091756.139583-1-tariqt@nvidia.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 3 Apr 2026 12:17:56 +0300 you wrote:
> From: Michael Guralnik <michaelgur@nvidia.com>
>
> Add the upcoming ConnectX-10 NVLink-C2C device ID to the table of
> supported PCI device IDs.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
> Reviewed-by: Patrisious Haddad <phaddad@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
>
> [...]
Here is the summary with links:
- [net-next] net/mlx5: Update the list of the PCI supported devices
https://git.kernel.org/netdev/net/c/a9d4f4f6e65e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [RFC net-next 0/4] selftests: drv-net: tso: add double tunneling GSO tests
From: Xu Du @ 2026-04-07 2:45 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, horms, shuah
Cc: netdev, linux-kselftest, linux-kernel
This series extends the TSO selftest (tso.py) to cover double-encapsulated
tunnel scenarios, ensuring that hardware offload and the kernel GSO path
correctly handle packets with two layers of tunnel headers.
Xu Du (4):
selftests: drv-net: tso: retry connect on EHOSTUNREACH
selftests: drv-net: tso: add helpers for double tunneling GSO
selftests: drv-net: tso: add Geneve double tunneling GSO test
selftests: drv-net: tso: expand double tunnel GSO test coverage
.../drivers/net/hw/lib/py/__init__.py | 4 +-
tools/testing/selftests/drivers/net/hw/tso.py | 267 +++++++++++++++---
.../selftests/drivers/net/lib/py/__init__.py | 4 +-
.../testing/selftests/net/lib/py/__init__.py | 4 +-
tools/testing/selftests/net/lib/py/utils.py | 19 +-
5 files changed, 248 insertions(+), 50 deletions(-)
base-commit: 2f60df9e61aa48bf40c36254bf2e839f09cffd98
--
2.53.0
^ permalink raw reply
* [RFC net-next 1/4] selftests: drv-net: tso: retry connect on EHOSTUNREACH
From: Xu Du @ 2026-04-07 2:45 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, horms, shuah
Cc: netdev, linux-kselftest, linux-kernel
In-Reply-To: <cover.1775527362.git.xudu@redhat.com>
The TSO test occasionally fails with "No route to host" (EHOSTUNREACH)
when connecting to the remote socat listener. This can happen when the
neighbor resolution has not yet completed by the time the test attempts
to connect, particularly in tunnel setups where neighbor entries may
take slightly longer to establish.
Add a retry loop (up to 5 attempts with 0.5s delay) around the
sock.connect() call to handle this transient condition gracefully.
Signed-off-by: Xu Du <xudu@redhat.com>
---
tools/testing/selftests/drivers/net/hw/tso.py | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/tso.py b/tools/testing/selftests/drivers/net/hw/tso.py
index bb675e3dac88..f792115adfb3 100755
--- a/tools/testing/selftests/drivers/net/hw/tso.py
+++ b/tools/testing/selftests/drivers/net/hw/tso.py
@@ -3,6 +3,7 @@
"""Run the tools/testing/selftests/net/csum testsuite."""
+import errno
import fcntl
import socket
import struct
@@ -47,10 +48,20 @@ def run_one_stream(cfg, ipver, remote_v4, remote_v6, should_lso):
if ipver == "4":
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
- sock.connect((remote_v4, port))
+ sockaddr = (remote_v4, port)
else:
sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
- sock.connect((remote_v6, port))
+ sockaddr = (remote_v6, port)
+
+ for attempt in range(5):
+ try:
+ sock.connect(sockaddr)
+ break
+ except OSError as e:
+ if e.errno == errno.EHOSTUNREACH and attempt < 4:
+ time.sleep(0.5)
+ else:
+ raise
# Small send to make sure the connection is working.
sock.send("ping".encode())
--
2.53.0
^ permalink raw reply related
* [RFC net-next 2/4] selftests: drv-net: tso: add helpers for double tunneling GSO
From: Xu Du @ 2026-04-07 2:45 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, horms, shuah
Cc: netdev, linux-kselftest, linux-kernel
In-Reply-To: <cover.1775527362.git.xudu@redhat.com>
Add helper functions to support double tunneling GSO testing. Since certain
tunnel-specific parameters (e.g., gro-hint) are not yet supported by the
standard ip-link tool, this patch adds a new helper function utilizing
the ynl-cli to handle these extended netlink attributes.
As the YNL Python module cannot be invoked across different devices or
environments directly in its current form, the helper abstracts the
YNL CLI calls to ensure proper configuration of the tunneling device
features.
Signed-off-by: Xu Du <xudu@redhat.com>
---
.../drivers/net/hw/lib/py/__init__.py | 4 ++--
.../selftests/drivers/net/lib/py/__init__.py | 4 ++--
.../testing/selftests/net/lib/py/__init__.py | 4 ++--
tools/testing/selftests/net/lib/py/utils.py | 19 +++++++++++++++++--
4 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/lib/py/__init__.py b/tools/testing/selftests/drivers/net/hw/lib/py/__init__.py
index df4da5078c48..34a06e1afcb5 100644
--- a/tools/testing/selftests/drivers/net/hw/lib/py/__init__.py
+++ b/tools/testing/selftests/drivers/net/hw/lib/py/__init__.py
@@ -24,7 +24,7 @@ try:
from net.lib.py import CmdExitFailure
from net.lib.py import bkg, cmd, bpftool, bpftrace, defer, ethtool, \
fd_read_timeout, ip, rand_port, rand_ports, wait_port_listen, \
- wait_file, tool
+ wait_file, tool, ynlcli
from net.lib.py import bpf_map_set, bpf_map_dump, bpf_prog_map_ids
from net.lib.py import KsftSkipEx, KsftFailEx, KsftXfailEx
from net.lib.py import ksft_disruptive, ksft_exit, ksft_pr, ksft_run, \
@@ -40,7 +40,7 @@ try:
"CmdExitFailure",
"bkg", "cmd", "bpftool", "bpftrace", "defer", "ethtool",
"fd_read_timeout", "ip", "rand_port", "rand_ports",
- "wait_port_listen", "wait_file", "tool",
+ "wait_port_listen", "wait_file", "tool", "ynlcli",
"bpf_map_set", "bpf_map_dump", "bpf_prog_map_ids",
"KsftSkipEx", "KsftFailEx", "KsftXfailEx",
"ksft_disruptive", "ksft_exit", "ksft_pr", "ksft_run",
diff --git a/tools/testing/selftests/drivers/net/lib/py/__init__.py b/tools/testing/selftests/drivers/net/lib/py/__init__.py
index 2b5ec0505672..a9eb1a57fcc4 100644
--- a/tools/testing/selftests/drivers/net/lib/py/__init__.py
+++ b/tools/testing/selftests/drivers/net/lib/py/__init__.py
@@ -22,7 +22,7 @@ try:
from net.lib.py import EthtoolFamily, NetdevFamily, NetshaperFamily, \
NlError, RtnlFamily, DevlinkFamily, PSPFamily, Netlink
from net.lib.py import CmdExitFailure
- from net.lib.py import bkg, cmd, bpftool, bpftrace, defer, ethtool, \
+ from net.lib.py import bkg, cmd, bpftool, bpftrace, defer, ethtool, ynlcli, \
fd_read_timeout, ip, rand_port, rand_ports, wait_port_listen, wait_file
from net.lib.py import bpf_map_set, bpf_map_dump, bpf_prog_map_ids
from net.lib.py import KsftSkipEx, KsftFailEx, KsftXfailEx
@@ -36,7 +36,7 @@ try:
"NlError", "RtnlFamily", "DevlinkFamily", "PSPFamily", "Netlink",
"CmdExitFailure",
"bkg", "cmd", "bpftool", "bpftrace", "defer", "ethtool",
- "fd_read_timeout", "ip", "rand_port", "rand_ports",
+ "fd_read_timeout", "ip", "rand_port", "rand_ports", "ynlcli",
"wait_port_listen", "wait_file",
"bpf_map_set", "bpf_map_dump", "bpf_prog_map_ids",
"KsftSkipEx", "KsftFailEx", "KsftXfailEx",
diff --git a/tools/testing/selftests/net/lib/py/__init__.py b/tools/testing/selftests/net/lib/py/__init__.py
index 7c81d86a7e97..a3337666a856 100644
--- a/tools/testing/selftests/net/lib/py/__init__.py
+++ b/tools/testing/selftests/net/lib/py/__init__.py
@@ -14,7 +14,7 @@ from .netns import NetNS, NetNSEnter
from .nsim import NetdevSim, NetdevSimDev
from .utils import CmdExitFailure, fd_read_timeout, cmd, bkg, defer, \
bpftool, ip, ethtool, bpftrace, rand_port, rand_ports, wait_port_listen, \
- wait_file, tool
+ wait_file, tool, ynlcli
from .bpf import bpf_map_set, bpf_map_dump, bpf_prog_map_ids
from .ynl import NlError, NlctrlFamily, YnlFamily, \
EthtoolFamily, NetdevFamily, RtnlFamily, RtnlAddrFamily
@@ -29,7 +29,7 @@ __all__ = ["KSRC",
"NetNS", "NetNSEnter",
"CmdExitFailure", "fd_read_timeout", "cmd", "bkg", "defer",
"bpftool", "ip", "ethtool", "bpftrace", "rand_port", "rand_ports",
- "wait_port_listen", "wait_file", "tool",
+ "wait_port_listen", "wait_file", "tool", "ynlcli",
"bpf_map_set", "bpf_map_dump", "bpf_prog_map_ids",
"NetdevSim", "NetdevSimDev",
"NetshaperFamily", "DevlinkFamily", "PSPFamily", "NlError",
diff --git a/tools/testing/selftests/net/lib/py/utils.py b/tools/testing/selftests/net/lib/py/utils.py
index 6c44a3d2bbf7..a14a4b5dd592 100644
--- a/tools/testing/selftests/net/lib/py/utils.py
+++ b/tools/testing/selftests/net/lib/py/utils.py
@@ -8,6 +8,8 @@ import socket
import subprocess
import time
+from .consts import KSRC, KSFT_DIR
+
class CmdInitFailure(Exception):
""" Command failed to start. Only raised by bkg(). """
@@ -217,12 +219,12 @@ class defer:
self.exec_only()
-def tool(name, args, json=None, ns=None, host=None):
+def tool(name, args, json=None, ns=None, host=None, shell=None):
cmd_str = name + ' '
if json:
cmd_str += '--json '
cmd_str += args
- cmd_obj = cmd(cmd_str, ns=ns, host=host)
+ cmd_obj = cmd(cmd_str, ns=ns, host=host, shell=shell)
if json:
return _json.loads(cmd_obj.stdout)
return cmd_obj
@@ -242,6 +244,19 @@ def ethtool(args, json=None, ns=None, host=None):
return tool('ethtool', args, json=json, ns=ns, host=host)
+def ynlcli(family, args, json=None, ns=None, host=None):
+ if (KSFT_DIR / "kselftest-list.txt").exists():
+ cli = KSFT_DIR / "net/lib/ynl/pyynl/cli.py"
+ spec = KSFT_DIR / f"net/lib/specs/{family}.yaml"
+ else:
+ cli = KSRC / "tools/net/ynl/pyynl/cli.py"
+ spec = KSRC / f"Documentation/netlink/specs/{family}.yaml"
+ if not cli.exists():
+ raise FileNotFoundError(f"cli not found at {cli}")
+ args = f"--spec {spec} --no-schema {args}"
+ return tool(cli.as_posix(), args, json=json, ns=ns, host=host, shell=True)
+
+
def bpftrace(expr, json=None, ns=None, host=None, timeout=None):
"""
Run bpftrace and return map data (if json=True).
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox