* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Jakub Kicinski @ 2026-04-12 17:51 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Marek Vasut, netdev, stable, David S. Miller, Andrew Lunn,
Eric Dumazet, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Yicong Hui, linux-kernel, Thomas Gleixner
In-Reply-To: <2558832d-c821-436d-898d-b708c5e0a228@nabladev.com>
On Sun, 12 Apr 2026 18:27:28 +0200 Marek Vasut wrote:
> On 4/12/26 6:01 PM, Jakub Kicinski wrote:
> > On Wed, 8 Apr 2026 18:24:58 +0200 Marek Vasut wrote:
> >> If CONFIG_PREEMPT_RT=y is set AND the driver executes ks8851_irq() AND
> >> KSZ_ISR register bit IRQ_RXI is set AND ks8851_rx_pkts() detects that
> >> there are packets in the RX FIFO, then netdev_alloc_skb_ip_align() is
> >> called to allocate SKBs. If netdev_alloc_skb_ip_align() is called with
> >> BH enabled, local_bh_enable() at the end of netdev_alloc_skb_ip_align()
> >> will call __local_bh_enable_ip(), which will call __do_softirq(), which
> >> may trigger net_tx_action() softirq, which may ultimately call the xmit
> >> callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try
> >> to lock struct ks8851_net_par .lock spinlock, which is already locked
> >> by ks8851_irq() from which ks8851_start_xmit_par() was called. This
> >> leads to a deadlock, which is reported by the kernel, including a trace
> >> listed below.
> >
> > lock_par is a spinlock, and AFAIU softirqs run in their on thread on RT.
> > I'm not following.
>
> Please look at the backtrace in the commit message, this part, please
> read from bottom to top to observe the failure in chronological order.
> It does not seem the handle_softirqs() is running in its own thread,
> separate from the IRQ thread ?
>
> rt_spin_lock from ks8851_start_xmit_par+0x68/0x1a0
> ks8851_start_xmit_par from netdev_start_xmit+0x1c/0x40 <---- this
> tries to grab the same PAR spinlock, and deadlocks
> netdev_start_xmit from dev_hard_start_xmit+0xec/0x1b0
> dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
> sch_direct_xmit from __qdisc_run+0x20c/0x4fc
> __qdisc_run from qdisc_run+0x1c/0x28
> qdisc_run from net_tx_action+0x1f4/0x244
> net_tx_action from handle_softirqs+0x1c0/0x29c
> handle_softirqs from __local_bh_enable_ip+0xdc/0xf4
> __local_bh_enable_ip from __netdev_alloc_skb+0x140/0x194
> __netdev_alloc_skb from ks8851_irq+0x348/0x4d8 <---- this is called
> from ks8851_rx_pkts() via netdev_alloc_skb_ip_align()
> ks8851_irq from irq_thread_fn+0x24/0x64 <-------- this here runs with
> the PAR spinlock held
>
> > The patch looks way to "advanced" for a driver. Something is going
> > very wrong here. Or the commit message must be updated to explain
> > it better to people like me. Or both.
>
> Does the backtrace make the problem clearer, with the annotation above ?
Sebastian, do you have any recommendation here? tl;dr is that the driver does
spin_lock_irqsave()
__netdev_alloc_skb()
spin_unlock_irqrestore()
And __netdev_alloc_skb() does:
if (in_hardirq() || irqs_disabled()) {
nc = this_cpu_ptr(&netdev_alloc_cache);
data = page_frag_alloc(nc, len, gfp_mask);
pfmemalloc = page_frag_cache_is_pfmemalloc(nc);
} else {
local_bh_disable();
local_lock_nested_bh(&napi_alloc_cache.bh_lock);
nc = this_cpu_ptr(&napi_alloc_cache.page);
data = page_frag_alloc(nc, len, gfp_mask);
pfmemalloc = page_frag_cache_is_pfmemalloc(nc);
local_unlock_nested_bh(&napi_alloc_cache.bh_lock);
local_bh_enable();
}
the local_bh_enable() seems to kick in BH processing inline,
and BH processing takes the same spin lock the driver is already
holding.
^ permalink raw reply
* [PATCH net] net: ethernet: ravb: Do not check URAM suspension when WoL is active
From: Niklas Söderlund @ 2026-04-12 17:32 UTC (permalink / raw)
To: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Yoshihiro Shimoda,
Geert Uytterhoeven, netdev, linux-renesas-soc
Cc: Niklas Söderlund
When updating the driver to match latest datasheet to suspend access to
URAM when suspending DMA transfers a corner-case was missed, URAM access
will not be suspended if WoL is enabled. This lead to the error message
(correctly) being triggered as URAM access is not suspended even tho
it's requested as part of stopping DMA.
Avoid checking if URAM access is suspended and printing the error
message if WoL is enabled when we suspend the system, as we know it will
not be.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Closes: https://lore.kernel.org/all/CAMuHMdWnjV%3DHGE1o08zLhUfTgOSene5fYx1J5GG10mB%2BToq8qg@mail.gmail.com/
Fixes: 353d8e7989b6 ("net: ethernet: ravb: Suspend and resume the transmission flow")
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/net/ethernet/renesas/ravb_main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 1dbfadb2a881..5f88733094d0 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1108,9 +1108,12 @@ static int ravb_stop_dma(struct net_device *ndev)
/* Request for transmission suspension */
ravb_modify(ndev, CCC, CCC_DTSR, CCC_DTSR);
- error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
- if (error)
- netdev_err(ndev, "failed to stop AXI BUS\n");
+ /* Access to URAM will not be suspended if WoL is enabled. */
+ if (!priv->wol_enabled) {
+ error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
+ if (error)
+ netdev_err(ndev, "failed to stop AXI BUS\n");
+ }
/* Stop AVB-DMAC process */
return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 00/11] netfilter: updates for net-next
From: Florian Westphal @ 2026-04-12 17:17 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Paolo Abeni, David S. Miller, Eric Dumazet,
netfilter-devel, pablo
In-Reply-To: <advOUl92VLlqaiCJ@strlen.de>
Florian Westphal <fw@strlen.de> wrote:
> Jakub Kicinski <kuba@kernel.org> wrote:
> https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de
Forgot to mention this:
---------------
AF_PACKET raw sockets or tun devices, the network_header might be
uninitialized (~0U). In this state, skb_mac_header_len() will evaluate to
a very large number, bypassing the ETH_HLEN check completely.
---------------
Really? TIL.
---------------------
Furthermore, skb_mac_header_len() only verifies the logical distance between
header offsets, rather than ensuring the bytes are actually present in the
physical linear buffer.
---------------
Really? Total news to me :-(
^ permalink raw reply
* [PATCH net-next 3/3] net: airoha: Rely on net_device pointer in ETS callbacks
From: Lorenzo Bianconi @ 2026-04-12 17:13 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Xuegang Lu,
Lorenzo Bianconi
In-Reply-To: <20260412-airoha-multi-serdes-preliminary-patch-v1-0-08d5b670ca8f@kernel.org>
Remove airoha_gdm_port dependency in ETS tc callback signatures and rely
on net_device pointer instead. Please note this patch does not introduce
any logical change and it is a preliminary patch in order to support
multiple net_devices connected to the same GDM3 or GDM4 port via an
external hw arbiter.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index c2b5fcffce82..d426dc173d99 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2138,10 +2138,11 @@ airoha_ethtool_get_rmon_stats(struct net_device *dev,
} while (u64_stats_fetch_retry(&port->stats.syncp, start));
}
-static int airoha_qdma_set_chan_tx_sched(struct airoha_gdm_port *port,
+static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
int channel, enum tx_sched_mode mode,
const u16 *weights, u8 n_weights)
{
+ struct airoha_gdm_port *port = netdev_priv(dev);
int i;
for (i = 0; i < AIROHA_NUM_TX_RING; i++)
@@ -2173,17 +2174,15 @@ static int airoha_qdma_set_chan_tx_sched(struct airoha_gdm_port *port,
return 0;
}
-static int airoha_qdma_set_tx_prio_sched(struct airoha_gdm_port *port,
- int channel)
+static int airoha_qdma_set_tx_prio_sched(struct net_device *dev, int channel)
{
static const u16 w[AIROHA_NUM_QOS_QUEUES] = {};
- return airoha_qdma_set_chan_tx_sched(port, channel, TC_SCH_SP, w,
+ return airoha_qdma_set_chan_tx_sched(dev, channel, TC_SCH_SP, w,
ARRAY_SIZE(w));
}
-static int airoha_qdma_set_tx_ets_sched(struct airoha_gdm_port *port,
- int channel,
+static int airoha_qdma_set_tx_ets_sched(struct net_device *dev, int channel,
struct tc_ets_qopt_offload *opt)
{
struct tc_ets_qopt_offload_replace_params *p = &opt->replace_params;
@@ -2224,20 +2223,21 @@ static int airoha_qdma_set_tx_ets_sched(struct airoha_gdm_port *port,
else if (nstrict < AIROHA_NUM_QOS_QUEUES - 1)
mode = nstrict + 1;
- return airoha_qdma_set_chan_tx_sched(port, channel, mode, w,
+ return airoha_qdma_set_chan_tx_sched(dev, channel, mode, w,
ARRAY_SIZE(w));
}
-static int airoha_qdma_get_tx_ets_stats(struct airoha_gdm_port *port,
- int channel,
+static int airoha_qdma_get_tx_ets_stats(struct net_device *dev, int channel,
struct tc_ets_qopt_offload *opt)
{
+ struct airoha_gdm_port *port = netdev_priv(dev);
u64 cpu_tx_packets = airoha_qdma_rr(port->qdma,
REG_CNTR_VAL(channel << 1));
u64 fwd_tx_packets = airoha_qdma_rr(port->qdma,
REG_CNTR_VAL((channel << 1) + 1));
u64 tx_packets = (cpu_tx_packets - port->cpu_tx_packets) +
(fwd_tx_packets - port->fwd_tx_packets);
+
_bstats_update(opt->stats.bstats, 0, tx_packets);
port->cpu_tx_packets = cpu_tx_packets;
@@ -2246,7 +2246,7 @@ static int airoha_qdma_get_tx_ets_stats(struct airoha_gdm_port *port,
return 0;
}
-static int airoha_tc_setup_qdisc_ets(struct airoha_gdm_port *port,
+static int airoha_tc_setup_qdisc_ets(struct net_device *dev,
struct tc_ets_qopt_offload *opt)
{
int channel;
@@ -2259,12 +2259,12 @@ static int airoha_tc_setup_qdisc_ets(struct airoha_gdm_port *port,
switch (opt->command) {
case TC_ETS_REPLACE:
- return airoha_qdma_set_tx_ets_sched(port, channel, opt);
+ return airoha_qdma_set_tx_ets_sched(dev, channel, opt);
case TC_ETS_DESTROY:
/* PRIO is default qdisc scheduler */
- return airoha_qdma_set_tx_prio_sched(port, channel);
+ return airoha_qdma_set_tx_prio_sched(dev, channel);
case TC_ETS_STATS:
- return airoha_qdma_get_tx_ets_stats(port, channel, opt);
+ return airoha_qdma_get_tx_ets_stats(dev, channel, opt);
default:
return -EOPNOTSUPP;
}
@@ -2807,11 +2807,9 @@ static int airoha_tc_setup_qdisc_htb(struct net_device *dev,
static int airoha_dev_tc_setup(struct net_device *dev, enum tc_setup_type type,
void *type_data)
{
- struct airoha_gdm_port *port = netdev_priv(dev);
-
switch (type) {
case TC_SETUP_QDISC_ETS:
- return airoha_tc_setup_qdisc_ets(port, type_data);
+ return airoha_tc_setup_qdisc_ets(dev, type_data);
case TC_SETUP_QDISC_HTB:
return airoha_tc_setup_qdisc_htb(dev, type_data);
case TC_SETUP_BLOCK:
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 2/3] net: airoha: Rely on net_device pointer in HTB callbacks
From: Lorenzo Bianconi @ 2026-04-12 17:13 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Xuegang Lu,
Lorenzo Bianconi
In-Reply-To: <20260412-airoha-multi-serdes-preliminary-patch-v1-0-08d5b670ca8f@kernel.org>
Remove airoha_gdm_port dependency in HTB tc callback signatures and rely
on net_device pointer instead. Please note this patch does not introduce
any logical change and it is a preliminary patch in order to support
multiple net_devices connected to the same GDM3 or GDM4 port via an
external hw arbiter.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 45 +++++++++++++++++---------------
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index a98512e963b5..c2b5fcffce82 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2492,10 +2492,11 @@ static int airoha_qdma_set_trtcm_token_bucket(struct airoha_qdma *qdma,
mode, val);
}
-static int airoha_qdma_set_tx_rate_limit(struct airoha_gdm_port *port,
+static int airoha_qdma_set_tx_rate_limit(struct net_device *dev,
int channel, u32 rate,
u32 bucket_size)
{
+ struct airoha_gdm_port *port = netdev_priv(dev);
int i, err;
for (i = 0; i <= TRTCM_PEAK_MODE; i++) {
@@ -2515,21 +2516,20 @@ static int airoha_qdma_set_tx_rate_limit(struct airoha_gdm_port *port,
return 0;
}
-static int airoha_tc_htb_alloc_leaf_queue(struct airoha_gdm_port *port,
+static int airoha_tc_htb_alloc_leaf_queue(struct net_device *dev,
struct tc_htb_qopt_offload *opt)
{
u32 channel = TC_H_MIN(opt->classid) % AIROHA_NUM_QOS_CHANNELS;
u32 rate = div_u64(opt->rate, 1000) << 3; /* kbps */
- struct net_device *dev = port->dev;
- int num_tx_queues = dev->real_num_tx_queues;
- int err;
+ int err, num_tx_queues = dev->real_num_tx_queues;
+ struct airoha_gdm_port *port = netdev_priv(dev);
if (opt->parent_classid != TC_HTB_CLASSID_ROOT) {
NL_SET_ERR_MSG_MOD(opt->extack, "invalid parent classid");
return -EINVAL;
}
- err = airoha_qdma_set_tx_rate_limit(port, channel, rate, opt->quantum);
+ err = airoha_qdma_set_tx_rate_limit(dev, channel, rate, opt->quantum);
if (err) {
NL_SET_ERR_MSG_MOD(opt->extack,
"failed configuring htb offload");
@@ -2541,7 +2541,7 @@ static int airoha_tc_htb_alloc_leaf_queue(struct airoha_gdm_port *port,
err = netif_set_real_num_tx_queues(dev, num_tx_queues + 1);
if (err) {
- airoha_qdma_set_tx_rate_limit(port, channel, 0, opt->quantum);
+ airoha_qdma_set_tx_rate_limit(dev, channel, 0, opt->quantum);
NL_SET_ERR_MSG_MOD(opt->extack,
"failed setting real_num_tx_queues");
return err;
@@ -2728,44 +2728,47 @@ static int airoha_dev_setup_tc_block(struct net_device *dev,
}
}
-static void airoha_tc_remove_htb_queue(struct airoha_gdm_port *port, int queue)
+static void airoha_tc_remove_htb_queue(struct net_device *dev, int queue)
{
- struct net_device *dev = port->dev;
+ struct airoha_gdm_port *port = netdev_priv(dev);
netif_set_real_num_tx_queues(dev, dev->real_num_tx_queues - 1);
- airoha_qdma_set_tx_rate_limit(port, queue + 1, 0, 0);
+ airoha_qdma_set_tx_rate_limit(dev, queue + 1, 0, 0);
clear_bit(queue, port->qos_sq_bmap);
}
-static int airoha_tc_htb_delete_leaf_queue(struct airoha_gdm_port *port,
+static int airoha_tc_htb_delete_leaf_queue(struct net_device *dev,
struct tc_htb_qopt_offload *opt)
{
u32 channel = TC_H_MIN(opt->classid) % AIROHA_NUM_QOS_CHANNELS;
+ struct airoha_gdm_port *port = netdev_priv(dev);
if (!test_bit(channel, port->qos_sq_bmap)) {
NL_SET_ERR_MSG_MOD(opt->extack, "invalid queue id");
return -EINVAL;
}
- airoha_tc_remove_htb_queue(port, channel);
+ airoha_tc_remove_htb_queue(dev, channel);
return 0;
}
-static int airoha_tc_htb_destroy(struct airoha_gdm_port *port)
+static int airoha_tc_htb_destroy(struct net_device *dev)
{
+ struct airoha_gdm_port *port = netdev_priv(dev);
int q;
for_each_set_bit(q, port->qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS)
- airoha_tc_remove_htb_queue(port, q);
+ airoha_tc_remove_htb_queue(dev, q);
return 0;
}
-static int airoha_tc_get_htb_get_leaf_queue(struct airoha_gdm_port *port,
+static int airoha_tc_get_htb_get_leaf_queue(struct net_device *dev,
struct tc_htb_qopt_offload *opt)
{
u32 channel = TC_H_MIN(opt->classid) % AIROHA_NUM_QOS_CHANNELS;
+ struct airoha_gdm_port *port = netdev_priv(dev);
if (!test_bit(channel, port->qos_sq_bmap)) {
NL_SET_ERR_MSG_MOD(opt->extack, "invalid queue id");
@@ -2777,23 +2780,23 @@ static int airoha_tc_get_htb_get_leaf_queue(struct airoha_gdm_port *port,
return 0;
}
-static int airoha_tc_setup_qdisc_htb(struct airoha_gdm_port *port,
+static int airoha_tc_setup_qdisc_htb(struct net_device *dev,
struct tc_htb_qopt_offload *opt)
{
switch (opt->command) {
case TC_HTB_CREATE:
break;
case TC_HTB_DESTROY:
- return airoha_tc_htb_destroy(port);
+ return airoha_tc_htb_destroy(dev);
case TC_HTB_NODE_MODIFY:
case TC_HTB_LEAF_ALLOC_QUEUE:
- return airoha_tc_htb_alloc_leaf_queue(port, opt);
+ return airoha_tc_htb_alloc_leaf_queue(dev, opt);
case TC_HTB_LEAF_DEL:
case TC_HTB_LEAF_DEL_LAST:
case TC_HTB_LEAF_DEL_LAST_FORCE:
- return airoha_tc_htb_delete_leaf_queue(port, opt);
+ return airoha_tc_htb_delete_leaf_queue(dev, opt);
case TC_HTB_LEAF_QUERY_QUEUE:
- return airoha_tc_get_htb_get_leaf_queue(port, opt);
+ return airoha_tc_get_htb_get_leaf_queue(dev, opt);
default:
return -EOPNOTSUPP;
}
@@ -2810,7 +2813,7 @@ static int airoha_dev_tc_setup(struct net_device *dev, enum tc_setup_type type,
case TC_SETUP_QDISC_ETS:
return airoha_tc_setup_qdisc_ets(port, type_data);
case TC_SETUP_QDISC_HTB:
- return airoha_tc_setup_qdisc_htb(port, type_data);
+ return airoha_tc_setup_qdisc_htb(dev, type_data);
case TC_SETUP_BLOCK:
case TC_SETUP_FT:
return airoha_dev_setup_tc_block(dev, type_data);
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 1/3] net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
From: Lorenzo Bianconi @ 2026-04-12 17:13 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Xuegang Lu,
Lorenzo Bianconi
In-Reply-To: <20260412-airoha-multi-serdes-preliminary-patch-v1-0-08d5b670ca8f@kernel.org>
Remove airoha_gdm_port dependency in airoha_dev_setup_tc_block routine
signature and rely on net_device pointer instead. Please note this patch
does not introduce any logical change and it is a preliminary patch to
support multiple net_devices connected to the GDM3 or GDM4 ports via an
external hw arbiter.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 8e4b043af4bc..a98512e963b5 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2687,7 +2687,7 @@ static int airoha_dev_setup_tc_block_cb(enum tc_setup_type type,
}
}
-static int airoha_dev_setup_tc_block(struct airoha_gdm_port *port,
+static int airoha_dev_setup_tc_block(struct net_device *dev,
struct flow_block_offload *f)
{
flow_setup_cb_t *cb = airoha_dev_setup_tc_block_cb;
@@ -2700,12 +2700,12 @@ static int airoha_dev_setup_tc_block(struct airoha_gdm_port *port,
f->driver_block_list = &block_cb_list;
switch (f->command) {
case FLOW_BLOCK_BIND:
- block_cb = flow_block_cb_lookup(f->block, cb, port->dev);
+ block_cb = flow_block_cb_lookup(f->block, cb, dev);
if (block_cb) {
flow_block_cb_incref(block_cb);
return 0;
}
- block_cb = flow_block_cb_alloc(cb, port->dev, port->dev, NULL);
+ block_cb = flow_block_cb_alloc(cb, dev, dev, NULL);
if (IS_ERR(block_cb))
return PTR_ERR(block_cb);
@@ -2714,7 +2714,7 @@ static int airoha_dev_setup_tc_block(struct airoha_gdm_port *port,
list_add_tail(&block_cb->driver_list, &block_cb_list);
return 0;
case FLOW_BLOCK_UNBIND:
- block_cb = flow_block_cb_lookup(f->block, cb, port->dev);
+ block_cb = flow_block_cb_lookup(f->block, cb, dev);
if (!block_cb)
return -ENOENT;
@@ -2813,7 +2813,7 @@ static int airoha_dev_tc_setup(struct net_device *dev, enum tc_setup_type type,
return airoha_tc_setup_qdisc_htb(port, type_data);
case TC_SETUP_BLOCK:
case TC_SETUP_FT:
- return airoha_dev_setup_tc_block(port, type_data);
+ return airoha_dev_setup_tc_block(dev, type_data);
default:
return -EOPNOTSUPP;
}
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 0/3] net: airoha: Preliminary series to support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-04-12 17:13 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Xuegang Lu,
Lorenzo Bianconi
EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
manages the traffic in a TDM manner.
This series introduces some preliminary changes necessary to introduce
support for multiple net_devices connected to the same Frame Engine (FE)
GDM port (GDM3 or GDM4).
---
Lorenzo Bianconi (3):
net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
net: airoha: Rely on net_device pointer in HTB callbacks
net: airoha: Rely on net_device pointer in ETS callbacks
drivers/net/ethernet/airoha/airoha_eth.c | 85 ++++++++++++++++----------------
1 file changed, 43 insertions(+), 42 deletions(-)
---
base-commit: 118cbd428e434bc1b8aac92a74b4992c7683f0fe
change-id: 20260412-airoha-multi-serdes-preliminary-patch-95f1cf5b5815
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* Re: [net-next] net: ethernet: ravb: Suspend and resume the transmission flow
From: Niklas Söderlund @ 2026-04-12 17:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Paul Barker, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev,
linux-renesas-soc
In-Reply-To: <CAMuHMdULBf3fBZU62F3YgBtJGzyTQgM-S-c9rhtX=cUCkqDQbA@mail.gmail.com>
Hi Geert,
On 2026-04-08 09:44:33 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Tue, 7 Apr 2026 at 20:54, Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > On 2026-04-07 11:03:38 +0200, Geert Uytterhoeven wrote:
> > > On Wed, 1 Apr 2026 at 20:39, Niklas Söderlund
> > > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > >
> > > > From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > >
> > > > The current driver does not follow the latest datasheet and does not
> > > > suspend the flow when stopping DMA and resume it when starting. Update
> > > > the driver to do so.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > > [Niklas: Rebase from BSP and reword commit message]
> > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > >
> > > Thanks for your patch, which is now commit 353d8e7989b6babe ("net:
> > > ethernet: ravb: Suspend and resume the transmission flow") in
> > > linux-next/master net-next.
> > >
> > > > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > > > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > > > @@ -694,6 +694,9 @@ static int ravb_dmac_init(struct net_device *ndev)
> > > > const struct ravb_hw_info *info = priv->info;
> > > > int error;
> > > >
> > > > + /* Clear transmission suspension */
> > > > + ravb_modify(ndev, CCC, CCC_DTSR, 0);
> > > > +
> > > > /* Set CONFIG mode */
> > > > error = ravb_set_opmode(ndev, CCC_OPC_CONFIG);
> > > > if (error)
> > > > @@ -1103,6 +1106,12 @@ static int ravb_stop_dma(struct net_device *ndev)
> > > > if (error)
> > > > return error;
> > > >
> > > > + /* Request for transmission suspension */
> > > > + ravb_modify(ndev, CCC, CCC_DTSR, CCC_DTSR);
> > > > + error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
> > > > + if (error)
> > > > + netdev_err(ndev, "failed to stop AXI BUS\n");
> > >
> > > This error message is printed during resume from s2idle or s2ram on
> > > e.g. Salvator-XS and Gray Hawk Single. Ethernet (nfsroot) still works
> > > fine, though.
> >
> > I was not able to reproduce this on M3N (r8a77965-salvator-xs.dts) nor
> > Sparrow Hawk (r8a779g3-sparrow-hawk.dts). I'm using the following to
> > test, is your test-case different?
> >
> > # echo enabled > /sys/class/tty/ttySC0/power/wakeup
> > # echo s2idle > /sys/power/mem_sleep
> > # echo 0 > /sys/module/printk/parameters/console_suspend
> > # echo mem > /sys/power/state
>
> Looks good. Major difference seems to be that I use either Wake-on-LAN
> or gpio-keys wake-up, and I always have WoL enabled for ravb.
WoL was indeed the key.
Having iperf3 blasting traffic to the target made no difference and
access to URAM is allowed to be suspended and no warning was triggered,
however just enabling WoL and no traffic.
# ethtool -s end0 wol g
And URAM access will not be suspended and reported active when checking
DTS in CSR register and this warning will be printed. I will send a
patch to ignore the check if WoL is enabled (when net-next open), but
still keep the request to stop URAM access. Nice catch!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH net-next 00/11] netfilter: updates for net-next
From: Florian Westphal @ 2026-04-12 16:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Paolo Abeni, David S. Miller, Eric Dumazet,
netfilter-devel, pablo
In-Reply-To: <20260412094049.7b01dd7b@kernel.org>
Jakub Kicinski <kuba@kernel.org> wrote:
> On Fri, 10 Apr 2026 13:23:41 +0200 Florian Westphal wrote:
> > 1-3) IPVS updates from Julian Anastasov to enhance visibility into
> > IPVS internal state by exposing hash size, load factor etc and
> > allows userspace to tune the load factor used for resizing hash
> > tables.
>
> Someone should take a look at the Sashiko reports for those, please?
https://sashiko.dev/#/patchset/20260410112352.23599-1-fw%40strlen.de
Sorry Pablo I am dumping this on you. Already wasted 3h on saturday
on LLM crap 8-(
---------
Could this trigger the DEBUG_NET_WARN_ON_ONCE() inside skb_mac_header_len()?
If a user program sends a verdict containing the NFQA_L2HDR attribute for a
packet where the MAC header is not set, it seems this code would call
skb_mac_header_len() without first checking skb_mac_header_was_set(entry->skb).
---------
And thus a new era of cargo cult programming will be born.
Because I have no idea how on earth PF_BRIDGE packets cannot have
a mac header attached to them.
Do I add this check as LLM overlord demands?
-------------
Is it safe to access the IP header here without ensuring the packet length
is sufficient and the header is in the linear data area?
Looking at the surrounding code in nft_fwd_neigh_eval(),
skb_try_make_writable() is called with sizeof(*iph), which is 20 bytes. At
the netdev hook, skb->data points to the MAC header, meaning the 20 bytes
only covers the Ethernet header and the first 6 bytes of the IP header.
Should this code use pskb_may_pull() or skb_ensure_writable() with an
offset that accounts for skb_network_offset(skb) + sizeof(*iph) before
dereferencing iph->ttl to avoid out-of-bounds accesses?
-------------
Dunno. Existing code does that.
^ permalink raw reply
* Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split
From: Jakub Kicinski @ 2026-04-12 16:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Wen Gu, tglx, richardcochran, andrew+netdev, davem, edumazet,
pabeni, linux-kernel, netdev, jstultz, anna-maria, frederic,
daniel.lezcano, sboyd, vladimir.oltean, wei.fang, xiaoning.wang,
jonathan.lemon, vadim.fedorenko, yangbo.lu, svens, nick.shi,
ajay.kaher, alexey.makhalov, bcm-kernel-feedback-list, linux-fpga,
imx, linux-s390, dust.li, xuanzhuo, mani, imran.shaik, taniya.das
In-Reply-To: <4B889ED5-D1F6-401D-B753-89AE2037F316@infradead.org>
On Sun, 12 Apr 2026 17:32:22 +0100 David Woodhouse wrote:
> On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
> >On Tue, 7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
> >> +PTP EMULATED CLOCK SUPPORT
> >> +M: David Woodhouse <dwmw2@infradead.org>
> >> +M: Wen Gu <guwen@linux.alibaba.com>
> >> +M: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >> +L: linux-kernel@vger.kernel.org
> >> +S: Maintained
> >> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
> >
> >Hi David,
> >
> >Do you have a tree to route the patches thru? Or do you really have
> >access to the tip tree?
>
> I do not have access to the tip tree. I can make a shared tree on
> git.infradead.org if the other two maintainers would like to send me
> a SSH pubkey and preferred username...
Honestly I'd love for you to be the only M here, and the other two
to be reviewers. Xuan Zhuo is currently at v40 trying to upstream
an Ethernet driver. Some growth needed there to become a subsystem
maintainer IMO.
^ permalink raw reply
* Re: [PATCH v1 net-next] selftest: net: Use port outside of the default ip_local_ports in csum.c.
From: Jakub Kicinski @ 2026-04-12 16:47 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Kuniyuki Iwashima, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Willem de Bruijn, Mahesh Bandewar,
Kuniyuki Iwashima, netdev
In-Reply-To: <willemdebruijn.kernel.15ccd7e646278@gmail.com>
On Sat, 11 Apr 2026 15:18:56 -0400 Willem de Bruijn wrote:
> > diff --git a/tools/testing/selftests/net/lib/csum.c b/tools/testing/selftests/net/lib/csum.c
> > index e28884ce3ab3..4e044689bc37 100644
> > --- a/tools/testing/selftests/net/lib/csum.c
> > +++ b/tools/testing/selftests/net/lib/csum.c
> > @@ -105,9 +105,9 @@ static char *cfg_mac_src;
> > static int cfg_proto = IPPROTO_UDP;
> > static int cfg_payload_char = 'a';
> > static int cfg_payload_len = 100;
> > -static uint16_t cfg_port_dst = 34000;
>
> This is paired with wait_port_listen(3400, .. in
> tools/testing/selftests/drivers/net/hw/csum.py
FWIW I can confirm that this caused the HW testing in NIPA to fail
the csum test since Friday.
^ permalink raw reply
* Re: [PATCH net-next 00/11] netfilter: updates for net-next
From: Jakub Kicinski @ 2026-04-12 16:40 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev, Paolo Abeni, David S. Miller, Eric Dumazet,
netfilter-devel, pablo
In-Reply-To: <20260410112352.23599-1-fw@strlen.de>
On Fri, 10 Apr 2026 13:23:41 +0200 Florian Westphal wrote:
> 1-3) IPVS updates from Julian Anastasov to enhance visibility into
> IPVS internal state by exposing hash size, load factor etc and
> allows userspace to tune the load factor used for resizing hash
> tables.
Someone should take a look at the Sashiko reports for those, please?
^ permalink raw reply
* Re: [PATCH net 1/1] net/sched: act_ct: Only release RCU read lock after ct_ft
From: patchwork-bot+netdevbpf @ 2026-04-12 16:40 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, edumazet, kuba, pabeni, horms, jiri,
zdi-disclosures, security, victor
In-Reply-To: <20260410111627.46611-1-jhs@mojatatu.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 07:16:27 -0400 you wrote:
> When looking up a flow table in act_ct in tcf_ct_flow_table_get(),
> rhashtable_lookup_fast() internally opens and closes an RCU read critical
> section before returning ct_ft.
> The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero()
> is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft
> object. This vulnerability can lead to privilege escalation.
>
> [...]
Here is the summary with links:
- [net,1/1] net/sched: act_ct: Only release RCU read lock after ct_ft
https://git.kernel.org/netdev/net/c/f462dca0c841
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] can: ucan: fix devres lifetime
From: patchwork-bot+netdevbpf @ 2026-04-12 16:40 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev, davem, kuba, linux-can, kernel, johan, stable,
jakob.unterwurzacher
In-Reply-To: <20260409165942.588421-2-mkl@pengutronix.de>
Hello:
This series was applied to netdev/net.git (main)
by Marc Kleine-Budde <mkl@pengutronix.de>:
On Thu, 9 Apr 2026 18:57:07 +0200 you wrote:
> From: Johan Hovold <johan@kernel.org>
>
> USB drivers bind to USB interfaces and any device managed resources
> should have their lifetime tied to the interface rather than parent USB
> device. This avoids issues like memory leaks when drivers are unbound
> without their devices being physically disconnected (e.g. on probe
> deferral or configuration changes).
>
> [...]
Here is the summary with links:
- [net,1/2] can: ucan: fix devres lifetime
https://git.kernel.org/netdev/net/c/fed4626501c8
- [net,2/2] can: raw: fix ro->uniq use-after-free in raw_rcv()
https://git.kernel.org/netdev/net/c/a535a9217ca3
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] netfilter: skip recording stale or retransmitted INIT
From: Xin Long @ 2026-04-12 16:35 UTC (permalink / raw)
To: Florian Westphal
Cc: network dev, linux-sctp, davem, kuba, Eric Dumazet, Paolo Abeni,
Simon Horman, Marcelo Ricardo Leitner, Yi Chen
In-Reply-To: <adqsEmki7ppz9T1g@strlen.de>
On Sat, Apr 11, 2026 at 4:16 PM Florian Westphal <fw@strlen.de> wrote:
>
> Xin Long <lucien.xin@gmail.com> wrote:
>
> > diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
> > index 645d2c43ebf7..7e10fa65cbdd 100644
> > --- a/net/netfilter/nf_conntrack_proto_sctp.c
> > +++ b/net/netfilter/nf_conntrack_proto_sctp.c
> > @@ -466,9 +466,13 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
> > if (!ih)
> > goto out_unlock;
> >
> > - if (ct->proto.sctp.init[dir] && ct->proto.sctp.init[!dir])
> > - ct->proto.sctp.init[!dir] = 0;
> > - ct->proto.sctp.init[dir] = 1;
> > + /* Do not record INIT matching peer vtag (stale or retransmitted INIT). */
> > + if (old_state == SCTP_CONNTRACK_NONE ||
> > + ct->proto.sctp.vtag[!dir] != ih->init_tag) {
>
> Should ct->proto.sctp.vtag[!dir] == ih->init_tag case also
> set ignore = true?
It should for a stale INIT, but not for a retransmitted one. At this point,
though, we don't reliably distinguish between the two.
Also, as this patch only aims to prevent updating ct->proto.sctp.init[]
(introduced in 8e56b063c865) in this scenario, it’s safer to avoid
changing other behavior.
Thanks.
^ permalink raw reply
* Re: [PATCH net v2] net: fix __this_cpu_add() in preemptible code in dev_xmit_recursion_inc/dec
From: Jakub Kicinski @ 2026-04-12 16:33 UTC (permalink / raw)
To: Jiayuan Chen, Eric Dumazet
Cc: netdev, David S. Miller, David Ahern, Paolo Abeni, Simon Horman,
Weiming Shi, linux-kernel
In-Reply-To: <20260410020631.191786-1-jiayuan.chen@linux.dev>
On Fri, 10 Apr 2026 10:06:30 +0800 Jiayuan Chen wrote:
> dev_xmit_recursion_{inc,dec}() use __this_cpu_{inc,dec}() which requires
> the caller to be non-preemptible in order to avoid cpu migration. However,
> some callers like SCTP's UDP encapsulation path invoke iptunnel_xmit()
> from process context without disabling BH or preemption:
>
> sctp_inet_connect -> __sctp_connect -> sctp_do_sm ->
> sctp_outq_flush -> sctp_packet_transmit -> sctp_v4_xmit ->
> udp_tunnel_xmit_skb -> iptunnel_xmit -> dev_xmit_recursion_inc
Eric, weren't there also a bunch of RCU reports because of this path?
Should we perhaps take the RCU read lock here?
> + guard(migrate)();
Sorry but I detest the guard() usage. Please use migrate_disable()
Quoting documentation:
Use of ``guard()`` is discouraged within any function longer than 20
lines, ``scoped_guard()`` is considered more readable. Using normal
lock/unlock is still (weakly) preferred.
See:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#using-device-managed-and-cleanup-h-constructs
^ permalink raw reply
* Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split
From: David Woodhouse @ 2026-04-12 16:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Wen Gu, tglx, richardcochran, andrew+netdev, davem, edumazet,
pabeni, linux-kernel, netdev, jstultz, anna-maria, frederic,
daniel.lezcano, sboyd, vladimir.oltean, wei.fang, xiaoning.wang,
jonathan.lemon, vadim.fedorenko, yangbo.lu, svens, nick.shi,
ajay.kaher, alexey.makhalov, bcm-kernel-feedback-list, linux-fpga,
imx, linux-s390, dust.li, xuanzhuo, mani, imran.shaik, taniya.das
In-Reply-To: <20260412084704.743482ad@kernel.org>
On 12 April 2026 16:47:04 BST, Jakub Kicinski <kuba@kernel.org> wrote:
>On Tue, 7 Apr 2026 18:48:02 +0800 Wen Gu wrote:
>> +PTP EMULATED CLOCK SUPPORT
>> +M: David Woodhouse <dwmw2@infradead.org>
>> +M: Wen Gu <guwen@linux.alibaba.com>
>> +M: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> +L: linux-kernel@vger.kernel.org
>> +S: Maintained
>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
>
>Hi David,
>
>Do you have a tree to route the patches thru? Or do you really have
>access to the tip tree?
I do not have access to the tip tree. I can make a shared tree on git.infradead.org if the other two maintainers would like to send me a SSH pubkey and preferred username...
^ permalink raw reply
* Re: [PATCH net-next] tcp: add indirect call wrapper in tcp_conn_request()
From: patchwork-bot+netdevbpf @ 2026-04-12 16:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, netdev,
eric.dumazet
In-Reply-To: <20260410174950.745670-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 17:49:50 +0000 you wrote:
> Small improvement in SYN processing, to directly call
> tcp_v6_init_seq_and_ts_off() or tcp_v4_init_seq_and_ts_off().
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> include/net/tcp.h | 6 ++++++
> net/ipv4/tcp_input.c | 5 ++++-
> net/ipv4/tcp_ipv4.c | 2 +-
> net/ipv6/tcp_ipv6.c | 2 +-
> 4 files changed, 12 insertions(+), 3 deletions(-)
Here is the summary with links:
- [net-next] tcp: add indirect call wrapper in tcp_conn_request()
https://git.kernel.org/netdev/net-next/c/29703d7813f9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [GIT PULL] wireless-next-2026-04-10
From: patchwork-bot+netdevbpf @ 2026-04-12 16:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260410064703.735099-3-johannes@sipsolutions.net>
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 08:44:33 +0200 you wrote:
> Hi,
>
> Final (obviously) pull request for now, the only thing to
> note is the crypto changes, FWIW the change touching crypto
> was acked by Herbert and he asked me to take it:
> https://lore.kernel.org/r/adYNVB3n358xm_s8@gondor.apana.org.au/
>
> [...]
Here is the summary with links:
- [GIT,PULL] wireless-next-2026-04-10
https://git.kernel.org/netdev/net-next/c/118cbd428e43
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Marek Vasut @ 2026-04-12 16:27 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Nicolai Buchwitz, Paolo Abeni, Ronald Wahl, Yicong Hui,
linux-kernel
In-Reply-To: <20260412090141.21bf1534@kernel.org>
On 4/12/26 6:01 PM, Jakub Kicinski wrote:
> On Wed, 8 Apr 2026 18:24:58 +0200 Marek Vasut wrote:
>> If CONFIG_PREEMPT_RT=y is set AND the driver executes ks8851_irq() AND
>> KSZ_ISR register bit IRQ_RXI is set AND ks8851_rx_pkts() detects that
>> there are packets in the RX FIFO, then netdev_alloc_skb_ip_align() is
>> called to allocate SKBs. If netdev_alloc_skb_ip_align() is called with
>> BH enabled, local_bh_enable() at the end of netdev_alloc_skb_ip_align()
>> will call __local_bh_enable_ip(), which will call __do_softirq(), which
>> may trigger net_tx_action() softirq, which may ultimately call the xmit
>> callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try
>> to lock struct ks8851_net_par .lock spinlock, which is already locked
>> by ks8851_irq() from which ks8851_start_xmit_par() was called. This
>> leads to a deadlock, which is reported by the kernel, including a trace
>> listed below.
>
> lock_par is a spinlock, and AFAIU softirqs run in their on thread on RT.
> I'm not following.
Please look at the backtrace in the commit message, this part, please
read from bottom to top to observe the failure in chronological order.
It does not seem the handle_softirqs() is running in its own thread,
separate from the IRQ thread ?
rt_spin_lock from ks8851_start_xmit_par+0x68/0x1a0
ks8851_start_xmit_par from netdev_start_xmit+0x1c/0x40 <---- this
tries to grab the same PAR spinlock, and deadlocks
netdev_start_xmit from dev_hard_start_xmit+0xec/0x1b0
dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
sch_direct_xmit from __qdisc_run+0x20c/0x4fc
__qdisc_run from qdisc_run+0x1c/0x28
qdisc_run from net_tx_action+0x1f4/0x244
net_tx_action from handle_softirqs+0x1c0/0x29c
handle_softirqs from __local_bh_enable_ip+0xdc/0xf4
__local_bh_enable_ip from __netdev_alloc_skb+0x140/0x194
__netdev_alloc_skb from ks8851_irq+0x348/0x4d8 <---- this is called
from ks8851_rx_pkts() via netdev_alloc_skb_ip_align()
ks8851_irq from irq_thread_fn+0x24/0x64 <-------- this here runs with
the PAR spinlock held
> The patch looks way to "advanced" for a driver. Something is going
> very wrong here. Or the commit message must be updated to explain
> it better to people like me. Or both.
Does the backtrace make the problem clearer, with the annotation above ?
^ permalink raw reply
* Re: [PATCH net-next] net: fix reference tracker mismanagement in netdev_put_lock()
From: patchwork-bot+netdevbpf @ 2026-04-12 16:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, dw,
skhawaja, bestswngs, razor, daniel
In-Reply-To: <20260410153600.1984522-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 08:36:00 -0700 you wrote:
> dev_put() releases a reference which didn't have a tracker.
> References without a tracker are accounted in the tracking
> code as "no_tracker". We can't free the tracker and then
> call dev_put(). The references themselves will be fine
> but the tracking code will think it's a double-release:
>
> refcount_t: decrement hit 0; leaking memory.
>
> [...]
Here is the summary with links:
- [net-next] net: fix reference tracker mismanagement in netdev_put_lock()
https://git.kernel.org/netdev/net-next/c/0aa72fc37e15
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] tcp: return a drop_reason from tcp_add_backlog()
From: patchwork-bot+netdevbpf @ 2026-04-12 16:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, netdev,
eric.dumazet
In-Reply-To: <20260409101147.1642967-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 10:11:47 +0000 you wrote:
> Part of a stack canary removal from tcp_v{4,6}_rcv().
>
> Return a drop_reason instead of a boolean, so that we no longer
> have to pass the address of a local variable.
>
> $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
> add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-37 (-37)
> Function old new delta
> tcp_v6_rcv 3133 3129 -4
> tcp_v4_rcv 3206 3202 -4
> tcp_add_backlog 1281 1252 -29
> Total: Before=25567186, After=25567149, chg -0.00%
>
> [...]
Here is the summary with links:
- [net-next] tcp: return a drop_reason from tcp_add_backlog()
https://git.kernel.org/netdev/net-next/c/f5148298b0fe
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net-next PATCH 0/2] net: dsa: tag_rtl8_4: fixes doc and set keep
From: patchwork-bot+netdevbpf @ 2026-04-12 16:20 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: andrew, olteanv, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel, alsi, linusw
In-Reply-To: <20260408-realtek_fixes-v1-0-915ff1404d56@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 17:31:00 -0300 you wrote:
> This small series addresses two points in the rtl8_4 tagger used by the
> realtel rtl8365mb driver.
>
> The first patch updates the documentation of the tag format while the
> second patch sets the KEEP flag bit, ensuring that the switch
> respects the frame's VLAN format as provided by the kernel.
>
> [...]
Here is the summary with links:
- [net-next,1/2] net: dsa: tag_rtl8_4: update format description
https://git.kernel.org/netdev/net-next/c/297e1f411ed4
- [net-next,2/2] net: dsa: tag_rtl8_4: set KEEP flag
https://git.kernel.org/netdev/net-next/c/82f37bd9a4d7
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] net: Add net_cookie to Dead loop messages
From: patchwork-bot+netdevbpf @ 2026-04-12 16:20 UTC (permalink / raw)
To: Chris J Arges
Cc: davem, edumazet, kuba, pabeni, horms, dsahern, kernel-team,
netdev, linux-kernel
In-Reply-To: <20260408191056.1036330-1-carges@cloudflare.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 14:10:47 -0500 you wrote:
> Network devices can have the same name within different network namespaces.
> To help distinguish these devices, add the net_cookie value which can be
> used to identify the netns.
>
> Signed-off-by: Chris J Arges <carges@cloudflare.com>
> ---
> v2: rebased on net-next
>
> [...]
Here is the summary with links:
- [net-next,v2] net: Add net_cookie to Dead loop messages
https://git.kernel.org/netdev/net-next/c/b258cba1e05d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: Rename ifq_idx to rxq_idx in netif_mp_* helpers
From: patchwork-bot+netdevbpf @ 2026-04-12 16:20 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, kuba, dw, pabeni, razor
In-Reply-To: <20260410130602.552600-1-daniel@iogearbox.net>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 15:06:02 +0200 you wrote:
> Rename the leftover ifq_idx parameter naming to rxq_idx to be
> consistent with the rest of the file and the header declaration.
> Back then this was taken out of the queue leasing series given
> the cleanup is independent. No functional change.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Link: https://lore.kernel.org/netdev/20260131160237.07789674@kernel.org
>
> [...]
Here is the summary with links:
- [net-next] net: Rename ifq_idx to rxq_idx in netif_mp_* helpers
https://git.kernel.org/netdev/net-next/c/59818773bab6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox