* [Intel-wired-lan][PATCH iwl-net] idpf: adjust TxQ ring count minimum
From: Joshua Hay @ 2026-06-30 23:56 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev
Set the TxQ ring count minimum to 128 descriptors. Any lower than this,
and the queue will stall and trigger Tx timeouts in flow based
scheduling mode. This is because next_to_clean might never be updated.
In flow based scheduling mode, next_to_clean is only updated after a
descriptor completion is processed, i.e. after the RE bit is set in the
last descriptor of a Tx packet. This will never happen with a ring size
of 64 and an IDPF_TX_SPLITQ_RE_MIN_GAP of 64. No matter what the value
of last_re is initialized/set to, the calculated gap will be at most 63
and never trigger the RE bit.
Even a ring size of 96 does not solve this. Because of how infrequent
next_to_clean is updated and how small the ring is, IDPF_DESC_UNUSED
will be much smaller on average. This increases the chance the queue
will be stopped because a multi-descriptor packet, e.g. a large LSO
packet, does not see enough resources on the ring. In this case, the
queue will trigger the stop logic. The queue permanently stalls because
there is no chance for a descriptor completion to update next_to_clean
since it is dependent on a packet being sent.
Fixes: 5f417d551324 ("idpf: replace flow scheduling buffer ring with buffer pool")
Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_txrx.c | 5 +----
drivers/net/ethernet/intel/idpf/idpf_txrx.h | 2 +-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
index 7f9056404f64..c724d429a7aa 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
@@ -3097,10 +3097,7 @@ static netdev_tx_t idpf_tx_splitq_frame(struct sk_buff *skb,
tx_params.dtype = IDPF_TX_DESC_DTYPE_FLEX_FLOW_SCHE;
tx_params.eop_cmd = IDPF_TXD_FLEX_FLOW_CMD_EOP;
- /* Set the RE bit to periodically "clean" the descriptor ring.
- * MIN_GAP is set to MIN_RING size to ensure it will be set at
- * least once each time around the ring.
- */
+ /* Set the RE bit periodically to "clean" the descriptor ring */
if (idpf_tx_splitq_need_re(tx_q)) {
tx_params.eop_cmd |= IDPF_TXD_FLEX_FLOW_CMD_RE;
tx_q->txq_grp->num_completions_pending++;
diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.h b/drivers/net/ethernet/intel/idpf/idpf_txrx.h
index 4be5b3b6d3ed..908dfa28674e 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.h
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.h
@@ -21,7 +21,7 @@
/* Mailbox Queue */
#define IDPF_MAX_MBXQ 1
-#define IDPF_MIN_TXQ_DESC 64
+#define IDPF_MIN_TXQ_DESC 128
#define IDPF_MIN_RXQ_DESC 64
#define IDPF_MIN_TXQ_COMPLQ_DESC 256
#define IDPF_MAX_QIDS 256
--
2.39.2
^ permalink raw reply related
* Re: [PATCH net-next v1 0/2] Reuse threaded NAPI kthread across napi_del()/napi_add().
From: Jakub Kicinski @ 2026-06-30 23:52 UTC (permalink / raw)
To: Mina Almasry
Cc: Harshitha Ramamurthy, Jordan Rhee, Shuhao Tan, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Andrew Lunn, Shuah Khan,
Samiullah Khawaja, Kuniyuki Iwashima, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <CAHS8izOc7OPrspPfo-6eAwPscQzk6ZzHQd10MFrRvzuPXU9WjA@mail.gmail.com>
On Tue, 30 Jun 2026 16:41:44 -0700 Mina Almasry wrote:
> > Can y'all not open a pidfs fd for the NAPI thread? You'll get a
> > notification when the existing kthread dies?
>
> Let me take a look, but I think we need a notification when the
> kthread is back up to reconfigure it. I guess if we're trying very
> hard not to touch the current code we can always monitor the running
> napi kthreads and their affinity and work around it like that.
To be clear -- I don't mind making changes. My first reaction was
to suggest adding Netlink notifications for when NAPIs are created /
removed. That's the standard Netlink way of letting the user space
do what's needed without adding kernel complexity. Then I remembered
pidfs can probably already do it.
The kernel threads for NAPI, and the state transitions are already
quite hairy. Plus keeping the threads for potentially dead NAPIs
around... IDK, just doesn't feel very clean.
^ permalink raw reply
* Re: [PATCH net] selftests: net: bump default cmd() timeout to 20 seconds
From: patchwork-bot+netdevbpf @ 2026-07-01 0:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
petrm, leitao, dw, noren, gal, linux-kselftest
In-Reply-To: <20260629233348.2145841-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 16:33:48 -0700 you wrote:
> We always used 5 sec as the default command timeout. But soon after
> it was introduced, David effectively made us ignore the timeout
> (it was passed to process.communicate() as the wrong argument).
> Gal recently fixed that, but turns out the 5 sec is not enough
> for a lot of tests and setups. The fix regressed regressions.
>
> In particular running reconfig commands (e.g. XDP attach) on mlx5
> with 32 rings and 9k MTU, on a heavily-debug-enabled kernel takes
> more than 5 sec. The XDP installation command will time out after
> 5 sec but since the sleeps in the kernel are non interruptible
> the command finishes anyway, leaving the XDP program attached,
> but with non-zero exit code. defer()ed cleanups are not installed,
> breaking the environment for subsequent tests.
>
> [...]
Here is the summary with links:
- [net] selftests: net: bump default cmd() timeout to 20 seconds
https://git.kernel.org/netdev/net/c/57bb59ab6fa3
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 v3 net-next] selftests/xsk: Preserve UMEM view in BIDIRECTIONAL test
From: patchwork-bot+netdevbpf @ 2026-07-01 0:00 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: netdev, bpf, magnus.karlsson, stfomichev, kuba, pabeni, horms,
tushar.vyavahare, kerneljasonxing
In-Reply-To: <20260629191221.2700-1-maciej.fijalkowski@intel.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 21:12:21 +0200 you wrote:
> The UMEM state refactor made __send_pkts() use xsk->umem for Tx
> address generation. At the same time, the shared-UMEM Tx setup copies the
> Rx UMEM state into a Tx-local state object and resets base_addr and
> next_buffer before configuring the Tx socket.
>
> Passing that Tx-local object to xsk_configure() makes xsk->umem point to
> the zero-based Tx allocator state. This breaks the BIDIRECTIONAL test once
> the roles are switched: the same socket is then used for Rx validation, but
> received descriptors from the other logical UMEM half are checked against
> base_addr == 0. With the new UMEM bounds check, a valid address such as
> base_addr + XDP_PACKET_HEADROOM is rejected as being outside the UMEM
> window.
>
> [...]
Here is the summary with links:
- [v3,net-next] selftests/xsk: Preserve UMEM view in BIDIRECTIONAL test
https://git.kernel.org/netdev/net-next/c/333289d1690d
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 00/13] treewide: replace linux/gpio.h
From: patchwork-bot+netdevbpf @ 2026-07-01 0:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, arnd, brgl, andrew, sebastian.hesselbarth,
gregory.clement, Frank.Li, robert.jarzmik, krzk, gerg, tsbogend,
hauke, zajec5, ysato, glaubitz, linusw, dmitry.torokhov, kuba,
pabeni, linux, linux-kernel, linux-arm-kernel, linux-samsung-soc,
patches, linux-m68k, linux-mips, linux-sh, linux-input,
linux-media, netdev, linux-sunxi, linux-phy, linux-rockchip,
linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 15:26:20 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> [...]
Here is the summary with links:
- [01/13] ARM: replace linux/gpio.h inclusions
(no matching commit)
- [02/13] m68k/coldfire: replace linux/gpio.h inclusions
(no matching commit)
- [03/13] mips: replace linux/gpio.h inclusions
(no matching commit)
- [04/13] sh: replace linux/gpio.h inclusions
(no matching commit)
- [05/13] mfd: replace linux/gpio.h inclusions
(no matching commit)
- [06/13,net-next] net: replace linux/gpio.h inclusions
https://git.kernel.org/netdev/net-next/c/a53d1872f2be
- [07/13] ASoC: replace linux/gpio.h inclusions
(no matching commit)
- [08/13] pcmcia: replace linux/gpio.h inclusions
(no matching commit)
- [09/13] phy: replace linux/gpio.h inclusions
(no matching commit)
- [10/13] media: replace linux/gpio.h inclusions
(no matching commit)
- [11/13] Input: matrix_keyboard - replace linux/gpio.h inclusion
(no matching commit)
- [12/13] gpib: gpio: replace linux/gpio.h inclusion
(no matching commit)
- [13/13] gpiolib: remove linux/gpio.h
(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-next v4 1/2] bpf, sockmap: disallow update and delete from tc, xdp, socket_filter and flow_dissector
From: John Fastabend @ 2026-07-01 0:07 UTC (permalink / raw)
To: Sechang Lim
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Shuah Khan,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, Stanislav Fomichev, Jiayuan Chen, Varun R Mallya,
Ihor Solodrai, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260630145410.3648099-2-rhkrqnwk98@gmail.com>
On Tue, Jun 30, 2026 at 02:54:05PM +0000, Sechang Lim wrote:
>sock_map_update_common() and __sock_map_delete() hold stab->lock and call
>sock_map_unref() -> sock_map_del_link(), which takes sk_callback_lock for
>write. That gives the order stab->lock -> sk_callback_lock.
>
>The reverse order comes from the SK_SKB stream parser.
>sk_psock_strp_data_ready() holds sk_callback_lock for read, and after the
>verdict tcp_bpf_strp_read_sock() acks the consumed data inline via
>__tcp_cleanup_rbuf(). The ACK goes out egress, where a sched_cls program
>deletes from the sockmap and takes stab->lock:
>
> WARNING: possible circular locking dependency detected
[...]
>A tc, xdp, socket_filter or flow_dissector program has no reason to
>update or delete a sockmap, and redirect does not go through here. Drop
>them from may_update_sockmap() so the verifier rejects it. It also
>closes the matching sockhash inversion.
>
>Suggested-by: John Fastabend <john.fastabend@gmail.com>
>Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
>---
Great lets get this merged and we will separately fix the sockops
issue reported by the bots.
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net 1/2] net/sched: act_skbmod: require an Ethernet header for MAC rewrites
From: Jakub Kicinski @ 2026-07-01 0:10 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, jhs, jiri, davem, edumazet, pabeni, horms, peilin.ye,
cong.wang, gnault, yuantan098, yifanwucs, tomapufckgml, zcliangcn,
bird, bronzed_45_vested
In-Reply-To: <3ab4a04fbab887238facc1792e02c33fd68190f7.1782548651.git.bronzed_45_vested@icloud.com>
On Mon, 29 Jun 2026 10:46:03 +0800 Ren Wei wrote:
> Cc: stable@vger.kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Assisted-by: Codex:GPT-5.4
> Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Let's do away with the 5 reported-by tags? You can use a tag for your
tool or your team, it doesn't have to be a person. Look at sashiko or
syzbot reported-by tags.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] sctp: fix addr_wq_timer race in sctp_free_addr_wq()
From: patchwork-bot+netdevbpf @ 2026-07-01 0:10 UTC (permalink / raw)
To: Xin Long
Cc: netdev, linux-sctp, davem, kuba, edumazet, pabeni, horms,
marcelo.leitner, ebiederm
In-Reply-To: <5dc95f295bdb5c3f60e880dd9aa5112dc5c071cc.1782757874.git.lucien.xin@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 14:31:14 -0400 you wrote:
> sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete()
> while holding addr_wq_lock. However, timer_delete() does not guarantee that
> a currently running timer handler has completed.
>
> This allows a race with sctp_addr_wq_timeout_handler(), where the handler
> may still run after addr_waitq has been freed, acquire addr_wq_lock, and
> access freed memory, leading to a use-after-free.
>
> [...]
Here is the summary with links:
- [net] sctp: fix addr_wq_timer race in sctp_free_addr_wq()
https://git.kernel.org/netdev/net/c/976c19de0f22
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf-next v4 2/2] selftests/bpf: drop tc/xdp/flow_dissector/socket_filter sockmap mutation tests
From: John Fastabend @ 2026-07-01 0:10 UTC (permalink / raw)
To: Sechang Lim
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, Shuah Khan,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, Stanislav Fomichev, Jiayuan Chen, Varun R Mallya,
Ihor Solodrai, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260630145410.3648099-3-rhkrqnwk98@gmail.com>
On Tue, Jun 30, 2026 at 02:54:06PM +0000, Sechang Lim wrote:
>tc, xdp, socket_filter and flow_dissector programs can no longer update
>or delete a sockmap. Adjust the tests:
>
> - verifier_sockmap_mutate: the tc, xdp, socket_filter and
> flow_dissector cases now expect __failure with "cannot update sockmap
> in this context".
> - sockmap_basic: drop "sockmap update" / "sockhash update", which load
> a SEC("tc") program that copies a sock between maps.
> - fexit_bpf2bpf: drop "func_sockmap_update", whose freplace program
> updates a sockmap in the tc cls_redirect context.
>
>Remove the now-unused test_sockmap_update.c and freplace_cls_redirect.c.
>
>Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next] chelsio: delete the line with the pidx initialization
From: Jakub Kicinski @ 2026-07-01 0:16 UTC (permalink / raw)
To: Markov Gleb
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Paolo Abeni, netdev,
linux-kernel, lvc-project
In-Reply-To: <20260629130839.218-1-markov.gi@npc-ksb.ru>
On Mon, 29 Jun 2026 16:08:35 +0300 Markov Gleb wrote:
> The value of pidx is overwritten immediately after exiting the "if" block.
>
> Remove pidx ptr initialization string from conditional block.
shrug?
--
pw-bot: reject
^ permalink raw reply
* Re: [PATCH v5] virtio_net: disable cb when NAPI is busy-polled
From: patchwork-bot+netdevbpf @ 2026-07-01 0:20 UTC (permalink / raw)
To: Longjun Tang
Cc: kuba, horms, mst, jasowang, edumazet, virtualization, netdev,
tanglongjun
In-Reply-To: <20260629024230.37325-1-lange_tang@163.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 10:42:30 +0800 you wrote:
> From: Longjun Tang <tanglongjun@kylinos.cn>
>
> When busy-poll is active, napi_schedule_prep() returns false in
> virtqueue_napi_schedule(), so virtqueue_disable_cb() is skipped.
> The device may keep firing irqs until reaches virtqueue_napi_complete().
> Under load (received == budget), it will lead to a large number
> of spurious interrupts.
>
> [...]
Here is the summary with links:
- [v5] virtio_net: disable cb when NAPI is busy-polled
https://git.kernel.org/netdev/net/c/1eb8fc67ca41
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 1/2] net/sched: act_skbmod: require an Ethernet header for MAC rewrites
From: Jakub Kicinski @ 2026-07-01 0:20 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, jhs, jiri, davem, edumazet, pabeni, horms, peilin.ye,
cong.wang, gnault, yuantan098, yifanwucs, tomapufckgml, zcliangcn,
bird, bronzed_45_vested
In-Reply-To: <20260630171016.11c02dec@kernel.org>
On Tue, 30 Jun 2026 17:10:16 -0700 Jakub Kicinski wrote:
> On Mon, 29 Jun 2026 10:46:03 +0800 Ren Wei wrote:
> > Cc: stable@vger.kernel.org
> > Reported-by: Yuan Tan <yuantan098@gmail.com>
> > Reported-by: Yifan Wu <yifanwucs@gmail.com>
> > Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> > Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
> > Reported-by: Xin Liu <bird@lzu.edu.cn>
> > Assisted-by: Codex:GPT-5.4
> > Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
> > Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
>
> Let's do away with the 5 reported-by tags? You can use a tag for your
> tool or your team, it doesn't have to be a person. Look at sashiko or
> syzbot reported-by tags.
On second thought, if y'all work together maybe there should be no
reported-by tag at all? Can you explain the situation?
^ permalink raw reply
* Re: [PATCH net] net: sgi: ioc3-eth: fix split TX DMA mapping lengths
From: patchwork-bot+netdevbpf @ 2026-07-01 0:20 UTC (permalink / raw)
To: Xu Rao
Cc: tsbogend, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-mips, netdev, linux-kernel, stable
In-Reply-To: <4E1486BC4536407E+20260629080623.908426-1-raoxu@uniontech.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 16:06:23 +0800 you wrote:
> From: Xu Rao <raoxu@uniontech.com>
>
> When a linear skb crosses a 16 KiB boundary, ioc3_start_xmit()
> splits it into two buffers of lengths s1 and s2. The descriptor
> advertises those lengths through B1CNT and B2CNT.
>
> The first buffer is mapped with s1, but the second buffer is also
> mapped with s1 even though the device is told to fetch s2 bytes from
> it. When the lengths differ, the DMA mapping does not cover the same
> region as the second descriptor buffer, which can result in incorrect
> cache maintenance or a DMA fault on implementations that enforce the
> mapped range.
>
> [...]
Here is the summary with links:
- [net] net: sgi: ioc3-eth: fix split TX DMA mapping lengths
https://git.kernel.org/netdev/net-next/c/cd066559a073
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 v4 net-next] bonding: no longer rely on RTNL in bond_fill_info()
From: patchwork-bot+netdevbpf @ 2026-07-01 0:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet, jv,
andrew+netdev
In-Reply-To: <20260629173200.469953-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 17:32:00 +0000 you wrote:
> Add READ_ONCE()/WRITE_ONCE() annotations on port->is_enabled.
> While this field is written under bond->mode_lock protection,
> is is read without this lock being held.
>
> Change bond_fill_info() to acquire RCU and use READ_ONCE()
> to read bond->params fields that can be updated concurrently
> from sysfs/procfs/rtnetlink.
>
> [...]
Here is the summary with links:
- [v4,net-next] bonding: no longer rely on RTNL in bond_fill_info()
https://git.kernel.org/netdev/net-next/c/317cefdcaacc
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/2] net: do not warn on best-effort skb allocation failures
From: patchwork-bot+netdevbpf @ 2026-07-01 0:20 UTC (permalink / raw)
To: Breno Leitao
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel, asantostc, gustavold, vlad.wing, kernel-team
In-Reply-To: <20260629-netpoll_no_warn-v1-0-f380f0b2cd0c@debian.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 04:45:39 -0700 you wrote:
> Both netconsole and netpoll keep a small preallocated pool of skbs
> (skb_pool) so they can still get a buffer under memory pressure.
>
> On the hot path they first attempt a normal GFP_ATOMIC allocation and only
> fall back to the pool when that fails, keeping the pool as a last resort.
>
> This is where the problem happens. If alloc_skb() fails, we now have
> more than 100 message coming from the page=0 failure, which consumes the
> scarce pool of skb, making the real issue disappear.
>
> [...]
Here is the summary with links:
- [net-next,1/2] netconsole: do not warn when the best-effort skb allocation fails
https://git.kernel.org/netdev/net-next/c/09f7a613a14f
- [net-next,2/2] netpoll: do not warn when the best-effort pool refill fails
https://git.kernel.org/netdev/net-next/c/84c0ff1efb62
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: sgi: ioc3-eth: unregister netdev before freeing DMA rings
From: patchwork-bot+netdevbpf @ 2026-07-01 0:20 UTC (permalink / raw)
To: Xu Rao
Cc: tsbogend, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-mips, netdev, linux-kernel, stable
In-Reply-To: <40CD736C4911C181+20260629085053.964383-1-raoxu@uniontech.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 16:50:53 +0800 you wrote:
> From: Xu Rao <raoxu@uniontech.com>
>
> ioc3eth_remove() frees the coherent RX and TX descriptor rings before
> unregistering the netdev. If the interface is running,
> unregister_netdev() invokes ioc3_close() through ndo_stop.
>
> ioc3_close() stops the device and then calls ioc3_free_rx_bufs() and
> ioc3_clean_tx_ring(). Both cleanup functions access descriptors in the
> rings, so the current ordering causes CPU accesses to freed coherent
> memory. Until ioc3_stop() disables RX and TX DMA, the device may also
> continue using the freed ring addresses.
>
> [...]
Here is the summary with links:
- [net] net: sgi: ioc3-eth: unregister netdev before freeing DMA rings
https://git.kernel.org/netdev/net-next/c/18a28f3e107e
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/liquidio: drop cached VF pci_dev LUT and resolve VF for FLR on request
From: Jakub Kicinski @ 2026-07-01 0:22 UTC (permalink / raw)
To: Yuho Choi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Paolo Abeni,
Kory Maincent, Zilin Guan, Uwe Kleine-Koenig, Vadim Fedorenko,
Marco Crivellari, netdev, linux-kernel
In-Reply-To: <20260629141656.1769227-1-dbgh9129@gmail.com>
On Mon, 29 Jun 2026 10:16:56 -0400 Yuho Choi wrote:
> Xgene PCI probe by using port->dev->of_node directly.
sashiko points out that this is not part of this patch (or driver?)
--
pw-bot: cr
^ permalink raw reply
* [PATCH v5] bpf: Fix smp_processor_id() call trace for preemptible kernels
From: Edward Adam Davis @ 2026-07-01 0:27 UTC (permalink / raw)
To: sashiko-bot
Cc: eadavis, jiayuan.chen, sashiko-reviews, andrii, ast, bpf, daniel,
eddyz87, emil, jolsa, linux-kernel, martin.lau, memxor, netdev,
song, syzkaller-bugs, yonghong.song
In-Reply-To: <20260630132226.C44601F000E9@smtp.kernel.org>
bpf_mem_cache_free_rcu() maybe called in preemptible context, this
will trigger the below warning message:
BUG: using smp_processor_id() in preemptible [00000000] code: syz.0.17/5820
caller is bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
Call Trace:
check_preemption_disabled+0xd3/0xe0 lib/smp_processor_id.c:47
bpf_mem_cache_free_rcu+0x48/0xc0 kernel/bpf/memalloc.c:954
rhtab_delete_elem+0x185a/0x1b30 kernel/bpf/hashtab.c:2969
__rhtab_map_lookup_and_delete_batch+0x935/0xcb0 kernel/bpf/hashtab.c:3349
bpf_map_do_batch+0x445/0x630 kernel/bpf/syscall.c:-1
__sys_bpf+0x906/0xd90 kernel/bpf/syscall.c:-1
this_cpu_ptr() requires the caller to prevent task migration.
These helpers currently do not enforce that requirement and may
be invoked from preemptible contexts, leading to accesses to another
CPU's per-CPU cache after migration. Use get_cpu_ptr()/put_cpu_ptr()
to pin the task while accessing the per-CPU allocator state.
Fixes: 5af6807bdb10 ("bpf: Introduce bpf_mem_free_rcu() similar to kfree_rcu().")
Fixes: 7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")
Reported-by: syzbot+fd7e415d891073b83e1f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
v1 -> v2: using guard against preemption
v2 -> v3: replace get/put_cpu() to bpf_disable/enable_instrumentation()
v3 -> v4: disable preempt to make this_cpu_ptr() work
v4 -> v5: in mem free disable preemption
kernel/bpf/memalloc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/memalloc.c b/kernel/bpf/memalloc.c
index e9662db7198f..2118fe725ed4 100644
--- a/kernel/bpf/memalloc.c
+++ b/kernel/bpf/memalloc.c
@@ -911,7 +911,8 @@ void notrace bpf_mem_free(struct bpf_mem_alloc *ma, void *ptr)
if (WARN_ON_ONCE(idx < 0))
return;
- unit_free(this_cpu_ptr(ma->caches)->cache + idx, ptr);
+ unit_free(get_cpu_ptr(ma->caches)->cache + idx, ptr);
+ put_cpu_ptr(ma->caches);
}
void notrace bpf_mem_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
@@ -927,7 +928,8 @@ void notrace bpf_mem_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
if (WARN_ON_ONCE(idx < 0))
return;
- unit_free_rcu(this_cpu_ptr(ma->caches)->cache + idx, ptr);
+ unit_free_rcu(get_cpu_ptr(ma->caches)->cache + idx, ptr);
+ put_cpu_ptr(ma->caches);
}
void notrace *bpf_mem_cache_alloc(struct bpf_mem_alloc *ma)
@@ -951,7 +953,8 @@ void notrace bpf_mem_cache_free_rcu(struct bpf_mem_alloc *ma, void *ptr)
if (!ptr)
return;
- unit_free_rcu(this_cpu_ptr(ma->cache), ptr);
+ unit_free_rcu(get_cpu_ptr(ma->cache), ptr);
+ put_cpu_ptr(ma->cache);
}
/* Directly does a kfree() without putting 'ptr' back to the free_llist
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] cxgb4: Fix decode strings dump for T6 adapters
From: patchwork-bot+netdevbpf @ 2026-07-01 0:30 UTC (permalink / raw)
To: Markov Gleb
Cc: bharat, andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, lvc-project
In-Reply-To: <20260629130856.1168-1-markov.gi@npc-ksb.ru>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 16:08:54 +0300 you wrote:
> From: Gleb Markov <markov.gi@npc-ksb.ru>
>
> Depending on the value of chip_version, the correct decode set is selected.
> However, the subsequent matching with the t4 encoding type in the if-else
> block results in a reassignment, which leads to the loss of support for
> t6_decode as well as reinitializing of values t4_decode and t5_decode.
>
> [...]
Here is the summary with links:
- [net] cxgb4: Fix decode strings dump for T6 adapters
https://git.kernel.org/netdev/net/c/5d6dc22d6268
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] ipv4: igmp: remove multicast group from hash table on device destruction
From: Yuyang Huang @ 2026-07-01 0:41 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: idosch, davem, dsahern, edumazet, horms, jedrzej.jagielski, kuba,
linux-kernel, netdev, pabeni, xiyou.wangcong
In-Reply-To: <20260630211527.3365952-1-kuniyu@google.com>
On Wed, Jul 1, 2026 at 6:15 AM Kuniyuki Iwashima <kuniyu@google.com> wrote:
>
> From: Ido Schimmel <idosch@nvidia.com>
> Date: Tue, 30 Jun 2026 19:59:34 +0300
> > On Tue, Jun 30, 2026 at 04:55:22PM +0900, Yuyang Huang wrote:
> > > > Hi,
> > > >
> > > > why sending this to net-next not to net if that's a bug fix?
> > > >
> > > > In the v1 thread it was said
> > > > >This is a long-standing bug, not a recent regression.
> > > >
> > > > so why do not cc stable kernel to get rid of this bug from
> > > > stable kernels in such case?
> > >
> > > Thanks for the advise, will send this patch to stable kernel.
> >
> > Please target v3 at net and add a trace given you're claiming for a
> > use-after-free. That way we know that the problem is real and not a
> > false-positive from some tool. You can reproduce it by adding enough
> > delay in inetdev_destroy():
>
> I guess delay was added between ip_mc_destroy_dev() and
> RCU_INIT_POINTER(dev->ip_ptr, NULL) ?
>
> I feel like we should clear it first and destroy everything
> as done in IPv6 addrconf_ifdown().
>
>
> >
> > BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x2cc/0x500
> > Read of size 4 at addr ffff88810c571208 by task mausezahn/419
> >
> > CPU: 2 UID: 0 PID: 419 Comm: mausezahn Not tainted 7.1.0-virtme-g15d4a7c23bf6 #17 PREEMPT(lazy)
> > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > Call Trace:
> > <IRQ>
> > dump_stack_lvl+0x4d/0x70
> > print_report+0x153/0x4c2
> > kasan_report+0xda/0x110
> > ip_check_mc_rcu+0x2cc/0x500
> > ip_route_input_rcu.part.0+0x13d/0xbc0
> > ip_route_input_noref+0xb6/0x110
> > ip_rcv_finish_core+0x41b/0x1d90
> > ip_rcv_finish+0xea/0x1b0
> > ip_rcv+0xb7/0x1b0
> > __netif_receive_skb_one_core+0xfc/0x180
> > process_backlog+0x1ea/0x5e0
> > __napi_poll+0x97/0x480
> > net_rx_action+0x97c/0xfa0
> > handle_softirqs+0x18c/0x4f0
> > do_softirq+0x42/0x60
> > </IRQ>
> >
Thanks for the advise, I will try to add a trace in v3. For more
reference, the issue is pointed out in the following discussion:
https://lore.kernel.org/netdev/95adff35-ee56-49d3-8567-382ac17810b3@redhat.com/#t
^ permalink raw reply
* [PATCH net] gve: fix Rx queue stall on alloc failure
From: Harshitha Ramamurthy @ 2026-07-01 0:53 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, ast, daniel, hawk, john.fastabend, bpf, sdf, willemb,
jordanrhee, nktgrg, maolson, jacob.e.keller, thostet, csully, bcf,
linux-kernel, stable, Eddie Phillips
From: Eddie Phillips <eddiephillips@google.com>
When the system is under extreme memory pressure, page allocations can
fail during the Rx buffer refill loop. If the number of buffers posted
to hardware falls below a critical low threshold and the refill loop
exits due to allocation failures, the queue can stall:
1. The device drops incoming packets because there are no descriptors.
2. Since no packets are processed, no Rx completions are generated.
3. Because no completions occur, NAPI is never scheduled, preventing
the refill loop from running again even after memory is freed.
This results in a permanent queue stall.
Resolve this by introducing a starvation recovery timer for each Rx queue.
If the number of buffers posted to hardware falls below a critical low
threshold, start a timer to periodically reschedule NAPI. Once NAPI runs
and successfully refills the queue above the threshold, the timer is
not rescheduled.
Also add a new ethtool statistic "rx_critical_low_bufs" to track the
number of times the starvation recovery timer is triggered.
Cc: stable@vger.kernel.org
Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path")
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Eddie Phillips <eddiephillips@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve.h | 4 ++++
drivers/net/ethernet/google/gve/gve_ethtool.c | 14 +++++++++++++-
drivers/net/ethernet/google/gve/gve_rx_dqo.c | 32 ++++++++++++++++++++++++++++++++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h
index 2f7bd330..8378bef2 100644
--- a/drivers/net/ethernet/google/gve/gve.h
+++ b/drivers/net/ethernet/google/gve/gve.h
@@ -13,6 +13,7 @@
#include <linux/netdevice.h>
#include <linux/net_tstamp.h>
#include <linux/pci.h>
+#include <linux/timer.h>
#include <linux/ptp_clock_kernel.h>
#include <linux/u64_stats_sync.h>
#include <net/page_pool/helpers.h>
@@ -41,6 +42,7 @@
/* Interval to schedule a stats report update, 20000ms. */
#define GVE_STATS_REPORT_TIMER_PERIOD 20000
+#define GVE_RX_NAPI_RESCHED_MS 20 /* msecs */
/* Numbers of NIC tx/rx stats in stats report. */
#define NIC_TX_STATS_REPORT_NUM 0
@@ -318,6 +320,7 @@ struct gve_rx_ring {
u64 rx_copied_pkt; /* free-running total number of copied packets */
u64 rx_skb_alloc_fail; /* free-running count of skb alloc fails */
u64 rx_buf_alloc_fail; /* free-running count of buffer alloc fails */
+ u64 rx_critical_low_bufs; /* count of critical low buffer events */
u64 rx_desc_err_dropped_pkt; /* free-running count of packets dropped by descriptor error */
/* free-running count of unsplit packets due to header buffer overflow or hdr_len is 0 */
u64 rx_hsplit_unsplit_pkt;
@@ -334,6 +337,7 @@ struct gve_rx_ring {
struct gve_queue_resources *q_resources; /* head and tail pointer idx */
dma_addr_t q_resources_bus; /* dma address for the queue resources */
struct u64_stats_sync statss; /* sync stats for 32bit archs */
+ struct timer_list starvation_timer; /* for queue starvation recovery */
struct gve_rx_ctx ctx; /* Info for packet currently being processed in this ring. */
diff --git a/drivers/net/ethernet/google/gve/gve_ethtool.c b/drivers/net/ethernet/google/gve/gve_ethtool.c
index a0e0472b..71b6efbf 100644
--- a/drivers/net/ethernet/google/gve/gve_ethtool.c
+++ b/drivers/net/ethernet/google/gve/gve_ethtool.c
@@ -46,6 +46,7 @@ static const char gve_gstrings_main_stats[][ETH_GSTRING_LEN] = {
"rx_hsplit_unsplit_pkt",
"interface_up_cnt", "interface_down_cnt", "reset_cnt",
"page_alloc_fail", "dma_mapping_error", "stats_report_trigger_cnt",
+ "rx_critical_low_bufs",
};
static const char gve_gstrings_rx_stats[][ETH_GSTRING_LEN] = {
@@ -58,6 +59,7 @@ static const char gve_gstrings_rx_stats[][ETH_GSTRING_LEN] = {
"rx_xdp_aborted[%u]", "rx_xdp_drop[%u]", "rx_xdp_pass[%u]",
"rx_xdp_tx[%u]", "rx_xdp_redirect[%u]",
"rx_xdp_tx_errors[%u]", "rx_xdp_redirect_errors[%u]", "rx_xdp_alloc_fails[%u]",
+ "rx_critical_low_bufs[%u]",
};
static const char gve_gstrings_tx_stats[][ETH_GSTRING_LEN] = {
@@ -151,12 +153,14 @@ gve_get_ethtool_stats(struct net_device *netdev,
{
u64 tmp_rx_pkts, tmp_rx_hsplit_pkt, tmp_rx_bytes, tmp_rx_hsplit_bytes,
tmp_rx_skb_alloc_fail, tmp_rx_buf_alloc_fail,
+ tmp_rx_critical_low_bufs,
tmp_rx_desc_err_dropped_pkt, tmp_rx_hsplit_unsplit_pkt,
tmp_tx_pkts, tmp_tx_bytes,
tmp_xdp_tx_errors, tmp_xdp_redirect_errors;
u64 rx_buf_alloc_fail, rx_desc_err_dropped_pkt, rx_hsplit_unsplit_pkt,
rx_pkts, rx_hsplit_pkt, rx_skb_alloc_fail, rx_bytes, tx_pkts, tx_bytes,
- tx_dropped, xdp_tx_errors, xdp_redirect_errors;
+ rx_critical_low_bufs, tx_dropped, xdp_tx_errors,
+ xdp_redirect_errors;
int rx_base_stats_idx, max_rx_stats_idx, max_tx_stats_idx;
int stats_idx, stats_region_len, nic_stats_len;
struct stats *report_stats;
@@ -197,6 +201,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
for (rx_pkts = 0, rx_bytes = 0, rx_hsplit_pkt = 0,
rx_skb_alloc_fail = 0, rx_buf_alloc_fail = 0,
+ rx_critical_low_bufs = 0,
rx_desc_err_dropped_pkt = 0, rx_hsplit_unsplit_pkt = 0,
xdp_tx_errors = 0, xdp_redirect_errors = 0,
ring = 0;
@@ -212,6 +217,8 @@ gve_get_ethtool_stats(struct net_device *netdev,
tmp_rx_bytes = rx->rbytes;
tmp_rx_skb_alloc_fail = rx->rx_skb_alloc_fail;
tmp_rx_buf_alloc_fail = rx->rx_buf_alloc_fail;
+ tmp_rx_critical_low_bufs =
+ rx->rx_critical_low_bufs;
tmp_rx_desc_err_dropped_pkt =
rx->rx_desc_err_dropped_pkt;
tmp_rx_hsplit_unsplit_pkt =
@@ -226,6 +233,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
rx_bytes += tmp_rx_bytes;
rx_skb_alloc_fail += tmp_rx_skb_alloc_fail;
rx_buf_alloc_fail += tmp_rx_buf_alloc_fail;
+ rx_critical_low_bufs += tmp_rx_critical_low_bufs;
rx_desc_err_dropped_pkt += tmp_rx_desc_err_dropped_pkt;
rx_hsplit_unsplit_pkt += tmp_rx_hsplit_unsplit_pkt;
xdp_tx_errors += tmp_xdp_tx_errors;
@@ -269,6 +277,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
data[i++] = priv->page_alloc_fail;
data[i++] = priv->dma_mapping_error;
data[i++] = priv->stats_report_trigger_cnt;
+ data[i++] = rx_critical_low_bufs;
i = GVE_MAIN_STATS_LEN;
rx_base_stats_idx = 0;
@@ -337,6 +346,8 @@ gve_get_ethtool_stats(struct net_device *netdev,
tmp_rx_hsplit_bytes = rx->rx_hsplit_bytes;
tmp_rx_skb_alloc_fail = rx->rx_skb_alloc_fail;
tmp_rx_buf_alloc_fail = rx->rx_buf_alloc_fail;
+ tmp_rx_critical_low_bufs =
+ rx->rx_critical_low_bufs;
tmp_rx_desc_err_dropped_pkt =
rx->rx_desc_err_dropped_pkt;
tmp_xdp_tx_errors = rx->xdp_tx_errors;
@@ -381,6 +392,7 @@ gve_get_ethtool_stats(struct net_device *netdev,
} while (u64_stats_fetch_retry(&priv->rx[ring].statss,
start));
i += GVE_XDP_ACTIONS + 3; /* XDP rx counters */
+ data[i++] = tmp_rx_critical_low_bufs;
}
} else {
i += priv->rx_cfg.num_queues * NUM_GVE_RX_CNTS;
diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
index 02cba280..303db4fa 100644
--- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c
+++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c
@@ -18,6 +18,16 @@
#include <net/tcp.h>
#include <net/xdp_sock_drv.h>
+static void gve_rx_starvation_timer(struct timer_list *t)
+{
+ struct gve_rx_ring *rx = timer_container_of(rx, t, starvation_timer);
+ struct gve_priv *priv = rx->gve;
+ struct gve_notify_block *block;
+
+ block = &priv->ntfy_blocks[rx->ntfy_id];
+ napi_schedule(&block->napi);
+}
+
static void gve_rx_free_hdr_bufs(struct gve_priv *priv, struct gve_rx_ring *rx)
{
struct device *hdev = &priv->pdev->dev;
@@ -120,6 +130,7 @@ void gve_rx_stop_ring_dqo(struct gve_priv *priv, int idx)
if (rx->dqo.page_pool)
page_pool_disable_direct_recycling(rx->dqo.page_pool);
+ timer_delete_sync(&rx->starvation_timer);
gve_remove_napi(priv, ntfy_idx);
gve_rx_remove_from_block(priv, idx);
gve_rx_reset_ring_dqo(priv, idx);
@@ -136,6 +147,8 @@ void gve_rx_free_ring_dqo(struct gve_priv *priv, struct gve_rx_ring *rx,
u32 qpl_id;
int i;
+ timer_shutdown_sync(&rx->starvation_timer);
+
completion_queue_slots = rx->dqo.complq.mask + 1;
buffer_queue_slots = rx->dqo.bufq.mask + 1;
@@ -232,6 +245,7 @@ int gve_rx_alloc_ring_dqo(struct gve_priv *priv,
rx->gve = priv;
rx->q_num = idx;
rx->packet_buffer_size = cfg->packet_buffer_size;
+ timer_setup(&rx->starvation_timer, gve_rx_starvation_timer, 0);
if (cfg->xdp) {
rx->packet_buffer_truesize = GVE_XDP_RX_BUFFER_SIZE_DQO;
@@ -365,6 +379,7 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
struct gve_rx_compl_queue_dqo *complq = &rx->dqo.complq;
struct gve_rx_buf_queue_dqo *bufq = &rx->dqo.bufq;
struct gve_priv *priv = rx->gve;
+ u32 num_bufs_avail_to_hw;
u32 num_avail_slots;
u32 num_full_slots;
u32 num_posted = 0;
@@ -400,6 +415,23 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
}
rx->fill_cnt += num_posted;
+
+ /* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
+ * visible to the hardware, and no doorbell was written, the hardware
+ * is in danger of starving and cannot trigger interrupts. Start the
+ * timer to periodically reschedule NAPI and recover from starvation.
+ */
+ num_bufs_avail_to_hw =
+ ((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
+ bufq->head) & bufq->mask;
+
+ if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
+ u64_stats_update_begin(&rx->statss);
+ rx->rx_critical_low_bufs++;
+ u64_stats_update_end(&rx->statss);
+ mod_timer(&rx->starvation_timer,
+ jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
+ }
}
static void gve_rx_skb_csum(struct sk_buff *skb,
--
2.55.0.rc2.803.g1fd1e6609c-goog
^ permalink raw reply related
* Re: [PATCH net] selftests: drv-net: tso: don't touch dangerous feature bits
From: patchwork-bot+netdevbpf @ 2026-07-01 1:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
daniel.zahka, linux-kselftest
In-Reply-To: <20260629233923.2151144-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 29 Jun 2026 16:39:23 -0700 you wrote:
> query_nic_features() detects which offloads depend on tx-gso-partial
> by enabling everything, turning tx-gso-partial off, and seeing which
> active features drop out. Enabling all hw features is dangerous:
> we may end up enabling rx-fcs and loopback for example. For the
> ice driver we end up getting into problems with feature dependencies
> so the cleanup isn't successful either, and the test exits with
> rx-fcs and loopback enabled.
>
> [...]
Here is the summary with links:
- [net] selftests: drv-net: tso: don't touch dangerous feature bits
https://git.kernel.org/netdev/net/c/2f7f2e311106
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 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-07-01 1:32 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn
Cc: dinguyen@kernel.org, rmk+kernel@armlinux.org.uk,
krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <e691298f-b3e5-4c1a-8270-a821c1f46a2b@bootlin.com>
On 30/6/2026 11:42 pm, Maxime Chevallier wrote:
>
>
> On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:
>
>> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
>> Quartus soft IP instantiated in the FPGA fabric — equivalent to the
>> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
>> fabric, the soft IP converts them to RGMII, and the RGMII signals then
>> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
>
> Does this converter need any special config, and does it expose any
> control registers ? or is it fully autonomous ?
>
> If it's fully autonomous, can you detect its presence through some
> capability registers or something like that ?
>
>
> Maxime
>
Hi Maxime,
Per my knowledge, the converter is fully autonomous with no control
registers and no software configuration required.
Speed switching is handled entirely in hardware — the XGMAC's mac_speed
output signals are wired directly in the FPGA fabric to the converter's
speed input. No driver intervention is needed on speed changes.
There are no capability registers and no way to detect its presence in
hardware. It is a property of the FPGA design, not the HPS silicon.
BR,
Nazim Amirul
^ permalink raw reply
* [PATCH net-next v2] ice: use dev_err_probe() in ice_probe()
From: Rongguang Wei @ 2026-07-01 1:36 UTC (permalink / raw)
To: netdev, intel-wired-lan, aleksandr.loktionov, przemyslaw.kitszel
Cc: anthony.l.nguyen, andrew+netdev, Rongguang Wei
From: Rongguang Wei <weirongguang@kylinos.cn>
dev_err_probe() logs the error and returns the supplied error code, which
allows probe error paths to be written more compactly.
Use dev_err_probe() in ice_probe() for error paths that currently print an
error message and immediately return the same error code. This keeps the
existing error handling semantics while reducing open-coded logging and
return sequences.
Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
v2:
- Fix commit message per Aleksandr Loktionov's recommendation.
v1: https://lore.kernel.org/netdev/20260630032537.42605-1-clementwei90@163.com/T/#t
---
drivers/net/ethernet/intel/ice/ice_main.c | 24 ++++++++---------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index e2fd2dab03e3..31aa42f8e6d3 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5161,10 +5161,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
struct ice_hw *hw;
int err;
- if (pdev->is_virtfn) {
- dev_err(dev, "can't probe a virtual function\n");
- return -EINVAL;
- }
+ if (pdev->is_virtfn)
+ return dev_err_probe(dev, -EINVAL, "can't probe a virtual function\n");
/* when under a kdump kernel initiate a reset before enabling the
* device in order to clear out any pending DMA transactions. These
@@ -5188,10 +5186,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
return err;
err = pcim_iomap_regions(pdev, BIT(ICE_BAR0), dev_driver_string(dev));
- if (err) {
- dev_err(dev, "BAR0 I/O map error %d\n", err);
- return err;
- }
+ if (err)
+ return dev_err_probe(dev, err, "BAR0 I/O map error %d\n", err);
pf = ice_allocate_pf(dev);
if (!pf)
@@ -5202,10 +5198,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
/* set up for high or low DMA */
err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
- if (err) {
- dev_err(dev, "DMA configuration failed: 0x%x\n", err);
- return err;
- }
+ if (err)
+ return dev_err_probe(dev, err, "DMA configuration failed: 0x%x\n", err);
pci_set_master(pdev);
pf->pdev = pdev;
@@ -5240,10 +5234,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
return ice_probe_recovery_mode(pf);
err = ice_init_hw(hw);
- if (err) {
- dev_err(dev, "ice_init_hw failed: %d\n", err);
- return err;
- }
+ if (err)
+ return dev_err_probe(dev, err, "ice_init_hw failed: %d\n", err);
ice_init_dev_hw(pf);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net] netfilter: nf_nat_masquerade: recalculate TCP TS offset when port is randomized
From: Jiayuan Chen @ 2026-07-01 1:44 UTC (permalink / raw)
To: xietangxin, Pablo Neira Ayuso, Florian Westphal, Phil Sutter,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: gaoxingwang, huyizhen, netfilter-devel, coreteam, netdev,
linux-kernel, stable
In-Reply-To: <20260629093408.3927103-1-xietangxin@h-partners.com>
On 6/29/26 5:34 PM, xietangxin wrote:
> Problem observed in Kubernetes environments where MASQUERADE target with
> --random-fully is configured by default. after commit
> 165573e41f2f ("tcp: secure_seq: add back ports to TS offset") TCP short
> connection QPS dropped from ~20000 to ~10000. This added source and
> destination ports into TS offset calculation.
>
> However, with MASQUERADE --random-fully, when multiple internal connections
> (e.g sport 10000,20000) are mapped to the same external port (e.g 30000),
> their TS offsets are calculated as ts_offset(10000) and ts_offset(20000).
> If the server reuses the TIME_WAIT slot from the first connection, there is
> a chance that ts_offset(20000) < ts_offset(10000), breaking TSval
> monotonicity for the same 4-tuple and causing RST packets:
> Client -> Server 24870 -> 80 [SYN] TSval=2294041168
> Server -> Client 80 -> 24870 [ACK] TSecr=2846236456
> Client -> Server 24870 -> 80 [RST] Seq=855605690
>
> After nf_nat_setup_info() successfully assigns a new randomized
> source port, recalculate the TS offset using the new port and
> update the SYN packet's TSval accordingly.
>
> Test results on 4U4G VM with
> `./wrk -t8 -c200 -H "Connection: close" -d10s --latency http://5.5.5.5:80`
> Before:
> random:10712 req/s, random-fully:10986 req/s
> After:
> random:21463 req/s, random-fully:19181 req/s
>
> Fixes: 165573e41f2f ("tcp: secure_seq: add back ports to TS offset")
> Cc: stable@vger.kernel.org
I'd treat it as a feature not a fix.
> Closes:https://lore.kernel.org/all/92935c00-e0be-4591-ac44-5978c7804d57@yeah.net/
> Signed-off-by: xietangxin <xietangxin@h-partners.com>
> ---
> net/netfilter/nf_nat_masquerade.c | 91 ++++++++++++++++++++++++++++++-
> 1 file changed, 89 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nf_nat_masquerade.c b/net/netfilter/nf_nat_masquerade.c
> index 4de6e0a51701..8c9ca5a051cc 100644
> --- a/net/netfilter/nf_nat_masquerade.c
> +++ b/net/netfilter/nf_nat_masquerade.c
> @@ -6,8 +6,11 @@
> #include <linux/netfilter.h>
> #include <linux/netfilter_ipv4.h>
> #include <linux/netfilter_ipv6.h>
> +#include <linux/tcp.h>
>
> +#include <net/tcp.h>
> #include <net/netfilter/nf_nat_masquerade.h>
> +#include <net/secure_seq.h>
>
> struct masq_dev_work {
> struct work_struct work;
> @@ -24,6 +27,76 @@ static DEFINE_MUTEX(masq_mutex);
> static unsigned int masq_refcnt __read_mostly;
> static atomic_t masq_worker_count __read_mostly;
>
> +static __be32 *tcp_ts_option_ptr(const struct sk_buff *skb)
> +{
> + const struct tcphdr *th;
> + unsigned char *ptr;
> + unsigned char opsize;
> + unsigned int optlen, offset;
> +
> + th = tcp_hdr(skb);
> + optlen = (th->doff - 5) * 4;
> + ptr = (unsigned char *)(th + 1);
> + offset = 0;
> +
> + while (offset < optlen) {
> + unsigned char opcode = ptr[offset];
> +
> + if (opcode == TCPOPT_EOL)
> + break;
> + if (opcode == TCPOPT_NOP) {
> + offset++;
> + continue;
> + }
> +
> + if (offset + 1 >= optlen)
> + break;
> +
> + opsize = ptr[offset + 1];
> + if (opsize < 2 || offset + opsize > optlen)
> + break;
> +
> + if (opcode == TCPOPT_TIMESTAMP && opsize == TCPOLEN_TIMESTAMP)
> + return (__be32 *)(ptr + offset + 2);
> +
> + offset += opsize;
> + }
> +
> + return NULL;
> +}
> +
> +static void masquerade_update_tcp_ts_offset(struct nf_conn *ct, struct sk_buff *skb)
> +{
> + __be32 *tsptr;
> + struct net *net;
> + struct tcphdr *th;
> + struct tcp_sock *tp;
> + union tcp_seq_and_ts_off st;
> + struct nf_conntrack_tuple *tuple;
> +
> + th = tcp_hdr(skb);
> + net = nf_ct_net(ct);
> + tuple = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
> +
why use reply not original, or do I miss something ?
^ 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