* Re: [PATCH v2 0/3] bpf: fix sock_ops rtt_min OOB read and related guard issues
From: patchwork-bot+netdevbpf @ 2026-04-12 19:40 UTC (permalink / raw)
To: Werner Kasselman
Cc: martin.lau, ast, daniel, andrii, john.fastabend, brakmo, eddyz87,
song, yonghong.song, kpsingh, sdf, haoluo, jolsa, davem, edumazet,
kuba, pabeni, horms, bpf, netdev, linux-kernel
In-Reply-To: <20260412030306.3469543-1-werner@verivus.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 12 Apr 2026 03:03:08 +0000 you wrote:
> Patch 3 fixes an out-of-bounds read in sock_ops_convert_ctx_access()
> for the rtt_min context field. It is the only tcp_sock-backed field
> that bypasses the is_locked_tcp_sock guard, so on request_sock-backed
> sock_ops callbacks the converted BPF load reads past the end of a
> tcp_request_sock.
>
> Patches 1 and 2 are groundwork. Patch 1 fixes a pre-existing info
> leak in SOCK_OPS_GET_FIELD() and SOCK_OPS_GET_SK() where dst_reg is
> left holding the context pointer on the guard-failure branch when
> dst_reg == src_reg, instead of being zeroed. Patch 2 extracts
> SOCK_OPS_LOAD_TCP_SOCK_FIELD() from SOCK_OPS_GET_FIELD() so the
> rtt_min sub-field access in patch 3 can reuse it.
>
> [...]
Here is the summary with links:
- [v2,1/3] bpf: zero dst_reg on sock_ops field guard failure when dst == src
https://git.kernel.org/netdev/net/c/10f86a2a5c91
- [v2,2/3] bpf: extract SOCK_OPS_LOAD_TCP_SOCK_FIELD from SOCK_OPS_GET_FIELD
(no matching commit)
- [v2,3/3] bpf: guard sock_ops rtt_min against non-locked tcp_sock
(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 bpf v3 0/2] bpf: Fix SOCK_OPS_GET_SK same-register OOB read in sock_ops and add selftest
From: patchwork-bot+netdevbpf @ 2026-04-12 19:40 UTC (permalink / raw)
To: Jiayuan Chen
Cc: bpf, werner, martin.lau, daniel, john.fastabend, sdf, ast, andrii,
eddyz87, memxor, song, yonghong.song, jolsa, davem, edumazet,
kuba, pabeni, horms, shuah, sun.jian.kdev, linux-kernel, netdev,
linux-kselftest
In-Reply-To: <20260407022720.162151-1-jiayuan.chen@linux.dev>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 7 Apr 2026 10:26:26 +0800 you wrote:
> 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.
>
> [...]
Here is the summary with links:
- [bpf,v3,1/2] bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops
https://git.kernel.org/netdev/net/c/10f86a2a5c91
- [bpf,v3,2/2] selftests/bpf: Add tests for sock_ops ctx access with same src/dst register
https://git.kernel.org/netdev/net/c/04013c3ca022
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 v2 net] openvswitch: fix vport netlink reply size for large upcall PID arrays
From: Ilya Maximets @ 2026-04-12 19:33 UTC (permalink / raw)
To: Weiming Shi, Aaron Conole, Eelco Chaudron
Cc: i.maximets, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Flavio Leitner, Mark Gray, netdev,
Xiang Mei, sunichi, ovs dev
In-Reply-To: <20260411141448.1479933-3-bestswngs@gmail.com>
On 4/11/26 4:14 PM, Weiming Shi wrote:
> The vport netlink reply helpers allocate a fixed-size skb with
> nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
> array via ovs_vport_get_upcall_portids(). Since
> ovs_vport_set_upcall_portids() accepts any non-zero multiple of
> sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
> array large enough to overflow the reply buffer. On systems with
> unprivileged user namespaces enabled (e.g., Ubuntu default), this is
> reachable via unshare -Urn since all OVS vport genl operations use
> GENL_UNS_ADMIN_PERM.
>
> When the subsequent nla_put() fails with -EMSGSIZE, five BUG_ON(err < 0)
> sites fire and panic the kernel:
>
> kernel BUG at net/openvswitch/datapath.c:2414!
> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1
> RIP: 0010:ovs_vport_cmd_set+0x34c/0x400
> Call Trace:
> <TASK>
> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)
> genl_rcv_msg (net/netlink/genetlink.c:1194)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> genl_rcv (net/netlink/genetlink.c:1219)
> netlink_unicast (net/netlink/af_netlink.c:1344)
> netlink_sendmsg (net/netlink/af_netlink.c:1894)
> __sys_sendto (net/socket.c:2206)
> __x64_sys_sendto (net/socket.c:2209)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
> Kernel panic - not syncing: Fatal exception
>
> Fix this by dynamically sizing the reply skb to account for the actual
> PID array length, and replace the BUG_ON() calls with graceful error
> returns.
Hi, Weiming. Thanks for working on this! The earlier attempt to fix this
problem was here:
https://lore.kernel.org/netdev/20260323071435.1945543-1-sunyiqixm@gmail.com/
CC: sunichi, maybe you can cooperate on the fix somehow.
A few problems with the solution here:
- You're locking to count the number of pids, then unlocking and then
re-locking to fill the output. This is racy and may still cause the
inability to put all the data into allocated space, since the number can
theoretically change.
- Failing the del command is very unfriendly to the userspace and also it
becomes impossible for the user to delete the port without clearing the
upcall pids first, which they will not know to do.
- Failing the new command as done in this change is very confusing as the
port is actually created while the user gets the error.
- NLMSG_DEFAULT_SIZE + portids_size is not the actual size of the message,
nothing in the code guarantees that the rest fits into NLMSG_DEFAULT_SIZE.
- The number of pids being unbounded is a problem in itself.
So, we need to approach this issue differently. As I suggested in the thread
linked above, we should limit the maximum number of the pid to the number of
CPUs, as it is done for the per-cpu dispatch socket array. There is no point
in more sockets than CPUs and the userspace never creates that many. This way
we can:
- Fail the attempts to set up more pids than CPUs in the first place.
- Know beforehand the maximum size to allocate - no need to check the actual
number and re-lock. Create a function similar to ovs_dp_cmd_msg_size()
to allocate based on what can be included in the worst case, which shouldn't
be a lot.
And all the BUG_ON() calls must remain BUG_ON()s as it is a bug if we're not
counting correctly.
> Fixes: b83d23a2a38b ("openvswitch: Introduce per-cpu upcall dispatch")
This is not the right commit. The change you're making has nothing to do with
the per-cpu dispatch. The actual commit you're looking for is much older:
5cd667b0a456 ("openvswitch: Allow each vport to have an array of 'port_id's.")
Couple more notes:
- Wait at least 24 hours between versions. Otherwise, people have no enough
time to look at your patch.
- Please, CC all maintainers including the ovs-dev list. It is moderated for
new senders (the only reliable way to keep it out of spam) but we approve
fast, so your next emails should go right through.
Best regards, Ilya Maximets.
^ permalink raw reply
* Re: [RFC net-next v5 0/3] Add RSS and LRO support
From: Frank Wunderlich @ 2026-04-12 19:24 UTC (permalink / raw)
To: Jakub Kicinski, Frank Wunderlich
Cc: linux, nbd, sean.wang, lorenzo, andrew+netdev, davem, edumazet,
pabeni, matthias.bgg, angelogioacchino.delregno, linux, daniel,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260412075402.2eda04d3@kernel.org>
Am 12. April 2026 um 16:54 schrieb "Jakub Kicinski" <kuba@kernel.org>:
>
> On Sun, 12 Apr 2026 11:57:47 +0000 Frank Wunderlich wrote:
>
> >
> > some time has passed without a single comment, so i just send a friendly reminder ;)
> >
> You have a lot of people in the To:
> Could you clarify who you expect to action these patches?
> Patches are an RFC and I suppose ain't nobody got much comments?
Hi,
imho 11 people are in "To" is not much, but i was told that no comments can mean
"OK so far" so i will send v6 soon rebased on current net-next.
regards Frank
^ permalink raw reply
* Re: [PATCH net-next v6 3/7] net: bcmgenet: add basic XDP support (PASS/DROP)
From: Jakub Kicinski @ 2026-04-12 19:22 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: netdev, Justin Chen, Simon Horman, Mohsin Bashir, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, Eric Dumazet, Paolo Abeni, David S. Miller,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, linux-kernel, bpf
In-Reply-To: <20260406083536.839517-4-nb@tipi-net.de>
On Mon, 6 Apr 2026 10:35:27 +0200 Nicolai Buchwitz wrote:
> Add XDP program attachment via ndo_bpf and execute XDP programs in the
> RX path. XDP_PASS builds an SKB from the xdp_buff (handling
> xdp_adjust_head/tail), XDP_DROP returns the page to page_pool without
> SKB allocation.
>
> XDP_TX and XDP_REDIRECT are not yet supported and return XDP_ABORTED.
>
> Advertise NETDEV_XDP_ACT_BASIC in xdp_features.
> - skb_mark_for_recycle(skb);
> -
> - /* Reserve the RSB + pad, then set the data length */
> - skb_reserve(skb, GENET_RSB_PAD);
> - __skb_put(skb, len - GENET_RSB_PAD);
> + {
floating code blocks are considered poor coding style in the kernel
Why not push the variables up into the outer scope or make this
a helper?
> + struct xdp_buff xdp;
> + unsigned int xdp_act;
> + int pkt_len;
> +
> + pkt_len = len - GENET_RSB_PAD;
> + if (priv->crc_fwd_en)
> + pkt_len -= ETH_FCS_LEN;
> +
> + /* Save rx_csum before XDP runs - an XDP program
> + * could overwrite the RSB via bpf_xdp_adjust_head.
> + */
> + if (dev->features & NETIF_F_RXCSUM)
> + rx_csum = (__force __be16)(status->rx_csum
> + & 0xffff);
FWIW this could be before the block
> + xdp_init_buff(&xdp, PAGE_SIZE, &ring->xdp_rxq);
> + xdp_prepare_buff(&xdp, page_address(rx_page),
> + GENET_RX_HEADROOM, pkt_len, true);
> +
> + if (xdp_prog) {
> + xdp_act = bcmgenet_run_xdp(ring, xdp_prog,
> + &xdp, rx_page);
Since you pass the xdp_prog in you can save yourself the indentation by
making bcmgenet_run_xdp() return PASS when no program is set.
bcmgenet_run_xdp() has one caller, it's going to get inlined.
> + if (xdp_act != XDP_PASS)
> + goto next;
> + }
>
> - if (priv->crc_fwd_en) {
> - skb_trim(skb, skb->len - ETH_FCS_LEN);
> + skb = bcmgenet_xdp_build_skb(ring, &xdp);
> + if (unlikely(!skb)) {
> + BCMGENET_STATS64_INC(stats, dropped);
> + page_pool_put_full_page(ring->page_pool,
> + rx_page, true);
> + goto next;
> + }
> }
>
> /* Set up checksum offload */
> if (dev->features & NETIF_F_RXCSUM) {
> - rx_csum = (__force __be16)(status->rx_csum & 0xffff);
> if (rx_csum) {
> skb->csum = (__force __wsum)ntohs(rx_csum);
> skb->ip_summed = CHECKSUM_COMPLETE;
> @@ -3744,6 +3810,37 @@ static int bcmgenet_change_carrier(struct net_device *dev, bool new_carrier)
> return 0;
> }
>
> +static int bcmgenet_xdp_setup(struct net_device *dev,
> + struct netdev_bpf *xdp)
> +{
> + struct bcmgenet_priv *priv = netdev_priv(dev);
> + struct bpf_prog *old_prog;
> + struct bpf_prog *prog = xdp->prog;
> +
> + if (prog && dev->mtu > PAGE_SIZE - GENET_RX_HEADROOM -
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) {
I'm confused by this check, it appears that the max page size this
driver can Rx in the first place is 2kB (RX_BUF_LENGTH). And max_mtu
is 1.5kB.
If GENET_RX_HEADROOM + SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
is larger than 2kB the Rx path will break completely whether XDP was
attached or not.
This check seems to be cargo culting what other drivers do?
^ permalink raw reply
* Re: [PATCH net-next v6 1/7] net: bcmgenet: convert RX path to page_pool
From: Jakub Kicinski @ 2026-04-12 19:10 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: netdev, Justin Chen, Simon Horman, Mohsin Bashir, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, Eric Dumazet, Paolo Abeni, David S. Miller,
Vikas Gupta, Bhargava Marreddy, Rajashekar Hudumula,
Arnd Bergmann, Fernando Fernandez Mancera, Markus Blöchl,
linux-kernel
In-Reply-To: <20260406083536.839517-2-nb@tipi-net.de>
On Mon, 6 Apr 2026 10:35:25 +0200 Nicolai Buchwitz wrote:
> Replace the per-packet __netdev_alloc_skb() + dma_map_single() in the
> RX path with page_pool, which provides efficient page recycling and
> DMA mapping management. This is a prerequisite for XDP support (which
> requires stable page-backed buffers rather than SKB linear data).
>
> Key changes:
> - Create a page_pool per RX ring (PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV)
> - bcmgenet_rx_refill() allocates pages via page_pool_alloc_pages()
> - bcmgenet_desc_rx() builds SKBs from pages via napi_build_skb() with
> skb_mark_for_recycle() for automatic page_pool return
> - Buffer layout reserves XDP_PACKET_HEADROOM (256 bytes) before the HW
> RSB (64 bytes) + alignment pad (2 bytes) for future XDP headroom
some nits here, since I have more "real" comments on later patches
> +/* Page pool RX buffer layout:
> + * XDP_PACKET_HEADROOM | RSB(64) + pad(2) | frame data | skb_shared_info
> + * The HW writes the 64B RSB + 2B alignment padding before the frame.
> + */
> +#define GENET_XDP_HEADROOM XDP_PACKET_HEADROOM
subjective but IDK what value this define adds vs using
XDP_PACKET_HEADROOM directly.
> +#define GENET_RSB_PAD (sizeof(struct status_64) + 2)
> +#define GENET_RX_HEADROOM (GENET_XDP_HEADROOM + GENET_RSB_PAD)
> +static int bcmgenet_rx_refill(struct bcmgenet_rx_ring *ring,
> + struct enet_cb *cb)
> {
> - struct device *kdev = &priv->pdev->dev;
> - struct sk_buff *skb;
> - struct sk_buff *rx_skb;
> + struct bcmgenet_priv *priv = ring->priv;
> dma_addr_t mapping;
> + struct page *page;
>
> - /* Allocate a new Rx skb */
> - skb = __netdev_alloc_skb(priv->dev, priv->rx_buf_len + SKB_ALIGNMENT,
> - GFP_ATOMIC | __GFP_NOWARN);
page pool adds __GFP_NOWARN automatically, you can drop it now
> - if (!skb) {
> + page = page_pool_alloc_pages(ring->page_pool,
> + GFP_ATOMIC | __GFP_NOWARN);
> + if (!page) {
> priv->mib.alloc_rx_buff_failed++;
> netif_err(priv, rx_err, priv->dev,
> - "%s: Rx skb allocation failed\n", __func__);
> - return NULL;
> - }
^ permalink raw reply
* Re: [PATCH net-next 00/11] netfilter: updates for net-next
From: Pablo Neira Ayuso @ 2026-04-12 18:58 UTC (permalink / raw)
To: Florian Westphal
Cc: Jakub Kicinski, netdev, Paolo Abeni, David S. Miller,
Eric Dumazet, netfilter-devel
In-Reply-To: <advTosG9qZ_ZW355@strlen.de>
On Sun, Apr 12, 2026 at 07:17:22PM +0200, Florian Westphal wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > Jakub Kicinski <kuba@kernel.org> wrote:
> > https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de
>
> Forgot to mention this:
>
> ---------------
> AF_PACKET raw sockets or tun devices, the network_header might be
> uninitialized (~0U). In this state, skb_mac_header_len() will evaluate to
> a very large number, bypassing the ETH_HLEN check completely.
> ---------------
>
> Really? TIL.
>
> ---------------------
> Furthermore, skb_mac_header_len() only verifies the logical distance between
> header offsets, rather than ensuring the bytes are actually present in the
> physical linear buffer.
>
> ---------------
>
> Really? Total news to me :-(
No problem, taking a look into this.
^ permalink raw reply
* Re: [PATCH net 1/2] NFC: digital: Bounds check NFC-A cascade depth in SDD response handler
From: patchwork-bot+netdevbpf @ 2026-04-12 18:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, linux-kernel, davem, edumazet, kuba, pabeni, horms, kees,
thierry.escande, sameo, stable
In-Reply-To: <2026040913-figure-seducing-bd3f@gregkh>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 17:18:14 +0200 you wrote:
> The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3
> or 4 bytes to target->nfcid1 on each round, but the number of cascade
> rounds is controlled entirely by the peer device. The peer sets the
> cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the
> cascade-incomplete bit in the SEL_RES (deciding whether another round
> follows).
>
> [...]
Here is the summary with links:
- [net,1/2] NFC: digital: Bounds check NFC-A cascade depth in SDD response handler
https://git.kernel.org/netdev/net/c/46ce8be2ced3
- [net,2/2] NFC: digital: Bounds check Felica response before sensf_res memcpy
(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 v2] net_sched: fix skb memory leak in deferred qdisc drops
From: patchwork-bot+netdevbpf @ 2026-04-12 18:50 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, edumazet, davem, damilola
In-Reply-To: <20260408100044.4530-1-fmancera@suse.de>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 12:00:44 +0200 you wrote:
> When the network stack cleans up the deferred list via qdisc_run_end(),
> it operates on the root qdisc. If the root qdisc do not implement the
> TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and
> gets stranded on the child's local to_free list.
>
> Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It
> fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If
> the flag is present, the packet is appended directly to the root's
> to_free list. Otherwise, drop it directly as it was done before the
> optimization was implemented.
>
> [...]
Here is the summary with links:
- [net,v2] net_sched: fix skb memory leak in deferred qdisc drops
https://git.kernel.org/netdev/net/c/a6bd339dbb35
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 2/2] NFC: digital: Bounds check Felica response before sensf_res memcpy
From: Jakub Kicinski @ 2026-04-12 18:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, linux-kernel, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Kees Cook, Thierry Escande, Samuel Ortiz, stable
In-Reply-To: <2026040913-rearrange-unseeing-fa85@gregkh>
On Thu, 9 Apr 2026 17:18:15 +0200 Greg Kroah-Hartman wrote:
> A malicious NFC peer can send a SENSF_RES that is longer than the
> NFC_SENSF_RES_MAXSIZE (18 byte) sensf_res field in the onstack struct
> nfc_target. digital_in_recv_sensf_res() validates that the response is
> at least DIGITAL_SENSF_RES_MIN_LENGTH bytes but applies no upper bound
> before memcpy(target.sensf_res, sensf_res, resp->len) is called,
> allowing a stack buffer overflow with attacker-controlled length and
> content.
>
> Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays")
> fixed identical missing checks for the same target->sensf_res field on
> the NCI path; the Digital Protocol path was never patched.
>
> Fix this all up by just rejecting responses that exceed
> NFC_SENSF_RES_MAXSIZE.
This driver's local definition of the sensf_res struct seems to
be larger than NFC_SENSF_RES_MAXSIZE. Something is off here.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] ynl/ethtool/netlink: fix nla_len overflow for large string sets
From: patchwork-bot+netdevbpf @ 2026-04-12 18:40 UTC (permalink / raw)
To: Hangbin Liu
Cc: donald.hunter, kuba, davem, edumazet, pabeni, horms, andrew,
netdev, linux-kernel
In-Reply-To: <20260408-b4-ynl_ethtool-v2-0-7623a5e8f70b@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 15:08:48 +0800 you wrote:
> This series addresses a silent data corruption issue triggered when ynl
> retrieves string sets from NICs with a large number of statistics entries
> (e.g. mlx5_core with thousands of ETH_SS_STATS strings).
>
> The root cause is that struct nlattr.nla_len is a __u16 (max 65535
> bytes). When a NIC exports enough statistics strings, the
> ETHTOOL_A_STRINGSET_STRINGS nest built by strset_fill_set() exceeds
> this limit. nla_nest_end() silently truncates the length on assignment,
> producing a corrupted netlink message.
>
> [...]
Here is the summary with links:
- [net-next,v2,1/5] tools: ynl: move ethtool.py to selftest
https://git.kernel.org/netdev/net-next/c/22ef8a263c17
- [net-next,v2,2/5] tools: ynl: ethtool: use doit instead of dumpit for per-device GET
https://git.kernel.org/netdev/net-next/c/1c43d471a513
- [net-next,v2,3/5] tools: ynl: ethtool: add --dbg-small-recv option
https://git.kernel.org/netdev/net-next/c/594ba4477164
- [net-next,v2,4/5] netlink: add a nla_nest_end_safe() helper
https://git.kernel.org/netdev/net-next/c/1346586a9ac9
- [net-next,v2,5/5] ethtool: strset: check nla_len overflow
https://git.kernel.org/netdev/net-next/c/b2fb1a336383
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue()
From: patchwork-bot+netdevbpf @ 2026-04-12 18:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260408-airoha-cpu-idx-airoha_qdma_cleanup_rx_queue-v1-1-8efa64844308@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 20:26:56 +0200 you wrote:
> When the descriptor index written in REG_RX_CPU_IDX() is equal to the one
> stored in REG_RX_DMA_IDX(), the hw will stop since the QDMA RX ring is
> empty.
> Add missing REG_RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue
> routine during QDMA RX ring cleanup.
>
> Fixes: 514aac359987 ("net: airoha: Add missing cleanup bits in airoha_qdma_cleanup_rx_queue()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add missing RX_CPU_IDX() configuration in airoha_qdma_cleanup_rx_queue()
https://git.kernel.org/netdev/net/c/656121b15503
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 0/2] net: mana: Fix debugfs directory naming and file lifecycle
From: patchwork-bot+netdevbpf @ 2026-04-12 18:40 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ssengar, dipayanroy, gargaditya,
shradhagupta, kees, kotaranov, yury.norov, linux-hyperv, netdev,
linux-kernel
In-Reply-To: <20260408081224.302308-1-ernis@linux.microsoft.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 01:12:18 -0700 you wrote:
> This series fixes two pre-existing debugfs issues in the MANA driver.
>
> Patch 1 fixes the per-device debugfs directory naming to use the unique
> PCI BDF address via pci_name(), avoiding a potential NULL pointer
> dereference when pdev->slot is NULL (e.g. VFIO passthrough, nested KVM)
> and preventing name collisions across multiple PFs or VFs.
>
> [...]
Here is the summary with links:
- [net,1/2] net: mana: Use pci_name() for debugfs directory naming
https://git.kernel.org/netdev/net/c/c116f07ab9d2
- [net,2/2] net: mana: Move current_speed debugfs file to mana_init_port()
https://git.kernel.org/netdev/net/c/3b7c7fc97aea
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/3] net: phy: add support for disabling autonomous EEE
From: Jakub Kicinski @ 2026-04-12 18:35 UTC (permalink / raw)
To: Andrew Lunn, Russell King, Florian Fainelli
Cc: Nicolai Buchwitz, Heiner Kallweit, David S. Miller, Eric Dumazet,
Paolo Abeni, Broadcom internal kernel review list, netdev,
linux-kernel
In-Reply-To: <20260406-devel-autonomous-eee-v1-0-b335e7143711@tipi-net.de>
On Mon, 06 Apr 2026 09:13:06 +0200 Nicolai Buchwitz wrote:
> Some PHYs implement autonomous EEE where the PHY manages EEE
> independently, preventing the MAC from controlling LPI signaling.
> This conflicts with MACs that implement their own LPI control.
AFAIU the discussion that followed was about.. future work?
So this series is good as is. Applied, please LMK if I misread,
I'll drop it.
^ permalink raw reply
* Re: [PATCH net] nfc: llcp: add missing return after LLCP_CLOSED checks
From: patchwork-bot+netdevbpf @ 2026-04-12 18:30 UTC (permalink / raw)
To: Junxi Qian; +Cc: netdev, davem, edumazet, kuba, pabeni, horms
In-Reply-To: <20260408081006.3723-1-qjx1298677004@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 16:10:06 +0800 you wrote:
> In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket
> state is LLCP_CLOSED, the code correctly calls release_sock() and
> nfc_llcp_sock_put() but fails to return. Execution falls through to
> the remainder of the function, which calls release_sock() and
> nfc_llcp_sock_put() again. This results in a double release_sock()
> and a refcount underflow via double nfc_llcp_sock_put(), leading to
> a use-after-free.
>
> [...]
Here is the summary with links:
- [net] nfc: llcp: add missing return after LLCP_CLOSED checks
https://git.kernel.org/netdev/net/c/2b5dd4632966
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: check qdisc_pkt_len_segs_init() return value on ingress
From: Jakub Kicinski @ 2026-04-12 18:21 UTC (permalink / raw)
To: David Carlier
Cc: davem, edumazet, pabeni, horms, sdf, kuniyu, skhawaja, liuhangbin,
krikku, netdev, linux-kernel
In-Reply-To: <20260408172307.172736-1-devnexen@gmail.com>
On Wed, 8 Apr 2026 18:23:07 +0100 David Carlier wrote:
> Commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> changed qdisc_pkt_len_segs_init() to return an skb drop reason when
> it detects malicious GSO packets. The egress path in __dev_queue_xmit()
> checks this return value and drops bad packets, but the ingress path in
> sch_handle_ingress() ignores it.
>
> This means malformed GSO packets entering via TC ingress are not dropped
> and could be redirected to another interface or cause incorrect qdisc
> accounting.
>
> Check the return value and drop the packet when a bad GSO is detected.
>
> Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> Signed-off-by: David Carlier <devnexen@gmail.com>
Not sure this can happen today, but okay.
Hopefully we won't get a patch for every Sashiko report we knowingly
ignored :|
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5a31f9d2128c..2b5f508fc479 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4459,7 +4459,7 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
> struct net_device *orig_dev, bool *another)
> {
> struct bpf_mprog_entry *entry = rcu_dereference_bh(skb->dev->tcx_ingress);
> - enum skb_drop_reason drop_reason = SKB_DROP_REASON_TC_INGRESS;
> + enum skb_drop_reason drop_reason;
this needs to move one line down now to keep the variable ordering.
> struct bpf_net_context __bpf_net_ctx, *bpf_net_ctx;
> int sch_ret;
>
> @@ -4472,7 +4472,15 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
> *pt_prev = NULL;
> }
>
> - qdisc_pkt_len_segs_init(skb);
> + drop_reason = qdisc_pkt_len_segs_init(skb);
> + if (unlikely(drop_reason)) {
> + kfree_skb_reason(skb, drop_reason);
> + *ret = NET_RX_DROP;
> + bpf_net_ctx_clear(bpf_net_ctx);
> + return NULL;
> + }
> +
> + drop_reason = SKB_DROP_REASON_TC_INGRESS;
> tcx_set_ingress(skb, true);
>
> if (static_branch_unlikely(&tcx_needed_key)) {
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v12 00/10] bng_en: add link management and statistics support
From: patchwork-bot+netdevbpf @ 2026-04-12 18:20 UTC (permalink / raw)
To: Bhargava Marreddy
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, horms, netdev,
linux-kernel, michael.chan, pavan.chebbi, vsrama-krishna.nemani,
vikas.gupta
In-Reply-To: <20260406180420.279470-1-bhargava.marreddy@broadcom.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 6 Apr 2026 23:34:10 +0530 you wrote:
> Hi,
>
> This series enhances the bng_en driver by adding:
> 1. Link/PHY support
> a. Link query
> b. Async Link events
> c. Ethtool link set/get functionality
> 2. Hardware statistics reporting via ethtool -S
>
> [...]
Here is the summary with links:
- [net-next,v12,01/10] bng_en: add per-PF workqueue, timer, and slow-path task
https://git.kernel.org/netdev/net-next/c/2095da234017
- [net-next,v12,02/10] bng_en: query PHY capabilities and report link status
https://git.kernel.org/netdev/net-next/c/7626cd3d53be
- [net-next,v12,03/10] bng_en: add ethtool link settings, get_link, and nway_reset
https://git.kernel.org/netdev/net-next/c/169f6e8dd149
- [net-next,v12,04/10] bng_en: implement ethtool pauseparam operations
https://git.kernel.org/netdev/net-next/c/dc85e8a51f5a
- [net-next,v12,05/10] bng_en: add support for link async events
https://git.kernel.org/netdev/net-next/c/4a75900989c9
- [net-next,v12,06/10] bng_en: add HW stats infra and structured ethtool ops
https://git.kernel.org/netdev/net-next/c/8438239bd2b2
- [net-next,v12,07/10] bng_en: periodically fetch and accumulate hardware statistics
https://git.kernel.org/netdev/net-next/c/50c885cb2ebe
- [net-next,v12,08/10] bng_en: implement ndo_get_stats64
https://git.kernel.org/netdev/net-next/c/d4f802eb4e7d
- [net-next,v12,09/10] bng_en: implement netdev_stat_ops
https://git.kernel.org/netdev/net-next/c/c1da271f0d35
- [net-next,v12,10/10] bng_en: add support for ethtool -S stats display
https://git.kernel.org/netdev/net-next/c/bcc0f4c0f257
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] sctp: disable BH before calling udp_tunnel_xmit_skb()
From: Xin Long @ 2026-04-12 18:15 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, kuba, Eric Dumazet, Paolo Abeni, Simon Horman,
Marcelo Ricardo Leitner, Weiming Shi
udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with
BH disabled. After commit 6f1a9140ecda ("add xmit recursion limit to
tunnel xmit functions"), on the path:
udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit()
dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU.
Without local_bh_disable(), the context may move between CPUs, which can
break the inc/dec pairing. This may lead to incorrect recursion level
detection and cause packets to be dropped in ip(6)_tunnel_xmit() or
__dev_queue_xmit().
Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths.
In my testing, after enabling the SCTP over UDP:
# ip net exec ha sysctl -w net.sctp.udp_port=9899
# ip net exec ha sysctl -w net.sctp.encap_port=9899
# ip net exec hb sysctl -w net.sctp.udp_port=9899
# ip net exec hb sysctl -w net.sctp.encap_port=9899
# ip net exec ha iperf3 -s
- without this patch:
# ip net exec hb iperf3 -c 192.168.0.1 --sctp
[ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender
[ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver
- with this patch:
# ip net exec hb iperf3 -c 192.168.0.1 --sctp
[ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender
[ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver
Fixes: 6f1a9140ecda ("add xmit recursion limit to tunnel xmit functions")
Fixes: 046c052b475e ("sctp: enable udp tunneling socks")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/ipv6.c | 2 ++
net/sctp/protocol.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 53a5c027f8e3..cd15b695607e 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -261,9 +261,11 @@ static int sctp_v6_xmit(struct sk_buff *skb, struct sctp_transport *t)
skb_set_inner_ipproto(skb, IPPROTO_SCTP);
label = ip6_make_flowlabel(sock_net(sk), skb, fl6->flowlabel, true, fl6);
+ local_bh_disable();
udp_tunnel6_xmit_skb(dst, sk, skb, NULL, &fl6->saddr, &fl6->daddr,
tclass, ip6_dst_hoplimit(dst), label,
sctp_sk(sk)->udp_port, t->encap_port, false, 0);
+ local_bh_enable();
return 0;
}
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 828a59b8e7bf..5800e7ee7ea0 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1070,10 +1070,12 @@ static inline int sctp_v4_xmit(struct sk_buff *skb, struct sctp_transport *t)
skb_reset_inner_mac_header(skb);
skb_reset_inner_transport_header(skb);
skb_set_inner_ipproto(skb, IPPROTO_SCTP);
+ local_bh_disable();
udp_tunnel_xmit_skb(dst_rtable(dst), sk, skb, fl4->saddr,
fl4->daddr, dscp, ip4_dst_hoplimit(dst), df,
sctp_sk(sk)->udp_port, t->encap_port, false, false,
0);
+ local_bh_enable();
return 0;
}
--
2.47.1
^ permalink raw reply related
* [PATCH net] sctp: fix missing encap_port propagation for GSO fragments
From: Xin Long @ 2026-04-12 18:13 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, kuba, Eric Dumazet, Paolo Abeni, Simon Horman,
Marcelo Ricardo Leitner
encap_port in SCTP_INPUT_CB(skb) is used by sctp_vtag_verify() for
SCTP-over-UDP processing. In the GSO case, it is only set on the head
skb, while fragment skbs leave it 0.
This results in fragment skbs seeing encap_port == 0, breaking
SCTP-over-UDP connections.
Fix it by propagating encap_port from the head skb cb when initializing
fragment skbs in sctp_inq_pop().
Fixes: 046c052b475e ("sctp: enable udp tunneling socks")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/inqueue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sctp/inqueue.c b/net/sctp/inqueue.c
index f5a7d5a38755..a024c0843247 100644
--- a/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -201,6 +201,7 @@ struct sctp_chunk *sctp_inq_pop(struct sctp_inq *queue)
cb->chunk = head_cb->chunk;
cb->af = head_cb->af;
+ cb->encap_port = head_cb->encap_port;
}
}
--
2.47.1
^ permalink raw reply related
* Re: [net-next v10 00/10] Add TSO map-once DMA helpers and bnxt SW USO support
From: patchwork-bot+netdevbpf @ 2026-04-12 18:10 UTC (permalink / raw)
To: Joe Damato
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni, horms,
michael.chan, pavan.chebbi, linux-kernel, leon
In-Reply-To: <20260408230607.2019402-1-joe@dama.to>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 16:05:49 -0700 you wrote:
> Greetings:
>
> This series extends net/tso to add a data structure and some helpers allowing
> drivers to DMA map headers and packet payloads a single time. The helpers can
> then be used to reference slices of shared mapping for each segment. This
> helps to avoid the cost of repeated DMA mappings, especially on systems which
> use an IOMMU. N per-packet DMA maps are replaced with a single map for the
> entire GSO skb. As of v3, the series uses the DMA IOVA API (as suggested by
> Leon [1]) and provides a fallback path when an IOMMU is not in use. The DMA
> IOVA API provides even better efficiency than the v2; see below.
>
> [...]
Here is the summary with links:
- [net-next,v10,01/10] net: tso: Introduce tso_dma_map and helpers
https://git.kernel.org/netdev/net-next/c/82db77f6fb16
- [net-next,v10,02/10] net: bnxt: Export bnxt_xmit_get_cfa_action
https://git.kernel.org/netdev/net-next/c/268c63f2c6b2
- [net-next,v10,03/10] net: bnxt: Add a helper for tx_bd_ext
https://git.kernel.org/netdev/net-next/c/637237d3d93c
- [net-next,v10,04/10] net: bnxt: Use dma_unmap_len for TX completion unmapping
https://git.kernel.org/netdev/net-next/c/3cb430e62c83
- [net-next,v10,05/10] net: bnxt: Add TX inline buffer infrastructure
https://git.kernel.org/netdev/net-next/c/0c26a0e765e7
- [net-next,v10,06/10] net: bnxt: Add boilerplate GSO code
https://git.kernel.org/netdev/net-next/c/0440e27eedac
- [net-next,v10,07/10] net: bnxt: Implement software USO
https://git.kernel.org/netdev/net-next/c/cc5d90667db8
- [net-next,v10,08/10] net: bnxt: Add SW GSO completion and teardown support
https://git.kernel.org/netdev/net-next/c/87550ba2dc39
- [net-next,v10,09/10] net: bnxt: Dispatch to SW USO
https://git.kernel.org/netdev/net-next/c/28f2c22398fb
- [net-next,v10,10/10] selftests: drv-net: Add USO test
https://git.kernel.org/netdev/net-next/c/5d3b12d1a24b
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 00/11] netfilter: updates for net-next
From: Julian Anastasov @ 2026-04-12 18:07 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Florian Westphal, netdev, Paolo Abeni, David S. Miller,
Eric Dumazet, netfilter-devel, pablo
In-Reply-To: <20260412105344.5e14fe70@kernel.org>
Hello,
On Sun, 12 Apr 2026, Jakub Kicinski wrote:
> On Sun, 12 Apr 2026 18:54:49 +0200 Florian Westphal wrote:
> > Jakub Kicinski <kuba@kernel.org> wrote:
> > > On Fri, 10 Apr 2026 13:23:41 +0200 Florian Westphal wrote:
> > > > 1-3) IPVS updates from Julian Anastasov to enhance visibility into
> > > > IPVS internal state by exposing hash size, load factor etc and
> > > > allows userspace to tune the load factor used for resizing hash
> > > > tables.
> > >
> > > Someone should take a look at the Sashiko reports for those, please?
> >
> > https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de
> >
> > Sorry Pablo I am dumping this on you. Already wasted 3h on saturday
> > on LLM crap 8-(
>
> Sorry, I was quoting the IPVS section of the PR because I meant that
> someone should look at the IPVS portion. The rest looked like a waste
> of time, indeed. The netns dismantle vs ipvs smelled like it could be
> legit.
I'll check the IPVS part, there are probably
some problems to fix...
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net-next] net: lan743x: rename chip_rev to fpga_rev
From: patchwork-bot+netdevbpf @ 2026-04-12 18:00 UTC (permalink / raw)
To: Thangaraj Samynathan
Cc: bryan.whitehead, UNGLinuxDriver, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20260410085710.9246-1-thangaraj.s@microchip.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 14:27:10 +0530 you wrote:
> The variable chip_rev stores the value read from the FPGA_REV
> register and represents the FPGA revision. Rename it to fpga_rev
> to better reflect its meaning.
>
> No functional change intended.
>
> Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
>
> [...]
Here is the summary with links:
- [net-next] net: lan743x: rename chip_rev to fpga_rev
https://git.kernel.org/netdev/net-next/c/469faa546e7a
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: skb: clean up dead code after skb_kfree_head() simplification
From: patchwork-bot+netdevbpf @ 2026-04-12 18:00 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, davem, edumazet, kuba, pabeni, horms, kerneljasonxing,
kuniyu, mhal, almasrymina, ebiggers, toke, linux-kernel
In-Reply-To: <20260410034736.297900-1-jiayuan.chen@linux.dev>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 11:47:32 +0800 you wrote:
> Since commit 0f42e3f4fe2a ("net: skb: fix cross-cache free of
> KFENCE-allocated skb head"), skb_kfree_head() always calls kfree()
> and no longer uses end_offset to distinguish between skb_small_head_cache
> and generic kmalloc caches.
>
> Clean up the leftovers:
>
> [...]
Here is the summary with links:
- [net-next] net: skb: clean up dead code after skb_kfree_head() simplification
https://git.kernel.org/netdev/net-next/c/5758be283ff8
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] selftests: netfilter: nft_tproxy.sh: adjust to socat changes
From: patchwork-bot+netdevbpf @ 2026-04-12 18:00 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev, kuba
In-Reply-To: <20260409224506.27072-1-fw@strlen.de>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 00:45:02 +0200 you wrote:
> Like e65d8b6f3092 ("selftests: drv-net: adjust to socat changes") we
> need to add shut-none for this test too.
>
> The extra 0-packet can trigger a second (unexpected) reply from the server.
>
> Fixes: 7e37e0eacd22 ("selftests: netfilter: nft_tproxy.sh: add tcp tests")
> Reported-by: Jakub Kicinski <kuba@kernel.org>
> Closes: https://lore.kernel.org/netdev/20260408152432.24b8ad0d@kernel.org/
> Suggested-by: Jakub Kicinski <kuba@kernel.org>
> Signed-off-by: Florian Westphal <fw@strlen.de>
>
> [...]
Here is the summary with links:
- [net] selftests: netfilter: nft_tproxy.sh: adjust to socat changes
https://git.kernel.org/netdev/net-next/c/61119542663c
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] vsock/virtio: remove unnecessary call to `virtio_transport_get_ops`
From: patchwork-bot+netdevbpf @ 2026-04-12 18:00 UTC (permalink / raw)
To: Luigi Leonardi
Cc: mst, jasowang, xuanzhuo, eperezma, stefanha, sgarzare, davem,
edumazet, kuba, pabeni, horms, avkrasnov, kvm, virtualization,
netdev, linux-kernel
In-Reply-To: <20260408-remove_parameter-v2-1-e00f31cf7a17@redhat.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 17:21:02 +0200 you wrote:
> `virtio_transport_send_pkt_info` gets all the transport information
> from the parameter `t_ops`. There is no need to call
> `virtio_transport_get_ops()`.
>
> Remove it.
>
> Acked-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>
> [...]
Here is the summary with links:
- [net-next,v2] vsock/virtio: remove unnecessary call to `virtio_transport_get_ops`
https://git.kernel.org/netdev/net-next/c/006679268a29
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