* Re: [PATCH] devlink/param: replace deprecated strcpy() with strscpy()
From: Álvaro Costa @ 2026-05-06 23:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: jiri, David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
open list:DEVLINK, open list
In-Reply-To: <20260506154252.65d673c2@kernel.org>
On Wed, May 6, 2026 at 7:42 PM Jakub Kicinski <kuba@kernel.org> wrote:
> The current code validates the netlink attr is nul-terminated.
> I'm not sure if your patch retains current behavior.
> I am sure, however, that checking whether the change is correct
> is a poor use of everyone's time.
> Please don't send these sort of patches for networking.
> --
> pw-bot: reject
Ok, thank you for the quick feedback!
^ permalink raw reply
* Re: [PATCH 0/8] pull request (net): ipsec 2026-05-05
From: Jakub Kicinski @ 2026-05-06 23:51 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <20260506165035.61964333@kernel.org>
On Wed, 6 May 2026 16:50:35 -0700 Jakub Kicinski wrote:
> On Tue, 5 May 2026 15:22:56 +0200 Steffen Klassert wrote:
> > 5. Harden __xfrm_state_delete() against repeated or inconsistent unhashing
> > of state list nodes by keying the removal on actual list membership and
> > using delete-and-init helpers. From Michal Kosiorek.
>
> Sashiko seems to have extra comments for this but I suspect follow up
> is the way to go there.
I should have made it clear - Claude-shiko:
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260505132326.1362733-4-steffen.klassert@secunet.com
^ permalink raw reply
* Re: [PATCH 0/8] pull request (net): ipsec 2026-05-05
From: Jakub Kicinski @ 2026-05-06 23:50 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <20260505132326.1362733-1-steffen.klassert@secunet.com>
On Tue, 5 May 2026 15:22:56 +0200 Steffen Klassert wrote:
> 5. Harden __xfrm_state_delete() against repeated or inconsistent unhashing
> of state list nodes by keying the removal on actual list membership and
> using delete-and-init helpers. From Michal Kosiorek.
Sashiko seems to have extra comments for this but I suspect follow up
is the way to go there.
^ permalink raw reply
* [PATCH net V2] net: shaper: Reject reparenting of existing nodes
From: Mohsin Bashir @ 2026-05-06 23:37 UTC (permalink / raw)
To: netdev
Cc: alexanderduyck, davem, edumazet, horms, kees, kuba, linux-kernel,
mohsin.bashr, p, pabeni, jiri
From: Mohsin Bashir <hmohsin@meta.com>
When an existing node-scope shaper is moved to a different parent
via the group operation, the framework fails to update the leaves
count on both the old and new parent shapers. Only newly created
nodes (handle.id == NET_SHAPER_ID_UNSPEC) trigger the parent
leaves increment at line 1039.
This causes the parent's leaves counter to diverge from the
actual number of children in the xarray. When the node is later
deleted, pre_del_node() allocates an array sized by the stale
leaves count, but the xarray iteration finds more children than
expected, hitting the WARN_ON_ONCE guard and returning -EINVAL.
Rather than adding reparenting support with complex leaves count
bookkeeping, reject group calls that attempt to change an existing
node's parent. Updates to an existing node's rate or leaves under
the same parent remain permitted. We expect that for any modification
of the topology user should always create new groups and let the
kernel garbage collect the leaf-less nodes.
Fixes: 5d5d4700e75d ("net-shapers: implement NL group operation")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mohsin Bashir <hmohsin@meta.com>
---
Changelog:
V2:
- Add missing maintainer
- Nit: Remove null at the end of fixes tag
- Move reparenting check after parent resolution so updates
that omit the parent argument are not incorrectly rejected
V1: https://lore.kernel.org/netdev/20260505174321.1794689-1-mohsin.bashr@gmail.com/
---
net/shaper/shaper.c | 30 +++++++++++++++++++++++-------
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/net/shaper/shaper.c b/net/shaper/shaper.c
index 94bc9c7382ea..1069fa4eb9f6 100644
--- a/net/shaper/shaper.c
+++ b/net/shaper/shaper.c
@@ -964,15 +964,22 @@ static int __net_shaper_group(struct net_shaper_binding *binding,
int i, ret;
if (node->handle.scope == NET_SHAPER_SCOPE_NODE) {
+ struct net_shaper *cur = NULL;
+
new_node = node->handle.id == NET_SHAPER_ID_UNSPEC;
- if (!new_node && !net_shaper_lookup(binding, &node->handle)) {
- /* The related attribute is not available when
- * reaching here from the delete() op.
- */
- NL_SET_ERR_MSG_FMT(extack, "Node shaper %d:%d does not exists",
- node->handle.scope, node->handle.id);
- return -ENOENT;
+ if (!new_node) {
+ cur = net_shaper_lookup(binding, &node->handle);
+ if (!cur) {
+ /* The related attribute is not available
+ * when reaching here from the delete() op.
+ */
+ NL_SET_ERR_MSG_FMT(extack,
+ "Node shaper %d:%d does not exist",
+ node->handle.scope,
+ node->handle.id);
+ return -ENOENT;
+ }
}
/* When unspecified, the node parent scope is inherited from
@@ -986,6 +993,15 @@ static int __net_shaper_group(struct net_shaper_binding *binding,
return ret;
}
+ if (cur && net_shaper_handle_cmp(&cur->parent,
+ &node->parent)) {
+ NL_SET_ERR_MSG_FMT(extack,
+ "Cannot reparent node shaper %d:%d",
+ node->handle.scope,
+ node->handle.id);
+ return -EOPNOTSUPP;
+ }
+
} else {
net_shaper_default_parent(&node->handle, &node->parent);
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net 1/3] ovpn: reset MAC header before passing skb up
From: patchwork-bot+netdevbpf @ 2026-05-06 23:20 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, edumazet, sd, davem, kuba, pabeni, ralf, qingfang.deng,
andrew+netdev, ptpt52
In-Reply-To: <20260504230305.2681646-2-antonio@openvpn.net>
Hello:
This series was applied to netdev/net.git (main)
by Antonio Quartulli <antonio@openvpn.net>:
On Tue, 5 May 2026 01:03:03 +0200 you wrote:
> From: Qingfang Deng <qingfang.deng@linux.dev>
>
> After decapsulating a packet, the skb->mac_header still points to the
> outer transport header.
>
> Fix this by calling skb_reset_mac_header() in ovpn_netdev_write() to
> ensure the MAC header points to the beginning of
> the inner IP/network packet, as expected by the rest of the stack.
>
> [...]
Here is the summary with links:
- [net,1/3] ovpn: reset MAC header before passing skb up
https://git.kernel.org/netdev/net/c/a200cdbf9593
- [net,2/3] ovpn: ensure packet delivery happens with BH disabled
https://git.kernel.org/netdev/net/c/c539cb30f93f
- [net,3/3] selftests: ovpn: reduce ping count in test.sh
https://git.kernel.org/netdev/net/c/201ba706318d
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] net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memclean
From: Jakub Kicinski @ 2026-05-06 23:16 UTC (permalink / raw)
To: Holger Brunck
Cc: netdev, linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms
In-Reply-To: <20260506111529.2919079-1-holger.brunck@hitachienergy.com>
On Wed, 6 May 2026 13:15:29 +0200 Holger Brunck wrote:
> When the device is removed all allocated resources should be freed.
> In uhdlc_memclean the netdev transmit queue was already stopped. But at
> this point we may have pending skb in the transmit queue which must be
> freed. Therefore iterate over the tx_skbuff pointers and free all
> pending skb. The issue was discovered by sashiko.
And you tested this how?
Given the questionable v1 I'm highly hesitant to accept patches
from you if you can't test them.
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: return NETDEV_TX_OK if skb was freed
From: Jakub Kicinski @ 2026-05-06 23:14 UTC (permalink / raw)
To: Holger Brunck
Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
andrew+netdev@lunn.ch, chleroy@kernel.org, qiang.zhao@nxp.com,
horms@kernel.org
In-Reply-To: <AM0PR06MB1039608A8965FE12520901515F73F2@AM0PR06MB10396.eurprd06.prod.outlook.com>
On Wed, 6 May 2026 09:35:00 +0000 Holger Brunck wrote:
> > On Mon, 4 May 2026 19:44:06 +0200 Holger Brunck wrote:
> > > If the skb was freed in the ucc_hdlc_tx function and the packet marked
> > > as dropped we need to return NETDEV_TX_OK. Otherwise the above layer
> > > will try to requeue an already freed skb.
> >
> > Is this really true? I thought negative returns mean drop.
>
> the API suggest to only use NETDEV_TX_OK or NETDEV_TX_BUSY as return value.
> I checked several drivers and they are usually returning NETDEV_TX_OK if an
> error occurred and the driver consumed the packet. But you are right
> dev_xmit_complete will also return true if the return code is smaller than zero
> and the packet is not requeued. Should I update the commit message or should
> the patch be dropped?
Drop the patch.
^ permalink raw reply
* Re: [PATCH net 2/3] ovpn: ensure packet delivery happens with BH disabled
From: Jakub Kicinski @ 2026-05-06 23:11 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, edumazet, sd, davem, pabeni, ralf, andrew+netdev, horms,
shuah, linux-kselftest
In-Reply-To: <9ffc1db1-3b67-453e-ae43-e986fdad3694@openvpn.net>
On Wed, 6 May 2026 11:00:20 +0200 Antonio Quartulli wrote:
> > ovpn_decrypt_post() {
> > ...
> > if (unlikely(ret < 0))
> > goto drop;
> > ...
> > drop:
> > if (unlikely(skb))
> > dev_dstats_rx_dropped(peer->ovpn->dev);
> > ...
> > }
> >
> > Since dev_dstats_rx_dropped() updates the same per-CPU dstats structure
> > without disabling bottom halves, could it still be vulnerable to softirq
> > preemption and stat corruption?
> >
>
> Actually we were already looking into this.
> However, since this needs a separate analysis, I wanted to get this
> fixed in a follow up patch.
>
> Would it be ok to pull this PR as is, so we don't hold back the
> outstanding fixes?
>
> Then we will address the issue highlighted by Sashiko in a new patch.
> The problem is similar, but may need to be fixed differently.
Ugh, fair. The way the AI formatted the output made me think
it's an error path in the same function, which would make sense
to address with a single patch.. Pulling now.
^ permalink raw reply
* Re: [PATCH net-next 0/4] RDMA/net/ionic: Misc updates
From: Jakub Kicinski @ 2026-05-06 22:59 UTC (permalink / raw)
To: Eric Joyner
Cc: netdev, linux-rdma, Brett Creeley, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Abhijit Gangurde, Allen Hubbe,
Jason Gunthorpe, Leon Romanovsky
In-Reply-To: <20260506041935.1061-1-eric.joyner@amd.com>
On Tue, 5 May 2026 21:19:31 -0700 Eric Joyner wrote:
> Other smaller additions add a devlink parameter to the ionic ethernet
> driver for enabling and disabling RDMA,
My understanding is that the devlink param was expected to change
the configuration of the device. IOW user can enable/disable RDMA
to save internal device resources. You seem to be purely preventing
the auxbus device to be added. So there's nothing gained here compared
to simply not loading the RDMA driver. What am I missing?
^ permalink raw reply
* Re: [PATCH net-next v10 4/4] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
From: Michael S. Tsirkin @ 2026-05-06 22:56 UTC (permalink / raw)
To: Simon Schippers
Cc: willemdebruijn.kernel, jasowang, andrew+netdev, davem, edumazet,
kuba, pabeni, eperezma, leiyang, stephen, jon, tim.gebauer,
netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20260506181909-mutt-send-email-mst@kernel.org>
On Wed, May 06, 2026 at 06:28:06PM -0400, Michael S. Tsirkin wrote:
> On Wed, May 06, 2026 at 04:10:33PM +0200, Simon Schippers wrote:
> > This commit prevents tail-drop when a qdisc is present and the ptr_ring
> > becomes full. Once an entry is successfully produced and the ptr_ring
> > reaches capacity, the netdev queue is stopped instead of dropping
> > subsequent packets. If no qdisc is present, the previous tail-drop
> > behavior is preserved.
> >
> > If producing an entry fails anyways due to a race, tun_net_xmit() drops
> > the packet. Such races are expected because LLTX is enabled and the
> > transmit path operates without the usual locking.
> >
> > The __tun_wake_queue() function of the consumer races with the producer
> > for waking/stopping the netdev queue, which could result in a stalled
> > queue. Therefore, an smp_mb__after_atomic() is introduced that pairs
> > with the smp_mb() of the consumer. It follows the principle of store
> > buffering described in tools/memory-model/Documentation/recipes.txt:
> >
> > - The producer in tun_net_xmit() first sets __QUEUE_STATE_DRV_XOFF,
> > followed by an smp_mb__after_atomic() (= smp_mb()), and then reads the
> > ring with __ptr_ring_produce_peek().
> >
> > - The consumer in __tun_wake_queue() first writes zero to the ring in
> > __ptr_ring_consume(), followed by an smp_mb(), and then reads the queue
> > status with netif_tx_queue_stopped().
> >
> > => Following the aforementioned principle, it is impossible for the
> > producer to see a full ring (and therefore not wake the queue on the
> > re-check) while the consumer simultaneously fails to see a stopped
> > queue (and therefore also does not wake it).
> >
> > Benchmarks:
> > The benchmarks show a slight regression in raw transmission performance
> > when using two sending threads. Packet loss also occurs only in the
> > two-thread sending case; no packet loss was observed with a single
> > sending thread.
> >
> > Test setup:
> > AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
> > Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2
> > mitigations disabled.
> >
> > Note for tap+vhost-net:
> > XDP drop program active in VM -> ~2.5x faster; slower for tap due to
> > more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)
> >
> > +--------------------------+--------------+----------------+----------+
> > | 1 thread | Stock | Patched with | diff |
> > | sending | | fq_codel qdisc | |
> > +------------+-------------+--------------+----------------+----------+
> > | TAP | Received | 1.132 Mpps | 1.133 Mpps | +0.1% |
> > | +-------------+--------------+----------------+----------+
> > | | Lost/s | 3.765 Mpps | 0 pps | |
> > +------------+-------------+--------------+----------------+----------+
> > | TAP | Received | 3.857 Mpps | 3.905 Mpps | +1.2% |
> > | +-------------+--------------+----------------+----------+
> > | +vhost-net | Lost/s | 0.802 Mpps | 0 pps | |
> > +------------+-------------+--------------+----------------+----------+
> >
> > +--------------------------+--------------+----------------+----------+
> > | 2 threads | Stock | Patched with | diff |
> > | sending | | fq_codel qdisc | |
> > +------------+-------------+--------------+----------------+----------+
> > | TAP | Received | 1.115 Mpps | 1.092 Mpps | -2.1% |
> > | +-------------+--------------+----------------+----------+
> > | | Lost/s | 8.490 Mpps | 359 pps | |
> > +------------+-------------+--------------+----------------+----------+
> > | TAP | Received | 3.664 Mpps | 3.549 Mpps | -3.1% |
> > | +-------------+--------------+----------------+----------+
> > | +vhost-net | Lost/s | 5.330 Mpps | 832 pps | |
> > +------------+-------------+--------------+----------------+----------+
> >
> > Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> > Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> > Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> > ---
> > drivers/net/tun.c | 25 +++++++++++++++++++++++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index fc358c4c355b..d9ffbf88cfd8 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -1018,6 +1018,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> > struct netdev_queue *queue;
> > struct tun_file *tfile;
> > int len = skb->len;
> > + int ret;
> >
> > rcu_read_lock();
> > tfile = rcu_dereference(tun->tfiles[txq]);
> > @@ -1072,13 +1073,33 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> >
> > nf_reset_ct(skb);
> >
> > - if (ptr_ring_produce(&tfile->tx_ring, skb)) {
> > + queue = netdev_get_tx_queue(dev, txq);
> > +
> > + spin_lock(&tfile->tx_ring.producer_lock);
> > + ret = __ptr_ring_produce(&tfile->tx_ring, skb);
> > + if (!qdisc_txq_has_no_queue(queue) &&
> > + (__ptr_ring_produce_peek(&tfile->tx_ring) || ret)) {
> > + netif_tx_stop_queue(queue);
> > + /* Paired with smp_mb() in __tun_wake_queue() */
> > + smp_mb__after_atomic();
> > + if (!__ptr_ring_produce_peek(&tfile->tx_ring))
> > + netif_tx_wake_queue(queue);
> > + }
> > + spin_unlock(&tfile->tx_ring.producer_lock);
> > +
>
> There's a weird corner case here when tx_queue_len is 0
> but a qdisc has been configured - it looks like that
> currently it just drops all packets, with this change,
> the qdisc will get stuck permanently.
>
> I suspect just checking tx_ring.size should fix it.
> Or if you feel adventurous, change return code for __ptr_ring_produce
> to distinguish between "no ring" and "no space".
__ptr_ring_produce_peek really.
>
> > + if (ret) {
> > + /* This should be a rare case if a qdisc is present, but
> > + * can happen due to lltx.
> > + * Since skb_tx_timestamp(), skb_orphan(),
> > + * run_ebpf_filter() and pskb_trim() could have tinkered
> > + * with the SKB, returning NETDEV_TX_BUSY is unsafe and
> > + * we must drop instead.
> > + */
> > drop_reason = SKB_DROP_REASON_FULL_RING;
> > goto drop;
> > }
> >
> > /* dev->lltx requires to do our own update of trans_start */
> > - queue = netdev_get_tx_queue(dev, txq);
> > txq_trans_cond_update(queue);
> >
> > /* Notify and wake up reader process */
> > --
> > 2.43.0
^ permalink raw reply
* Re: [Patch net-next v1 2/7] r8169: add support for multi rx queues
From: Jakub Kicinski @ 2026-05-06 22:54 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, pabeni,
horms, netdev, linux-kernel
In-Reply-To: <20260506081326.767-3-javen_xu@realsil.com.cn>
On Wed, 6 May 2026 16:13:20 +0800 javen wrote:
> This patch adds support for multi rx queues. RSS requires multi rx
> queues to receive packets. So we need struct rtl8169_rx_ring for each
> queue.
../drivers/net/ethernet/realtek/r8169_main.c:4994:16: expected unsigned int
../drivers/net/ethernet/realtek/r8169_main.c:4994:16: got restricted __le32
../drivers/net/ethernet/realtek/r8169_main.c:5032:26: warning: cast to restricted __le32
../drivers/net/ethernet/realtek/r8169_main.c:5046:34: warning: cast to restricted __le32
--
pw-bot: cr
^ permalink raw reply
* Re: [Patch net-next v1 1/7] r8169: add support for multi irqs
From: Jakub Kicinski @ 2026-05-06 22:53 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, pabeni,
horms, netdev, linux-kernel
In-Reply-To: <20260506081326.767-2-javen_xu@realsil.com.cn>
On Wed, 6 May 2026 16:13:19 +0800 javen wrote:
> RSS uses multi rx queues to receive packets, and each rx queue needs one
> irq and napi. So this patch adds support for multi irqs and napi here.
drivers/net/ethernet/realtek/r8169_main.c:5205:16: warning: variable 'irqflags' set but not used [-Wunused-but-set-variable]
5205 | unsigned long irqflags;
| ^
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: five small fixes and cleanups
From: Jacob Keller @ 2026-05-06 22:53 UTC (permalink / raw)
To: Aleksandr Loktionov, intel-wired-lan, anthony.l.nguyen; +Cc: netdev
In-Reply-To: <20260504142451.4161845-1-aleksandr.loktionov@intel.com>
On 5/4/2026 7:24 AM, Aleksandr Loktionov wrote:
> Three correctness fixes and two cleanups for the ice driver.
>
> Patch 1 corrects a kernel-doc comment in ice_ptp_hw.h that described the
> ETH56G MAC Rx offset field as unsigned when it is signed (trivial doc fix,
> no functional change).
>
> Patch 2 removes the PF_SB_REM_DEV_CTL sideband register write from
> ice_ptp_init_phc_e82x(). PHY access is enabled by default on E82X and
> the register write was a leftover from an earlier SWITCH_MODE workaround
> that is no longer needed.
>
> Patch 3 renames ICE_SMA2_UFL2_RX_DIS to ICE_SMA2_UFL2_RX_EN to match
> the actual active-high hardware semantics and inverts the three use sites
> in ice_dpll.c so that the logic remains correct.
>
> Patch 4 replaces the static per-type frequency tables for CGU pins with a
> single DPLL_PIN_FREQUENCY_RANGE(1, 25 MHz) entry. The firmware defines
> an any_freq capability for configurable CGU inputs, but the old tables
> restricted users to 1 PPS or 10 MHz. GNSS pins retain a 1 PPS-only
> entry since they are physically constrained.
>
> Patch 5 exports ice_dcb_need_recfg() and calls it in the four SW LLDP
> netlink setters instead of memcmp() on a non-packed struct, which is
> undefined behaviour due to uninitialised padding bytes. The redundant
> memcmp in ice_pf_dcb_cfg() is removed since callers now guard it.
>
Some of these seem like they belong as net fixes, not cleanups
targetting next.
Specifically patch 3 and 4 I feel should be separated. Could you please
either justify why those issues are not "fixes" worthy of net, or
separate them into their own series?
Thanks,
Jake
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-06
From: patchwork-bot+netdevbpf @ 2026-05-06 22:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260506204553.58686-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 6 May 2026 16:45:53 -0400 you wrote:
> The following changes since commit b89e0100a5f6885f9748bbacc3f4e3bcff654e4c:
>
> Merge tag 'wireless-2026-05-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless (2026-05-06 07:29:31 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-05-06
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth 2026-05-06
https://git.kernel.org/netdev/net/c/bd75e1003d3e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] i40e: Fix i40e_debug() to use struct i40e_hw argument
From: Mohamed Khalfella @ 2026-05-06 22:49 UTC (permalink / raw)
To: Jacob Keller
Cc: Paul Menzel, Tony Nguyen, Przemek Kitszel, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
In-Reply-To: <10637b35-766c-454b-b9fc-ac9e6df36da5@intel.com>
On Wed 2026-05-06 14:57:26 -0700, Jacob Keller wrote:
> On 4/29/2026 9:52 AM, Mohamed Khalfella wrote:
> > On Wed 2026-04-29 13:02:00 +0200, Paul Menzel wrote:
> >> Dear Mohamed,
> >>
> >>
> >> Thank you for your patch.
> >>
> >> Am 28.04.26 um 20:14 schrieb Mohamed Khalfella:
> >>> i40e_debug() macro takes struct i40e_hw *h as first argument. But the
> >>> macro body uses hw instead of h. This has been working so far because hw
> >>> happen to be the name of the variable in the context where the marco is
> >>
> >> marco → ma*cr*o
> >
> > Good catch. Also 'happen' should be 'happens'
> >
> >>
> >>> expanded. Fix the macro to use the passed argument.
> >>
> >> I’d add a Fixes: tag, but the maintainers might have more input.
> >
> > Yes, I should have added Fixes: tag. I will leave it to the maintainer
> > to decide if v2 is needed to fix the spelling mistakes and add Fixes
> > tag.
> >
> > Fixes: 5dfd37c37a44 ("i40e: Split i40e_osdep.h")
> >
> Please send a v2 with the fixes tag and typo. It will make it easier to
> avoid losing this data.
Done https://lore.kernel.org/all/20260506224123.691160-1-mkhalfella@purestorage.com/
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v4] ice: wait for reset completion in ice_resume()
From: Jacob Keller @ 2026-05-06 22:43 UTC (permalink / raw)
To: Aaron Ma, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
Cc: Akeem G Abodunrin, Jesse Brandeburg, intel-wired-lan,
aleksandr.loktionov, kohei, Paul Menzel
In-Reply-To: <20260429034849.1686650-1-aaron.ma@canonical.com>
On 4/28/2026 8:48 PM, Aaron Ma via Intel-wired-lan wrote:
> ice_resume() schedules an asynchronous PF reset and returns
> immediately. The reset runs later in ice_service_task(). If
> userspace tries to bring up the net device before the reset
> finishes, ice_open() fails with -EBUSY:
>
> ice_resume()
> ice_schedule_reset() # sets ICE_PFR_REQ, returns
> ...
> ice_open()
> ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY
> ...
> ice_service_task()
> ice_do_reset()
> ice_rebuild() # clears ICE_PFR_REQ, too late
>
> Reproduced on E800 series NICs during suspend/resume with irdma
> enabled, where the aux device probe widens the race window.
>
> ice 0000:81:00.0: can't open net device while reset is in progress
>
> Add a best-effort wait (10s timeout, matching ice_devlink_info_get())
> for the reset to complete before returning from ice_resume(). In
> practice the reset completes in ~300ms.
>
> Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
> Cc: stable@vger.kernel.org
> Reviewed-by: Kohei Enju <kohei@enjuk.jp>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
This doesn't specify a tree target, but given the cc to stable and the
fixes tag, I think this belongs on net, so I'll queue it for the iwl-net
dev-queue.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH net-next 6/9] net: atlantic: implement AQC113 L2/L3/L4 RX filter management filter management management
From: Vadim Fedorenko @ 2026-05-06 22:43 UTC (permalink / raw)
To: sukhdeeps, netdev
Cc: irusskikh, epomozov, richardcochran, andrew+netdev, davem,
edumazet, kuba, pabeni, linux-kernel
In-Reply-To: <20260506135706.2834-7-sukhdeeps@marvell.com>
On 06/05/2026 14:57, sukhdeeps@marvell.com wrote:
> From: Sukhdeep Singh <sukhdeeps@marvell.com>
>
> Implement complete RX filter management for AQC113 hardware:
>
> - Add tag-based filter policy with reference-counted sharing, allowing
> multiple filter rules to share the same L3 or L4 hardware filter
> when their match criteria are identical.
> - Implement L3 (IPv4/IPv6 source/destination address and protocol)
> filter find, get (program HW and increment refcount), and put
> (decrement refcount and clear HW when last user releases).
> - Implement L4 (TCP/UDP/SCTP source/destination port) filter
> management with the same find/get/put pattern.
> - Add combined L3L4 filter configuration that translates legacy
> aq_rx_filter_l3l4 commands into AQC113 separate L3+L4 filter
> programming with Action Resolver Table (ART) entries.
> - Add L2 ethertype filter set/clear with tag-based ART integration.
> - Add MAC address setup using firmware-provided L2 filter base index.
>
> Update hardware initialization:
> - Use firmware-reported ART section base and count instead of
> hardcoded 0xFFFF section enable.
> - Enable L3 v6/v4 select mode for simultaneous IPv4/IPv6 filtering.
> - Initialize L3L4 filter indices to -1 on reset.
>
> Wire up hw_filter_l2_set, hw_filter_l2_clear, hw_filter_l3l4_set,
> hw_set_mac_address, hw_get_version, and hw_get_regs in hw_atl2_ops.
>
> Signed-off-by: Sukhdeep Singh <sukhdeeps@marvell.com>
> ---
> .../net/ethernet/aquantia/atlantic/aq_hw.h | 2 +
> .../aquantia/atlantic/hw_atl2/hw_atl2.c | 582 +++++++++++++++++-
> 2 files changed, 580 insertions(+), 4 deletions(-)
[...]
>
> @@ -380,6 +422,9 @@ static void hw_atl2_hw_init_new_rx_filters(struct aq_hw_s *self)
> {
> u8 *prio_tc_map = self->aq_nic_cfg->prio_tc_map;
> struct hw_atl2_priv *priv = self->priv;
> + u32 art_first_sec, art_last_sec;
> + u32 art_sections;
> + u32 art_mask = 0;
no need to init variable which is overwritten later ...
> u16 action;
> u8 index;
> int i;
> @@ -394,9 +439,14 @@ static void hw_atl2_hw_init_new_rx_filters(struct aq_hw_s *self)
> * REC entry is used for further processing. If multiple entries match,
> * the lowest REC entry, Action field will be selected.
> */
> - hw_atl2_rpf_act_rslvr_section_en_set(self, 0xFFFF);
> + art_last_sec = priv->art_base_index / 8 + priv->art_count / 8;
> + art_first_sec = priv->art_base_index / 8;
> + art_mask = (BIT(art_last_sec) - 1) - (BIT(art_first_sec) - 1);
... here
> + art_sections = hw_atl2_rpf_act_rslvr_section_en_get(self) | art_mask;
> + hw_atl2_rpf_act_rslvr_section_en_set(self, art_sections);
> + hw_atl2_rpf_l3_v6_v4_select_set(self, 1);
> hw_atl2_rpfl2_uc_flr_tag_set(self, HW_ATL2_RPF_TAG_BASE_UC,
> - HW_ATL2_MAC_UC);
> + priv->l2_filters_base_index);
> hw_atl2_rpfl2_bc_flr_tag_set(self, HW_ATL2_RPF_TAG_BASE_UC);
>
> /* FW reserves the beginning of ART, thus all driver entries must
> @@ -530,6 +580,35 @@ static int hw_atl2_hw_init_rx_path(struct aq_hw_s *self)
> return aq_hw_err_from_flags(self);
> }
>
> +static int hw_atl2_hw_mac_addr_set(struct aq_hw_s *self, const u8 *mac_addr)
> +{
> + struct hw_atl2_priv *priv = self->priv;
> + u32 location = priv->l2_filters_base_index;
> + unsigned int h = 0U;
> + unsigned int l = 0U;
> + int err = 0;
here again, h, l and err are not used with init values.
> +
> + if (!mac_addr) {
> + err = -EINVAL;
> + goto err_exit;
> + }
> + h = (mac_addr[0] << 8) | (mac_addr[1]);
> + l = (mac_addr[2] << 24) | (mac_addr[3] << 16) |
> + (mac_addr[4] << 8) | mac_addr[5];
> +
> + hw_atl_rpfl2_uc_flr_en_set(self, 0U, location);
> + hw_atl_rpfl2unicast_dest_addresslsw_set(self, l, location);
> + hw_atl_rpfl2unicast_dest_addressmsw_set(self, h, location);
> + hw_atl_rpfl2unicast_flr_act_set(self, 1U, location);
> + hw_atl2_rpfl2_uc_flr_tag_set(self, HW_ATL2_RPF_TAG_BASE_UC, location);
> + hw_atl_rpfl2_uc_flr_en_set(self, 1U, location);
> +
> + err = aq_hw_err_from_flags(self);
> +
> +err_exit:
> + return err;
> +}
> +
> static int hw_atl2_hw_init(struct aq_hw_s *self, const u8 *mac_addr)
> {
> static u32 aq_hw_atl2_igcr_table_[4][2] = {
[...]
^ permalink raw reply
* Re: [PATCH] devlink/param: replace deprecated strcpy() with strscpy()
From: Jakub Kicinski @ 2026-05-06 22:42 UTC (permalink / raw)
To: Álvaro Costa
Cc: jiri, David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
open list:DEVLINK, open list
In-Reply-To: <20260506211415.16343-1-alvaroc.dev@gmail.com>
On Wed, 6 May 2026 18:14:11 -0300 Álvaro Costa wrote:
> Replace strcpy() call used to extract a string parameter from param_data
> with strscpy(). Since strscpy() already performs bounds checking and
> ensures the destination string is NUL-terminated, remove the string
> length check as well.
The current code validates the netlink attr is nul-terminated.
I'm not sure if your patch retains current behavior.
I am sure, however, that checking whether the change is correct
is a poor use of everyone's time.
Please don't send these sort of patches for networking.
--
pw-bot: reject
^ permalink raw reply
* [PATCH v2] i40e: Fix i40e_debug() to use struct i40e_hw argument
From: Mohamed Khalfella @ 2026-05-06 22:41 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Mohamed Khalfella, Aleksandr Loktionov, Paul Menzel, Jacob Keller,
intel-wired-lan, netdev, linux-kernel
i40e_debug() macro takes struct i40e_hw *h as first argument. But the
macro body uses hw instead of h. This has been working so far because hw
happens to be the name of the variable in the context where the macro is
expanded. Fix the macro to use the passed argument.
Fixes: 5dfd37c37a44 ("i40e: Split i40e_osdep.h")
Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
drivers/net/ethernet/intel/i40e/i40e_debug.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debug.h b/drivers/net/ethernet/intel/i40e/i40e_debug.h
index e9871dfb32bd4..01fd70db90866 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debug.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_debug.h
@@ -42,7 +42,7 @@ struct device *i40e_hw_to_dev(struct i40e_hw *hw);
#define i40e_debug(h, m, s, ...) \
do { \
if (((m) & (h)->debug_mask)) \
- dev_info(i40e_hw_to_dev(hw), s, ##__VA_ARGS__); \
+ dev_info(i40e_hw_to_dev(h), s, ##__VA_ARGS__); \
} while (0)
#endif /* _I40E_DEBUG_H_ */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 09/12] gpio: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-05-06 22:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, daniel, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, mcoquelin.stm32, me, prabhakar.mahadev-lad.rj,
richardcochran, rohan.g.thomas, sdf, siyanteng, weishangjuan,
wens, netdev, bpf, linux-arm-msm, devicetree, linux-gpio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <ec5765aa-b830-468b-8965-a95fbe020065@lunn.ch>
On 5/6/26 4:43 PM, Andrew Lunn wrote:
>> To be clear, the reason you're asking is that you're suggesting
>> we might want to model the GPIO controller differently, correct?
>
> Correct.
>
>> I.e., model it as *not* associated with the embedded PCIe
>> functions. Then we need to think about what its parent device
>> would be (the power control device, which I think somehow
>> duplicates the switch device?).
>
> Logically, the GPIO controller cannot be part of a downstream
> function, if you need to use the GPIO controller to turn the
> downstream function on.
Yes you're right, though the PCIe power controller functions
before the PCIe switch is enabled, and uses I2C to communicate
with the host.
> Logically, the GPIO controller needs to be above the switch downstream
> end points. Where above, i don't know. Which is why i was asking about
> where it appears in the address spaces.
You are touching on an issue we have faced since we started on
this earlier in the year. Our objective was to enable the eMACs,
but there was no device representing the "chip" (which holds the
switch and the GPIO controller, etc.). The TC956x is more than
just a PCIe switch, and more than just two Ethernet MACs. The
vendor code handles some of this between PCIe functions with
some reference counting and perhaps other things.
Eventually we settled on the model we have presented, which
creates a device for each function and lets one of them take
care of common "chip" things (including creating the GPIO
auxiliary device). The function device driver creates a
new auxiliary device to represent the MAC for each function.
I also considered modeling the TC956x as a remoteproc, but have
been reluctant to really pursue that.
> But i also don't know too much about PCI, i'm used to SoCs with simple
> linear MMIO.
I'm no PCI expert either, but I'm learning.
> From the little i know, it is more than what address space does the
> GPIO appear in. Its also, what enumerable entity does it appear in
> within the PCI bus. Because its the enumeration which is going to
> trigger a driver load, which can then drive the GPIO controller.
>
> Or, something more radical, you make the PCIe power controller an MFD,
> instantiating both the power controller and a GPIO controller over the
> I2C bus. GPIO access will not be as fast, but is there anything here
> which needs to be fast?
I considered that, but opted not to mess with the PCIe power controller
driver.
It's only asserting resets in the RB3gen2, so I don't the speed is a
major factor.
-Alex
>
> Andrew
^ permalink raw reply
* Re: [PATCH net 06/12] selftests: drv-net: add shaper test for duplicate leaves
From: Jakub Kicinski @ 2026-05-06 22:35 UTC (permalink / raw)
To: Breno Leitao
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
linux-kselftest
In-Reply-To: <aftup9Pe-RnDZVUi@gmail.com>
On Wed, 6 May 2026 09:40:07 -0700 Breno Leitao wrote:
> > @@ -453,7 +471,10 @@ from lib.py import cmd
> > basic_groups,
> > qgroups,
> > delegation,
> > - queue_update], args=(cfg, NetshaperFamily()))
> > + queue_update,
> > + dup_leaves
> > + ],
>
> Nit: dup_leaves], on a single line matches the surrounding style and
> avoids the dangling bracket on its own line. Not worth a respin on its
> own.
It was intentional to avoid having to touch the lines when adding more
tests. Now that I think about it again I should probably keep the tests
sorted and add a trailing ,
^ permalink raw reply
* Re: [PATCH net 04/12] net: shaper: try to avoid violating RCU
From: Jakub Kicinski @ 2026-05-06 22:35 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, edumazet, andrew+netdev, horms, shuah, linux-kselftest,
davem
In-Reply-To: <af591664-bb26-4b1b-93cf-cbcc68763d5e@redhat.com>
On Wed, 6 May 2026 17:32:10 +0200 Paolo Abeni wrote:
> On 5/6/26 5:22 PM, Paolo Abeni wrote:
> > On 5/6/26 2:06 AM, Jakub Kicinski wrote:
> >> net_shaper_commit() overrides nodes which may be concurrently read
> >> under RCU. This is not a huge deal since the entries only contain
> >> config, worst case user will see inconsistent config params. But
> >> we should try to avoid this obvious RCU violation. Try to allocate
> >> a new node. Since commit() can't fail fall back to overriding.
> >>
> >> Full fix is probably not worth the complexity, struct net_shaper
> >> is around 80B, and the allocation is with GFP_KERNEL.
> >
> > I'm not sure if even this variant is worthy?!? The scheduler tree dump
> > could be still inconsistent, as the dump is not atomic. IMHO e.g.
> > inconsistent weights in the same WRR group would be as bad as
> > inconsistent values inside the single shaper.
>
> I mean: I would simply avoid addressing this RCU violation.
Alright. I'll add a comment instead (fix just the ordering WRT
to the VALID flag)
^ permalink raw reply
* Re: [PATCH net 01/12] net: shaper: drop redundant xa_lock() bracketing
From: Jakub Kicinski @ 2026-05-06 22:33 UTC (permalink / raw)
To: Paolo Abeni
Cc: davem, netdev, edumazet, andrew+netdev, horms, shuah,
linux-kselftest
In-Reply-To: <ae14591f-f93e-4947-b3d4-af4c441d8229@redhat.com>
On Wed, 6 May 2026 17:30:32 +0200 Paolo Abeni wrote:
> On 5/6/26 2:06 AM, Jakub Kicinski wrote:
> > The shaper insertion code is written in a way that suggests that
> > perhaps it was expecting readers to be fenced off by xa_lock.
>
> FTR, the code was shaped (pun intended :) that way to avoid acquiring
> multiple times the xa_lock when not needed. Sort of evil early optimization.
Ah, that makes more sense, I guess. Do you prefer me to drop this patch?
The XA lock is guaranteed not to be contended since we're under the
netdev mutex..
^ permalink raw reply
* Re: [PATCH net-next v10 4/4] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
From: Michael S. Tsirkin @ 2026-05-06 22:28 UTC (permalink / raw)
To: Simon Schippers
Cc: willemdebruijn.kernel, jasowang, andrew+netdev, davem, edumazet,
kuba, pabeni, eperezma, leiyang, stephen, jon, tim.gebauer,
netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20260506141033.180450-5-simon.schippers@tu-dortmund.de>
On Wed, May 06, 2026 at 04:10:33PM +0200, Simon Schippers wrote:
> This commit prevents tail-drop when a qdisc is present and the ptr_ring
> becomes full. Once an entry is successfully produced and the ptr_ring
> reaches capacity, the netdev queue is stopped instead of dropping
> subsequent packets. If no qdisc is present, the previous tail-drop
> behavior is preserved.
>
> If producing an entry fails anyways due to a race, tun_net_xmit() drops
> the packet. Such races are expected because LLTX is enabled and the
> transmit path operates without the usual locking.
>
> The __tun_wake_queue() function of the consumer races with the producer
> for waking/stopping the netdev queue, which could result in a stalled
> queue. Therefore, an smp_mb__after_atomic() is introduced that pairs
> with the smp_mb() of the consumer. It follows the principle of store
> buffering described in tools/memory-model/Documentation/recipes.txt:
>
> - The producer in tun_net_xmit() first sets __QUEUE_STATE_DRV_XOFF,
> followed by an smp_mb__after_atomic() (= smp_mb()), and then reads the
> ring with __ptr_ring_produce_peek().
>
> - The consumer in __tun_wake_queue() first writes zero to the ring in
> __ptr_ring_consume(), followed by an smp_mb(), and then reads the queue
> status with netif_tx_queue_stopped().
>
> => Following the aforementioned principle, it is impossible for the
> producer to see a full ring (and therefore not wake the queue on the
> re-check) while the consumer simultaneously fails to see a stopped
> queue (and therefore also does not wake it).
>
> Benchmarks:
> The benchmarks show a slight regression in raw transmission performance
> when using two sending threads. Packet loss also occurs only in the
> two-thread sending case; no packet loss was observed with a single
> sending thread.
>
> Test setup:
> AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
> Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2
> mitigations disabled.
>
> Note for tap+vhost-net:
> XDP drop program active in VM -> ~2.5x faster; slower for tap due to
> more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)
>
> +--------------------------+--------------+----------------+----------+
> | 1 thread | Stock | Patched with | diff |
> | sending | | fq_codel qdisc | |
> +------------+-------------+--------------+----------------+----------+
> | TAP | Received | 1.132 Mpps | 1.133 Mpps | +0.1% |
> | +-------------+--------------+----------------+----------+
> | | Lost/s | 3.765 Mpps | 0 pps | |
> +------------+-------------+--------------+----------------+----------+
> | TAP | Received | 3.857 Mpps | 3.905 Mpps | +1.2% |
> | +-------------+--------------+----------------+----------+
> | +vhost-net | Lost/s | 0.802 Mpps | 0 pps | |
> +------------+-------------+--------------+----------------+----------+
>
> +--------------------------+--------------+----------------+----------+
> | 2 threads | Stock | Patched with | diff |
> | sending | | fq_codel qdisc | |
> +------------+-------------+--------------+----------------+----------+
> | TAP | Received | 1.115 Mpps | 1.092 Mpps | -2.1% |
> | +-------------+--------------+----------------+----------+
> | | Lost/s | 8.490 Mpps | 359 pps | |
> +------------+-------------+--------------+----------------+----------+
> | TAP | Received | 3.664 Mpps | 3.549 Mpps | -3.1% |
> | +-------------+--------------+----------------+----------+
> | +vhost-net | Lost/s | 5.330 Mpps | 832 pps | |
> +------------+-------------+--------------+----------------+----------+
>
> Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> ---
> drivers/net/tun.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index fc358c4c355b..d9ffbf88cfd8 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1018,6 +1018,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> struct netdev_queue *queue;
> struct tun_file *tfile;
> int len = skb->len;
> + int ret;
>
> rcu_read_lock();
> tfile = rcu_dereference(tun->tfiles[txq]);
> @@ -1072,13 +1073,33 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>
> nf_reset_ct(skb);
>
> - if (ptr_ring_produce(&tfile->tx_ring, skb)) {
> + queue = netdev_get_tx_queue(dev, txq);
> +
> + spin_lock(&tfile->tx_ring.producer_lock);
> + ret = __ptr_ring_produce(&tfile->tx_ring, skb);
> + if (!qdisc_txq_has_no_queue(queue) &&
> + (__ptr_ring_produce_peek(&tfile->tx_ring) || ret)) {
> + netif_tx_stop_queue(queue);
> + /* Paired with smp_mb() in __tun_wake_queue() */
> + smp_mb__after_atomic();
> + if (!__ptr_ring_produce_peek(&tfile->tx_ring))
> + netif_tx_wake_queue(queue);
> + }
> + spin_unlock(&tfile->tx_ring.producer_lock);
> +
There's a weird corner case here when tx_queue_len is 0
but a qdisc has been configured - it looks like that
currently it just drops all packets, with this change,
the qdisc will get stuck permanently.
I suspect just checking tx_ring.size should fix it.
Or if you feel adventurous, change return code for __ptr_ring_produce
to distinguish between "no ring" and "no space".
> + if (ret) {
> + /* This should be a rare case if a qdisc is present, but
> + * can happen due to lltx.
> + * Since skb_tx_timestamp(), skb_orphan(),
> + * run_ebpf_filter() and pskb_trim() could have tinkered
> + * with the SKB, returning NETDEV_TX_BUSY is unsafe and
> + * we must drop instead.
> + */
> drop_reason = SKB_DROP_REASON_FULL_RING;
> goto drop;
> }
>
> /* dev->lltx requires to do our own update of trans_start */
> - queue = netdev_get_tx_queue(dev, txq);
> txq_trans_cond_update(queue);
>
> /* Notify and wake up reader process */
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH v5 net-next 02/15] dt-bindings: net: dsa: add NETC switch
From: Rob Herring (Arm) @ 2026-05-06 22:22 UTC (permalink / raw)
To: Wei Fang
Cc: linux-kernel, chleroy, edumazet, frank.li, kuba, netdev,
vladimir.oltean, devicetree, linux, conor+dt, horms, davem,
andrew+netdev, xiaoning.wang, pabeni, krzk+dt, linuxppc-dev,
claudiu.manoil, f.fainelli, linux-arm-kernel, imx
In-Reply-To: <20260430024945.3413973-3-wei.fang@nxp.com>
On Thu, 30 Apr 2026 10:49:32 +0800, Wei Fang wrote:
> Add bindings for NETC switch. This switch is a PCIe function of NETC IP,
> it supports advanced QoS with 8 traffic classes and 4 drop resilience
> levels, and a full range of TSN standards capabilities. The switch CPU
> port connects to an internal ENETC port, which is also a PCIe function
> of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
> of a back-to-back MAC, because the "pseudo MAC" provides the delineation
> between switch and ENETC, this translates to lower power (less logic and
> memory) and lower delay (as there is no serialization delay across this
> link).
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/net/dsa/nxp,netc-switch.yaml | 127 ++++++++++++++++++
> 1 file changed, 127 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ 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