* [PATCH net v3] net/sched: taprio: fix NULL pointer dereference in class dump
From: Weiming Shi @ 2026-04-14 10:43 UTC (permalink / raw)
To: Vinicius Costa Gomes, Jamal Hadi Salim, Jiri Pirko,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, Xiang Mei, Weiming Shi
When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
Subsequent RTM_GETTCLASS dump operations walk all classes via
taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
returning the NULL pointer, then dereferences it to read child->handle,
causing a kernel NULL pointer dereference.
The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
namespaces enabled, an unprivileged local user can trigger a kernel
panic by creating a taprio qdisc inside a new network namespace,
grafting an explicit child qdisc, deleting it, and requesting a class
dump. The RTM_GETTCLASS dump itself requires no capability.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2475)
Call Trace:
<TASK>
tc_fill_tclass (net/sched/sch_api.c:1966)
qdisc_class_dump (net/sched/sch_api.c:2329)
taprio_walk (net/sched/sch_taprio.c:2510)
tc_dump_tclass_qdisc (net/sched/sch_api.c:2353)
tc_dump_tclass_root (net/sched/sch_api.c:2370)
tc_dump_tclass (net/sched/sch_api.c:2431)
rtnl_dumpit (net/core/rtnetlink.c:6827)
netlink_dump (net/netlink/af_netlink.c:2325)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6927)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
</TASK>
Fix this by substituting &noop_qdisc when new is NULL in
taprio_graft(), following the same pattern used by multiq_graft() and
prio_graft(). This ensures q->qdiscs[] slots are never NULL, making
control-plane dump paths safe without requiring individual NULL checks.
Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq)
previously had explicit NULL guards that would drop/skip the packet
cleanly, update those checks to test for &noop_qdisc instead. Without
this, packets would reach taprio_enqueue_one() which increments the root
qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc
drops the packet but those counters are never rolled back, permanently
inflating the root qdisc's statistics.
Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
v3: fix broken patch
v2: Also update NULL guards in taprio_enqueue() and
taprio_dequeue_from_txq() to avoid qlen/backlog inflation (Paolo).
---
net/sched/sch_taprio.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index f721c03514f60..07723b156c5b3 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -634,7 +634,7 @@ static int taprio_enqueue(struct sk_buff *skb, struct Qdisc *sch,
queue = skb_get_queue_mapping(skb);
child = q->qdiscs[queue];
- if (unlikely(!child))
+ if (unlikely(child == &noop_qdisc))
return qdisc_drop(skb, sch, to_free);
if (taprio_skb_exceeds_queue_max_sdu(sch, skb)) {
@@ -717,7 +717,7 @@ static struct sk_buff *taprio_dequeue_from_txq(struct Qdisc *sch, int txq,
int len;
u8 tc;
- if (unlikely(!child))
+ if (unlikely(child == &noop_qdisc))
return NULL;
if (TXTIME_ASSIST_IS_ENABLED(q->flags))
@@ -2183,6 +2183,9 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
if (!dev_queue)
return -EINVAL;
+ if (!new)
+ new = &noop_qdisc;
+
if (dev->flags & IFF_UP)
dev_deactivate(dev);
@@ -2196,14 +2199,14 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
*old = q->qdiscs[cl - 1];
if (FULL_OFFLOAD_IS_ENABLED(q->flags)) {
WARN_ON_ONCE(dev_graft_qdisc(dev_queue, new) != *old);
- if (new)
+ if (new != &noop_qdisc)
qdisc_refcount_inc(new);
if (*old)
qdisc_put(*old);
}
q->qdiscs[cl - 1] = new;
- if (new)
+ if (new != &noop_qdisc)
new->flags |= TCQ_F_ONETXQUEUE | TCQ_F_NOPARENT;
if (dev->flags & IFF_UP)
--
2.43.0
^ permalink raw reply related
* Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration
From: Leon Romanovsky @ 2026-04-14 10:35 UTC (permalink / raw)
To: fengchengwen
Cc: Jason Gunthorpe, Bjorn Helgaas, linux-rdma, linux-pci, netdev,
dri-devel, Keith Busch, Yochai Cohen, Yishai Hadas, Zhiping Zhang
In-Reply-To: <84bf119e-fa8c-4c97-9197-3377b7e2b250@huawei.com>
On Tue, Apr 14, 2026 at 05:30:09PM +0800, fengchengwen wrote:
> On 4/14/2026 4:57 PM, Leon Romanovsky wrote:
> > On Tue, Apr 14, 2026 at 09:07:23AM +0800, fengchengwen wrote:
> >> On 4/14/2026 3:19 AM, Leon Romanovsky wrote:
> >>> On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
> >>>> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
> >>>>> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I'm writing to propose adding a sysfs interface to expose and configure the
> >>>>>> PCIe TPH
> >>>>>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
> >>>>>>
> >>>>>>
> >>>>>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
> >>>>>> (identified
> >>>>>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
> >>>>>> user-space
> >>>>>> applications to fetch and set this value securely and conveniently, we need
> >>>>>> a standard
> >>>>>> kernel-to-user interface.
> >>>>>>
> >>>>>>
> >>>>>> Proposed Solution: Add several sysfs attributes under each PCIe device's
> >>>>>> sysfs directory:
> >>>>>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
> >>>>>> device specific)
> >>>>>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
> >>>>>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
> >>>>>> operations, e.g.:
> >>>>>> Read operation:
> >>>>>> echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>>> cat /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>>> Write operation:
> >>>>>> echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
> >>>>>>
> >>>>>>
> >>>>>> The design strictly follows PCI subsystem sysfs standards and has the
> >>>>>> following key properties:
> >>>>>>
> >>>>>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
> >>>>>> devices that
> >>>>>> support TPH Steering Tag. Devices without TPH capability will not show
> >>>>>> these nodes,
> >>>>>> avoiding unnecessary user confusion.
> >>>>>>
> >>>>>> 2. Permission Control: The attributes will use 0600 file permissions,
> >>>>>> ensuring only
> >>>>>> privileged root users can read or write them, which satisfies security
> >>>>>> requirements
> >>>>>> for hardware configuration interfaces.
> >>>>>>
> >>>>>> 3. Standard Implementation Location: The interface will be implemented in
> >>>>>> drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
> >>>>>> attributes,
> >>>>>> ensuring consistency and maintainability within the PCI subsystem.
> >>>>>>
> >>>>>>
> >>>>>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
> >>>>>>
> >>>>>> - Universality: sysfs does not require binding the device to a special
> >>>>>> driver such as
> >>>>>> vfio-pci. It is available to any privileged user-space component,
> >>>>>> including system
> >>>>>> utilities, daemons, and monitoring tools.
> >>>>>>
> >>>>>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
> >>>>>> straightforward, reducing code complexity and long-term maintenance cost.
> >>>>>>
> >>>>>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
> >>>>>> specific to
> >>>>>> user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
> >>>>>> kernel's
> >>>>>> standard pattern for hardware capabilities.
> >>>>>>
> >>>>>>
> >>>>>> I look forward to your comments about this design before submitting the
> >>>>>> final patch.
> >>>>>
> >>>>> You need to explain more clearly why this write functionality is useful
> >>>>> and necessary outside the VFIO/RDMA context:
> >>>>> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
> >>>>>
> >>>>> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
> >>>>> right ST values.
> >>>>>
> >>>>> There are several comments regarding the implementation, but those can wait
> >>>>> until the rationale behind the proposal is fully clarified.
> >>>>
> >>>> Thanks for your review and comments.
> >>>>
> >>>> Let me clarify the rationale behind this user-space sysfs interface:
> >>>>
> >>>> 1. VFIO is just one of the user-space device access frameworks.
> >>>> There are many other in-kernel frameworks that expose devices
> >>>> to user space, such as UIO, UACCE, etc., which may also require
> >>>> TPH Steering Tag support.
> >>>>
> >>>> 2. The kernel can automatically program Steering Tags only when
> >>>> the device provides a standard ST table in MSI-X or config space.
> >>>> However, many devices implement vendor-specific or platform-specific
> >>>> Steering Tag programming methods that cannot be fully handled
> >>>> by the generic kernel code.
> >>>>
> >>>> 3. For such devices, user-space applications or framework drivers
> >>>> need to retrieve and configure TPH Steering Tags directly.
> >>>> A unified sysfs interface allows all user-space frameworks
> >>>> (not just VFIO) to use a common, standard way to manage
> >>>> TPH Steering Tags, rather than implementing duplicated logic
> >>>> in each subsystem.
> >>>>
> >>>> This interface provides a uniform method for any user-space
> >>>> device access solution to work with TPH, which is why I believe
> >>>> it is useful and necessary beyond the VFIO/RDMA case.
> >>>
> >>> I understand the rationale for providing a read interface, for example for
> >>> debugging, but I do not see any justification for a write interface.
> >>
> >> Thank you for the comment!
> >>
> >> As I explained, read interface is not only for debugging. It was used to
> >> such device who don't declare ST location in MSI-X or config-space, the following
> >> is Intel X710 NIC device's lspci output (only TPH part):
> >>
> >> Capabilities: [1a0 v1] Transaction Processing Hints
> >> Device specific mode supported
> >> No steering table available
> >>
> >> So we could not config the ST for device on kernel because it's vendor specific.
> >> But we could configure ST by it's vendor user-space driver, in this case, we
> >> should get ST from kernel to user-space.
> >
> > Vendor-specific, in the context of the PCI specification, does not mean the
> > kernel cannot configure it. It simply means that the ST values are not
> > stored in the ST table.
>
> Thank you for the clarification!
>
> I agree with your interpretation of "vendor-specific" in PCI spec terms—it
> does not prevent the kernel from handling TPH in principle. However, the
> real problem is that the kernel has no standardized way to know where or
> how to program those vendor-specific ST values.
No one here is opposed to you implementing the appropriate callbacks or
extending the existing in-kernel API to support a device‑specific mode.
>
> When a device reports "No steering table available" and operates in
> device-specific mode, the method used to set ST values is entirely
> device-specific and not covered by the PCI specification. If the device
> is taken over to user-space by UIO framework (e.g. VFIO or IGB_UIO), the
> generic kernel cannot infer the proper programming sequence or registers
> for each vendor-specific implementation.
>
> In these cases, the configuration must be done by the vendor’s
> user-space driver, which is aware of the device’s private programming
> model. But such a user-space driver still needs to obtain valid,
> platform-provided ST values (from ACPI _DSM), which it cannot do
> without a kernel interface.
The objection applies to this point. The PCI device exists in kernel space,
and the kernel is responsible for managing its internal state.
>
> This is why a read-only interface to retrieve ST values is still
> needed: the kernel holds the valid platform tags, while the user-space
> driver handles the device-specific programming.
>
> Thanks
>
> >
> > Thanks
>
^ permalink raw reply
* Re: [PATCH] nfc: s3fwrn5: switch to GPIO descriptor API
From: Krzysztof Kozlowski @ 2026-04-14 10:33 UTC (permalink / raw)
To: deep
Cc: Linus Walleij, Bartosz Golaszewski, netdev, linux-nfc,
linux-kernel, linux-gpio
In-Reply-To: <20260414102257.365421-1-deep@crimson.net.eu.org>
On 14/04/2026 12:22, deep@crimson.net.eu.org wrote:
> From: Kenet Jovan Sokoli <deep@crimson.net.eu.org>
>
> I am working on cleaning up some legacy GPIO usage in the NFC subsystem.
> This patch converts the s3fwrn5 driver to use the modern descriptor based
> GPIO API instead of the old integer based one.
>
> Specifically:
> - I changed the gpio_en and gpio_fw_wake types to struct gpio_desc.
> - Replaced the manual DT parsing with devm_gpiod_get() in the probe
> functions.
> - Updated the calls in phy_common.c to use gpiod_set_value().
>
> This also allowed me to remove the s3fwrn5_i2c_parse_dt and
> s3fwrn82_uart_parse_dt functions as they are no longer needed with the
> new API.
>
> Signed-off-by: Kenet Jovan Sokoli <deep@crimson.net.eu.org>
> ---
> I have verified that this patch builds successfully with "make M=drivers/nfc/s3fwrn5"
> "scripts/checkpatch.pl" with no errors or warnings.
> This is very complicated stuff, but I am learning a lot by doing these cleanup works.
> I really hope I can contribute as much as possible to this environment, little by little.
> ---
Please do not duplicate existing work needlessly.
https://lore.kernel.org/all/?q=dfn%3Adrivers%2Fnfc%2Fs3fwrn5%2Fi2c.c
Best regards,
Krzysztof
^ permalink raw reply
* [net,PATCH v3 2/2] net: ks8851: Avoid excess softirq scheduling
From: Marek Vasut @ 2026-04-14 10:32 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Sebastian Andrzej Siewior, Yicong Hui, linux-kernel
In-Reply-To: <20260414103327.113500-1-marex@nabladev.com>
The code injects a packet into netif_rx() repeatedly, which will add
it to its internal NAPI and schedule a softirq, and process it. It is
more efficient to queue multiple packets and process them all at the
local_bh_enable() time.
Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs")
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Nicolai Buchwitz <nb@tipi-net.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Yicong Hui <yiconghui@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
---
V3: New patch
---
drivers/net/ethernet/micrel/ks8851_common.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851_common.c b/drivers/net/ethernet/micrel/ks8851_common.c
index 6c375647b24de..4afbb40bc0e4a 100644
--- a/drivers/net/ethernet/micrel/ks8851_common.c
+++ b/drivers/net/ethernet/micrel/ks8851_common.c
@@ -373,9 +373,12 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
if (status & IRQ_LCI)
mii_check_link(&ks->mii);
- if (status & IRQ_RXI)
+ if (status & IRQ_RXI) {
+ local_bh_disable();
while ((skb = __skb_dequeue(&rxq)))
netif_rx(skb);
+ local_bh_enable();
+ }
return IRQ_HANDLED;
}
--
2.53.0
^ permalink raw reply related
* [net,PATCH v3 1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Marek Vasut @ 2026-04-14 10:32 UTC (permalink / raw)
To: netdev
Cc: Marek Vasut, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Sebastian Andrzej Siewior, Yicong Hui, linux-kernel
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.
Fix the problem by disabling BH around critical sections, including the
IRQ handler, thus preventing the net_tx_action() softirq from triggering
during these critical sections. The net_tx_action() softirq is triggered
at the end of the IRQ handler, once all the other IRQ handler actions have
been completed.
__schedule from schedule_rtlock+0x1c/0x34
schedule_rtlock from rtlock_slowlock_locked+0x548/0x904
rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c
rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8
ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44
netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188
dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
sch_direct_xmit from __qdisc_run+0x1f8/0x4ec
__qdisc_run from qdisc_run+0x1c/0x28
qdisc_run from net_tx_action+0x1f0/0x268
net_tx_action from handle_softirqs+0x1a4/0x270
handle_softirqs from __local_bh_enable_ip+0xcc/0xe0
__local_bh_enable_ip from __alloc_skb+0xd8/0x128
__alloc_skb from __netdev_alloc_skb+0x3c/0x19c
__netdev_alloc_skb from ks8851_irq+0x388/0x4d4
ks8851_irq from irq_thread_fn+0x24/0x64
irq_thread_fn from irq_thread+0x178/0x28c
irq_thread from kthread+0x12c/0x138
kthread from ret_from_fork+0x14/0x28
Fixes: e0863634bf9f ("net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs")
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Nicolai Buchwitz <nb@tipi-net.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Yicong Hui <yiconghui@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
---
V2: Register dedicated IRQ handler wrapper which disables BH for the
parallel variant of the MAC, the variant which uses spinlocks as
the locking primitive. Use stock IRQ handler with BH unchanged
for the SPI variant, which uses mutexes as locking primitive.
V3: Switch to spin_lock_bh(), update commit message
---
drivers/net/ethernet/micrel/ks8851.h | 6 +-
drivers/net/ethernet/micrel/ks8851_common.c | 64 +++++++++------------
drivers/net/ethernet/micrel/ks8851_par.c | 15 ++---
drivers/net/ethernet/micrel/ks8851_spi.c | 11 ++--
4 files changed, 38 insertions(+), 58 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.h b/drivers/net/ethernet/micrel/ks8851.h
index 31f75b4a67fd7..b795a3a605711 100644
--- a/drivers/net/ethernet/micrel/ks8851.h
+++ b/drivers/net/ethernet/micrel/ks8851.h
@@ -408,10 +408,8 @@ struct ks8851_net {
struct gpio_desc *gpio;
struct mii_bus *mii_bus;
- void (*lock)(struct ks8851_net *ks,
- unsigned long *flags);
- void (*unlock)(struct ks8851_net *ks,
- unsigned long *flags);
+ void (*lock)(struct ks8851_net *ks);
+ void (*unlock)(struct ks8851_net *ks);
unsigned int (*rdreg16)(struct ks8851_net *ks,
unsigned int reg);
void (*wrreg16)(struct ks8851_net *ks,
diff --git a/drivers/net/ethernet/micrel/ks8851_common.c b/drivers/net/ethernet/micrel/ks8851_common.c
index 8048770958d60..6c375647b24de 100644
--- a/drivers/net/ethernet/micrel/ks8851_common.c
+++ b/drivers/net/ethernet/micrel/ks8851_common.c
@@ -28,25 +28,23 @@
/**
* ks8851_lock - register access lock
* @ks: The chip state
- * @flags: Spinlock flags
*
* Claim chip register access lock
*/
-static void ks8851_lock(struct ks8851_net *ks, unsigned long *flags)
+static void ks8851_lock(struct ks8851_net *ks)
{
- ks->lock(ks, flags);
+ ks->lock(ks);
}
/**
* ks8851_unlock - register access unlock
* @ks: The chip state
- * @flags: Spinlock flags
*
* Release chip register access lock
*/
-static void ks8851_unlock(struct ks8851_net *ks, unsigned long *flags)
+static void ks8851_unlock(struct ks8851_net *ks)
{
- ks->unlock(ks, flags);
+ ks->unlock(ks);
}
/**
@@ -129,11 +127,10 @@ static void ks8851_set_powermode(struct ks8851_net *ks, unsigned pwrmode)
static int ks8851_write_mac_addr(struct net_device *dev)
{
struct ks8851_net *ks = netdev_priv(dev);
- unsigned long flags;
u16 val;
int i;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
/*
* Wake up chip in case it was powered off when stopped; otherwise,
@@ -149,7 +146,7 @@ static int ks8851_write_mac_addr(struct net_device *dev)
if (!netif_running(dev))
ks8851_set_powermode(ks, PMECR_PM_SOFTDOWN);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
return 0;
}
@@ -163,12 +160,11 @@ static int ks8851_write_mac_addr(struct net_device *dev)
static void ks8851_read_mac_addr(struct net_device *dev)
{
struct ks8851_net *ks = netdev_priv(dev);
- unsigned long flags;
u8 addr[ETH_ALEN];
u16 reg;
int i;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
for (i = 0; i < ETH_ALEN; i += 2) {
reg = ks8851_rdreg16(ks, KS_MAR(i));
@@ -177,7 +173,7 @@ static void ks8851_read_mac_addr(struct net_device *dev)
}
eth_hw_addr_set(dev, addr);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
}
/**
@@ -312,11 +308,10 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
{
struct ks8851_net *ks = _ks;
struct sk_buff_head rxq;
- unsigned long flags;
unsigned int status;
struct sk_buff *skb;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
status = ks8851_rdreg16(ks, KS_ISR);
ks8851_wrreg16(ks, KS_ISR, status);
@@ -373,7 +368,7 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
ks8851_wrreg16(ks, KS_RXCR1, rxc->rxcr1);
}
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
if (status & IRQ_LCI)
mii_check_link(&ks->mii);
@@ -405,7 +400,6 @@ static void ks8851_flush_tx_work(struct ks8851_net *ks)
static int ks8851_net_open(struct net_device *dev)
{
struct ks8851_net *ks = netdev_priv(dev);
- unsigned long flags;
int ret;
ret = request_threaded_irq(dev->irq, NULL, ks8851_irq,
@@ -418,7 +412,7 @@ static int ks8851_net_open(struct net_device *dev)
/* lock the card, even if we may not actually be doing anything
* else at the moment */
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
netif_dbg(ks, ifup, ks->netdev, "opening\n");
@@ -471,7 +465,7 @@ static int ks8851_net_open(struct net_device *dev)
netif_dbg(ks, ifup, ks->netdev, "network device up\n");
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
mii_check_link(&ks->mii);
return 0;
}
@@ -487,23 +481,22 @@ static int ks8851_net_open(struct net_device *dev)
static int ks8851_net_stop(struct net_device *dev)
{
struct ks8851_net *ks = netdev_priv(dev);
- unsigned long flags;
netif_info(ks, ifdown, dev, "shutting down\n");
netif_stop_queue(dev);
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
/* turn off the IRQs and ack any outstanding */
ks8851_wrreg16(ks, KS_IER, 0x0000);
ks8851_wrreg16(ks, KS_ISR, 0xffff);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
/* stop any outstanding work */
ks8851_flush_tx_work(ks);
flush_work(&ks->rxctrl_work);
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
/* shutdown RX process */
ks8851_wrreg16(ks, KS_RXCR1, 0x0000);
@@ -512,7 +505,7 @@ static int ks8851_net_stop(struct net_device *dev)
/* set powermode to soft power down to save power */
ks8851_set_powermode(ks, PMECR_PM_SOFTDOWN);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
/* ensure any queued tx buffers are dumped */
while (!skb_queue_empty(&ks->txq)) {
@@ -566,14 +559,13 @@ static netdev_tx_t ks8851_start_xmit(struct sk_buff *skb,
static void ks8851_rxctrl_work(struct work_struct *work)
{
struct ks8851_net *ks = container_of(work, struct ks8851_net, rxctrl_work);
- unsigned long flags;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
/* need to shutdown RXQ before modifying filter parameters */
ks8851_wrreg16(ks, KS_RXCR1, 0x00);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
}
static void ks8851_set_rx_mode(struct net_device *dev)
@@ -780,7 +772,6 @@ static int ks8851_set_eeprom(struct net_device *dev,
{
struct ks8851_net *ks = netdev_priv(dev);
int offset = ee->offset;
- unsigned long flags;
int len = ee->len;
u16 tmp;
@@ -794,7 +785,7 @@ static int ks8851_set_eeprom(struct net_device *dev,
if (!(ks->rc_ccr & CCR_EEPROM))
return -ENOENT;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
ks8851_eeprom_claim(ks);
@@ -817,7 +808,7 @@ static int ks8851_set_eeprom(struct net_device *dev,
eeprom_93cx6_wren(&ks->eeprom, false);
ks8851_eeprom_release(ks);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
return 0;
}
@@ -827,7 +818,6 @@ static int ks8851_get_eeprom(struct net_device *dev,
{
struct ks8851_net *ks = netdev_priv(dev);
int offset = ee->offset;
- unsigned long flags;
int len = ee->len;
/* must be 2 byte aligned */
@@ -837,7 +827,7 @@ static int ks8851_get_eeprom(struct net_device *dev,
if (!(ks->rc_ccr & CCR_EEPROM))
return -ENOENT;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
ks8851_eeprom_claim(ks);
@@ -845,7 +835,7 @@ static int ks8851_get_eeprom(struct net_device *dev,
eeprom_93cx6_multiread(&ks->eeprom, offset/2, (__le16 *)data, len/2);
ks8851_eeprom_release(ks);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
return 0;
}
@@ -904,7 +894,6 @@ static int ks8851_phy_reg(int reg)
static int ks8851_phy_read_common(struct net_device *dev, int phy_addr, int reg)
{
struct ks8851_net *ks = netdev_priv(dev);
- unsigned long flags;
int result;
int ksreg;
@@ -912,9 +901,9 @@ static int ks8851_phy_read_common(struct net_device *dev, int phy_addr, int reg)
if (ksreg < 0)
return ksreg;
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
result = ks8851_rdreg16(ks, ksreg);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
return result;
}
@@ -949,14 +938,13 @@ static void ks8851_phy_write(struct net_device *dev,
int phy, int reg, int value)
{
struct ks8851_net *ks = netdev_priv(dev);
- unsigned long flags;
int ksreg;
ksreg = ks8851_phy_reg(reg);
if (ksreg >= 0) {
- ks8851_lock(ks, &flags);
+ ks8851_lock(ks);
ks8851_wrreg16(ks, ksreg, value);
- ks8851_unlock(ks, &flags);
+ ks8851_unlock(ks);
}
}
diff --git a/drivers/net/ethernet/micrel/ks8851_par.c b/drivers/net/ethernet/micrel/ks8851_par.c
index 78695be2570bf..9f1c33f6ddec0 100644
--- a/drivers/net/ethernet/micrel/ks8851_par.c
+++ b/drivers/net/ethernet/micrel/ks8851_par.c
@@ -55,29 +55,27 @@ struct ks8851_net_par {
/**
* ks8851_lock_par - register access lock
* @ks: The chip state
- * @flags: Spinlock flags
*
* Claim chip register access lock
*/
-static void ks8851_lock_par(struct ks8851_net *ks, unsigned long *flags)
+static void ks8851_lock_par(struct ks8851_net *ks)
{
struct ks8851_net_par *ksp = to_ks8851_par(ks);
- spin_lock_irqsave(&ksp->lock, *flags);
+ spin_lock_bh(&ksp->lock);
}
/**
* ks8851_unlock_par - register access unlock
* @ks: The chip state
- * @flags: Spinlock flags
*
* Release chip register access lock
*/
-static void ks8851_unlock_par(struct ks8851_net *ks, unsigned long *flags)
+static void ks8851_unlock_par(struct ks8851_net *ks)
{
struct ks8851_net_par *ksp = to_ks8851_par(ks);
- spin_unlock_irqrestore(&ksp->lock, *flags);
+ spin_unlock_bh(&ksp->lock);
}
/**
@@ -233,7 +231,6 @@ static netdev_tx_t ks8851_start_xmit_par(struct sk_buff *skb,
{
struct ks8851_net *ks = netdev_priv(dev);
netdev_tx_t ret = NETDEV_TX_OK;
- unsigned long flags;
unsigned int txqcr;
u16 txmir;
int err;
@@ -241,7 +238,7 @@ static netdev_tx_t ks8851_start_xmit_par(struct sk_buff *skb,
netif_dbg(ks, tx_queued, ks->netdev,
"%s: skb %p, %d@%p\n", __func__, skb, skb->len, skb->data);
- ks8851_lock_par(ks, &flags);
+ ks8851_lock_par(ks);
txmir = ks8851_rdreg16_par(ks, KS_TXMIR) & 0x1fff;
@@ -262,7 +259,7 @@ static netdev_tx_t ks8851_start_xmit_par(struct sk_buff *skb,
ret = NETDEV_TX_BUSY;
}
- ks8851_unlock_par(ks, &flags);
+ ks8851_unlock_par(ks);
return ret;
}
diff --git a/drivers/net/ethernet/micrel/ks8851_spi.c b/drivers/net/ethernet/micrel/ks8851_spi.c
index a161ae45743ab..b9e68520278d0 100644
--- a/drivers/net/ethernet/micrel/ks8851_spi.c
+++ b/drivers/net/ethernet/micrel/ks8851_spi.c
@@ -71,11 +71,10 @@ struct ks8851_net_spi {
/**
* ks8851_lock_spi - register access lock
* @ks: The chip state
- * @flags: Spinlock flags
*
* Claim chip register access lock
*/
-static void ks8851_lock_spi(struct ks8851_net *ks, unsigned long *flags)
+static void ks8851_lock_spi(struct ks8851_net *ks)
{
struct ks8851_net_spi *kss = to_ks8851_spi(ks);
@@ -85,11 +84,10 @@ static void ks8851_lock_spi(struct ks8851_net *ks, unsigned long *flags)
/**
* ks8851_unlock_spi - register access unlock
* @ks: The chip state
- * @flags: Spinlock flags
*
* Release chip register access lock
*/
-static void ks8851_unlock_spi(struct ks8851_net *ks, unsigned long *flags)
+static void ks8851_unlock_spi(struct ks8851_net *ks)
{
struct ks8851_net_spi *kss = to_ks8851_spi(ks);
@@ -309,7 +307,6 @@ static void ks8851_tx_work(struct work_struct *work)
struct ks8851_net_spi *kss;
unsigned short tx_space;
struct ks8851_net *ks;
- unsigned long flags;
struct sk_buff *txb;
bool last;
@@ -317,7 +314,7 @@ static void ks8851_tx_work(struct work_struct *work)
ks = &kss->ks8851;
last = skb_queue_empty(&ks->txq);
- ks8851_lock_spi(ks, &flags);
+ ks8851_lock_spi(ks);
while (!last) {
txb = skb_dequeue(&ks->txq);
@@ -343,7 +340,7 @@ static void ks8851_tx_work(struct work_struct *work)
ks->tx_space = tx_space;
spin_unlock_bh(&ks->statelock);
- ks8851_unlock_spi(ks, &flags);
+ ks8851_unlock_spi(ks);
}
/**
--
2.53.0
^ permalink raw reply related
* Re: [RFC] net: openvswitch: Inroduce a light-weight socket map concept.
From: Minxi Hou @ 2026-04-14 10:32 UTC (permalink / raw)
To: netdev; +Cc: Minxi Hou, ovs-dev, mhou
In-Reply-To: <20250627210054.114417-1-aconole@redhat.com>
Hi Aaron,
I tested two stages of this work on x86_64, single-node setup:
1. Early RFC (this patch, June 2025): basic socket action plumbing,
ODP parsing, and socket_lookup configuration.
2. Current development branch (sockmap_2026_feb, built as a scratch
kernel based on RHEL 9.8 / 5.14.0-611.el9_7), which extends this
RFC with: rcuify list, sockmap get/del commands, action list rework,
packet cmd fix, sockmap fixes, tuple detail improvements, and
flow-socket association. Paired with the OVS userspace sockmap
branch (sockmap_cmds).
Tests on the current development branch:
- ODP action round-trip parsing (valid and invalid): pass
- Socket action generation via ofproto/trace for TCP (IPv4/IPv6): pass
- Non-TCP exclusion (ICMP, UDP): pass
- socket_lookup enable/disable per port: pass
- socket_lookup with group recirculation: pass
- OpenFlow regression with socket_lookup: pass
- Conntrack regression with socket_lookup: pass
- 2-namespace TCP performance: pass
During 1000-namespace scale testing (2000 veth pairs, socket_lookup
enabled on all ports), the following WARNING burst was observed in the
kernel console log:
[20652.730148] WARNING: CPU: 118 PID: 304284 at
net/core/skbuff.c:1000 skb_release_head_state+0x95/0xa0
(185 occurrences within 79ms, followed by BUG: scheduling while
atomic in OVS upcall handler thread handler2052)
This is triggered by ARP table overflow under 2000 veth pairs, which
floods the OVS netlink upcall path. The underlying issue is that skbs
with netlink_skb_destructor are passed to consume_skb() without first
calling skb_orphan(). The WARNING is reproducible on a stock RHEL 9.8
kernel + stock OVS 3.7 without any of these patches, confirming it is
a pre-existing kernel issue unrelated to this work.
Tested-by: Minxi Hou <houminxi@gmail.com>
^ permalink raw reply
* [PATCH] net: mdio: MDIO_PIC64HPSC should depend on ARCH_MICROCHIP
From: Geert Uytterhoeven @ 2026-04-14 10:30 UTC (permalink / raw)
To: Charles Perry, Conor Dooley, Jakub Kicinski, Maxime Chevallier,
Andrew Lunn, Heiner Kallweit, Russell King, David S . Miller,
Eric Dumazet, Paolo Abeni
Cc: netdev, linux-kernel, Geert Uytterhoeven
The PIC64-HPSC/HX MDIO interface is only present on Microchip
PIC64-HPSC/HX SoCs. Hence add a dependency on ARCH_MICROCHIP, to
prevent asking the user about this driver when configuring a kernel
without Microchip SoC support.
Fixes: f76aef980206e7c6 ("net: mdio: add a driver for PIC64-HPSC/HX MDIO controller")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/net/mdio/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 516b0d05e16ebba3..c71132f33f8472e6 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -147,6 +147,7 @@ config MDIO_OCTEON
config MDIO_PIC64HPSC
tristate "PIC64-HPSC/HX MDIO interface support"
+ depends on ARCH_MICROCHIP || COMPILE_TEST
depends on HAS_IOMEM && OF_MDIO
help
This driver supports the MDIO interface found on the PIC64-HPSC/HX
--
2.43.0
^ permalink raw reply related
* [syzbot] [lvs?] BUG: sleeping function called from invalid context in ip_vs_conn_expire
From: syzbot @ 2026-04-14 10:30 UTC (permalink / raw)
To: coreteam, davem, edumazet, fw, horms, ja, kuba, linux-kernel,
lvs-devel, netdev, netfilter-devel, pabeni, pablo, phil,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 1c7cc4904160 Add linux-next specific files for 20260413
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10327cd2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=56c2b36de3316f1b
dashboard link: https://syzkaller.appspot.com/bug?extid=504e778ddaecd36fdd17
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/91a765b703da/disk-1c7cc490.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/da75a3061146/vmlinux-1c7cc490.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d55367ced048/bzImage-1c7cc490.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+504e778ddaecd36fdd17@syzkaller.appspotmail.com
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 16, name: ktimers/0
preempt_count: 2, expected: 0
RCU nest depth: 3, expected: 3
8 locks held by ktimers/0/16:
#0: ffffffff8de5f260 (local_bh){.+.+}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
#1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
#2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
#2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: timer_base_lock_expiry kernel/time/timer.c:1502 [inline]
#2: ffff8880b8826360 (&base->expiry_lock){+...}-{3:3}, at: __run_timer_base+0x120/0x9f0 kernel/time/timer.c:2384
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
#3: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
#4: ffffc90000157a80 ((&cp->timer)){+...}-{0:0}, at: call_timer_fn+0xd4/0x5e0 kernel/time/timer.c:1745
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:315 [inline]
#5: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: ip_vs_conn_expire+0x257/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
#6: ffffffff8de5f260 (local_bh){.+.+}-{1:3}, at: __local_bh_disable_ip+0x3c/0x420 kernel/softirq.c:163
#7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
#7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:324 [inline]
#7: ffff888068d4c3f0 (&cp->lock#2){+...}-{3:3}, at: ip_vs_conn_expire+0xd4a/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
Preemption disabled at:
[<ffffffff898a6358>] bit_spin_lock include/linux/bit_spinlock.h:38 [inline]
[<ffffffff898a6358>] hlist_bl_lock+0x18/0x110 include/linux/list_bl.h:149
CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G W L syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [W]=WARN, [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
__might_resched+0x329/0x480 kernel/sched/core.c:9162
__rt_spin_lock kernel/locking/spinlock_rt.c:48 [inline]
rt_spin_lock+0xc2/0x400 kernel/locking/spinlock_rt.c:57
spin_lock include/linux/spinlock_rt.h:45 [inline]
ip_vs_conn_unlink net/netfilter/ipvs/ip_vs_conn.c:324 [inline]
ip_vs_conn_expire+0xd4a/0x2390 net/netfilter/ipvs/ip_vs_conn.c:1260
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
run_ktimerd+0x69/0x100 kernel/softirq.c:1151
smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Marek Vasut @ 2026-04-14 10:26 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Jakub Kicinski, netdev, stable, David S. Miller, Andrew Lunn,
Eric Dumazet, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Yicong Hui, linux-kernel, Thomas Gleixner
In-Reply-To: <20260414085556.SJSDwbpW@linutronix.de>
On 4/14/26 10:55 AM, Sebastian Andrzej Siewior wrote:
> On 2026-04-13 18:03:38 [+0200], To Marek Vasut wrote:
>> On 2026-04-13 17:31:34 [+0200], Marek Vasut wrote:
>>>> I don't see why it needs to disable interrupts.
>>>
>>> Because when the lock is held, the PAR code shouldn't be interrupted by an
>>> interrupt, otherwise it would completely mess up the state of the KS8851
>>> MAC. The spinlock does not protect only the IRQ handler, it protects also
>>> ks8851_start_xmit_par() and ks8851_write_mac_addr() and
>>> ks8851_read_mac_addr() and ks8851_net_open() and ks8851_net_stop() and other
>>> sites which call ks8851_lock()/ks8851_unlock() which cannot be executed
>>> concurrently, but where BHs can be enabled.
>>
>> I need check this once brain is at full power again. But which
>> interrupt? Your interrupt is threaded. So that should be okay.
>
> I don't understand. There is no point in using spin_lock_irqsave() in
> ks8851_lock_par(). You don't protect against interrupts because none of
> the user actually run in an interrupt. As far as I can see, the
> interrupt is threaded and the mdio phy link checks should come from the
> workqueue.
Ha, now that the IRQ handler is indeed only threaded, I can use
spin_lock_bh() indeed. I will send a V3 like that.
> What is wrong is that the ndo_start_xmit callback can be invoked from a
> softirq and such you must disable BHs while acquiring a lock which can
> be accessed from both contexts. Therefore spin_lock() is not sufficient,
> it needs the _bh() and _irq() brings no additional value here.
^ permalink raw reply
* Re: [PATCH net v2] atm: mpoa: keep mpc->dev referenced across mpoad restart
From: Paolo Abeni @ 2026-04-14 10:25 UTC (permalink / raw)
To: Shuvam Pandey, David S . Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, netdev
Cc: linux-kernel, syzbot+5ec223ccb83b24ef982f
In-Reply-To: <20260411115958.64827-1-shuvampandey1@gmail.com>
On 4/11/26 1:59 PM, Shuvam Pandey wrote:
> atm: mpoa: keep mpc->dev referenced across mpoad restart
>
> syzbot reported a netdevice refcount warning:
>
> refcount_t: decrement hit 0; leaking memory.
> WARNING: lib/refcount.c:31 at refcount_warn_saturate+0x70/0x110
> ...
> dev_put include/linux/netdevice.h:4466 [inline]
> mpoad_close+0x1fc/0x3e0 net/atm/mpc.c:889
The full decoded backtrace is preferred to a small excerpt
> mpoad_close() drops the reference held in mpc->dev, but the mpoa_client
> itself stays alive and keeps the same device pointer.
>
> When mpoad is attached again, atm_mpoa_mpoad_attach() reuses the existing
> mpoa_client and its mpc->dev without reacquiring that reference, so the
> next close can hit the netdevice refcount warning.
>
> This reference is owned by the mpoa_client/LEC association rather than a
> single mpoad open/close cycle. It is acquired when the client gets its
> LEC device and is released later from mpoa_event_listener() on
> NETDEV_UNREGISTER. Fix the imbalance by removing the dev_put() from
> mpoad_close().
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+5ec223ccb83b24ef982f@syzkaller.appspotmail.com
> Link: https://groups.google.com/g/syzkaller-bugs/c/qhZ5MJfLBOE/m/UnotmgRdAQAJ
Preferred link is to the syzbot console:
https://syzkaller.appspot.com/bug?extid=5ec223ccb83b24ef982f
> Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
> ---
> Changes in v2:
> - drop the atm_mpoa_cleanup() dev_put()/NULL hunk
> - add the syzbot warning excerpt
> - add a Fixes tag
> - clarify that the final dev_put() comes from the notifier path
>
> net/atm/mpc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/atm/mpc.c b/net/atm/mpc.c
> index ce8e9780373b9..90ab8f2889734 100644
> --- a/net/atm/mpc.c
> +++ b/net/atm/mpc.c
> @@ -886,7 +886,6 @@ static void mpoad_close(struct atm_vcc *vcc)
> struct lec_priv *priv = netdev_priv(mpc->dev);
> priv->lane2_ops->associate_indicator = NULL;
> stop_mpc(mpc);
> - dev_put(mpc->dev);
Sashiko noted a possible regression introduced by this change:
Since this patch removes the dev_put(mpc->dev) here to defer the
netdevice reference release to the NETDEV_UNREGISTER event, does this
introduce a leak of the netdevice reference on module unload?
If the atm_mpoa module is unloaded while a lec device is still active,
atm_mpoa_cleanup() unregisters the netdevice notifier and frees all
mpoa_client structures without releasing their mpc->dev references:
net/atm/mpc.c:atm_mpoa_cleanup() {
...
unregister_netdevice_notifier(&mpoa_notifier);
...
while (mpc != NULL) {
tmp = mpc->next;
if (mpc->dev != NULL) {
stop_mpc(mpc);
...
}
...
kfree(mpc->mps_macs);
kfree(mpc);
mpc = tmp;
}
}
Because the notifier is unregistered, NETDEV_UNREGISTER will never be
delivered to clean up the references, which would permanently leak the
netdevice reference and prevent the interface from ever being unregistered.
Should a dev_put() be added in the module exit function atm_mpoa_cleanup()?
/P
^ permalink raw reply
* [PATCH] nfc: s3fwrn5: switch to GPIO descriptor API
From: deep @ 2026-04-14 10:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Linus Walleij, Bartosz Golaszewski, netdev, linux-nfc,
linux-kernel, linux-gpio, Kenet Jovan Sokoli
From: Kenet Jovan Sokoli <deep@crimson.net.eu.org>
I am working on cleaning up some legacy GPIO usage in the NFC subsystem.
This patch converts the s3fwrn5 driver to use the modern descriptor based
GPIO API instead of the old integer based one.
Specifically:
- I changed the gpio_en and gpio_fw_wake types to struct gpio_desc.
- Replaced the manual DT parsing with devm_gpiod_get() in the probe
functions.
- Updated the calls in phy_common.c to use gpiod_set_value().
This also allowed me to remove the s3fwrn5_i2c_parse_dt and
s3fwrn82_uart_parse_dt functions as they are no longer needed with the
new API.
Signed-off-by: Kenet Jovan Sokoli <deep@crimson.net.eu.org>
---
I have verified that this patch builds successfully with "make M=drivers/nfc/s3fwrn5"
"scripts/checkpatch.pl" with no errors or warnings.
This is very complicated stuff, but I am learning a lot by doing these cleanup works.
I really hope I can contribute as much as possible to this environment, little by little.
---
drivers/nfc/s3fwrn5/i2c.c | 58 ++++++--------------------------
drivers/nfc/s3fwrn5/phy_common.c | 12 +++----
drivers/nfc/s3fwrn5/phy_common.h | 5 +--
drivers/nfc/s3fwrn5/uart.c | 43 ++++++-----------------
4 files changed, 31 insertions(+), 87 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
index 110d086cfe5b..a629fbcd3237 100644
--- a/drivers/nfc/s3fwrn5/i2c.c
+++ b/drivers/nfc/s3fwrn5/i2c.c
@@ -8,9 +8,8 @@
#include <linux/clk.h>
#include <linux/i2c.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/delay.h>
-#include <linux/of_gpio.h>
#include <linux/of_irq.h>
#include <linux/module.h>
@@ -146,37 +145,6 @@ static irqreturn_t s3fwrn5_i2c_irq_thread_fn(int irq, void *phy_id)
return IRQ_HANDLED;
}
-static int s3fwrn5_i2c_parse_dt(struct i2c_client *client)
-{
- struct s3fwrn5_i2c_phy *phy = i2c_get_clientdata(client);
- struct device_node *np = client->dev.of_node;
-
- if (!np)
- return -ENODEV;
-
- phy->common.gpio_en = of_get_named_gpio(np, "en-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_en)) {
- /* Support also deprecated property */
- phy->common.gpio_en = of_get_named_gpio(np,
- "s3fwrn5,en-gpios",
- 0);
- if (!gpio_is_valid(phy->common.gpio_en))
- return -ENODEV;
- }
-
- phy->common.gpio_fw_wake = of_get_named_gpio(np, "wake-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_fw_wake)) {
- /* Support also deprecated property */
- phy->common.gpio_fw_wake = of_get_named_gpio(np,
- "s3fwrn5,fw-gpios",
- 0);
- if (!gpio_is_valid(phy->common.gpio_fw_wake))
- return -ENODEV;
- }
-
- return 0;
-}
-
static int s3fwrn5_i2c_probe(struct i2c_client *client)
{
struct s3fwrn5_i2c_phy *phy;
@@ -193,21 +161,17 @@ static int s3fwrn5_i2c_probe(struct i2c_client *client)
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
- ret = s3fwrn5_i2c_parse_dt(client);
- if (ret < 0)
- return ret;
-
- ret = devm_gpio_request_one(&phy->i2c_dev->dev, phy->common.gpio_en,
- GPIOF_OUT_INIT_HIGH, "s3fwrn5_en");
- if (ret < 0)
- return ret;
-
- ret = devm_gpio_request_one(&phy->i2c_dev->dev,
- phy->common.gpio_fw_wake,
- GPIOF_OUT_INIT_LOW, "s3fwrn5_fw_wake");
- if (ret < 0)
- return ret;
+ phy->common.gpio_en = devm_gpiod_get(&client->dev, "en", GPIOD_OUT_HIGH);
+ if (IS_ERR(phy->common.gpio_en)) {
+ return dev_err_probe(&client->dev, PTR_ERR(phy->common.gpio_en),
+ "Failed to get EN gpio\n");
+ }
+ phy->common.gpio_fw_wake = devm_gpiod_get(&client->dev, "wake", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->common.gpio_fw_wake)) {
+ return dev_err_probe(&client->dev, PTR_ERR(phy->common.gpio_fw_wake),
+ "Failed to get WAKE gpio\n");
+ }
/*
* S3FWRN5 depends on a clock input ("XI" pin) to function properly.
* Depending on the hardware configuration this could be an always-on
diff --git a/drivers/nfc/s3fwrn5/phy_common.c b/drivers/nfc/s3fwrn5/phy_common.c
index deb2c039f0fd..e802b4e609c8 100644
--- a/drivers/nfc/s3fwrn5/phy_common.c
+++ b/drivers/nfc/s3fwrn5/phy_common.c
@@ -8,7 +8,7 @@
* Bongsu Jeon <bongsu.jeon@samsung.com>
*/
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/delay.h>
#include <linux/module.h>
@@ -19,7 +19,7 @@ void s3fwrn5_phy_set_wake(void *phy_id, bool wake)
struct phy_common *phy = phy_id;
mutex_lock(&phy->mutex);
- gpio_set_value(phy->gpio_fw_wake, wake);
+ gpiod_set_value(phy->gpio_fw_wake, wake);
if (wake)
msleep(S3FWRN5_EN_WAIT_TIME);
mutex_unlock(&phy->mutex);
@@ -33,14 +33,14 @@ bool s3fwrn5_phy_power_ctrl(struct phy_common *phy, enum s3fwrn5_mode mode)
phy->mode = mode;
- gpio_set_value(phy->gpio_en, 1);
- gpio_set_value(phy->gpio_fw_wake, 0);
+ gpiod_set_value(phy->gpio_en, 1);
+ gpiod_set_value(phy->gpio_fw_wake, 0);
if (mode == S3FWRN5_MODE_FW)
- gpio_set_value(phy->gpio_fw_wake, 1);
+ gpiod_set_value(phy->gpio_fw_wake, 1);
if (mode != S3FWRN5_MODE_COLD) {
msleep(S3FWRN5_EN_WAIT_TIME);
- gpio_set_value(phy->gpio_en, 0);
+ gpiod_set_value(phy->gpio_en, 0);
msleep(S3FWRN5_EN_WAIT_TIME);
}
diff --git a/drivers/nfc/s3fwrn5/phy_common.h b/drivers/nfc/s3fwrn5/phy_common.h
index 9cef25436bf9..10210a8fd755 100644
--- a/drivers/nfc/s3fwrn5/phy_common.h
+++ b/drivers/nfc/s3fwrn5/phy_common.h
@@ -13,6 +13,7 @@
#include <linux/mutex.h>
#include <net/nfc/nci_core.h>
+#include <linux/gpio/consumer.h>
#include "s3fwrn5.h"
@@ -21,8 +22,8 @@
struct phy_common {
struct nci_dev *ndev;
- int gpio_en;
- int gpio_fw_wake;
+ struct gpio_desc *gpio_en;
+ struct gpio_desc *gpio_fw_wake;
struct mutex mutex;
diff --git a/drivers/nfc/s3fwrn5/uart.c b/drivers/nfc/s3fwrn5/uart.c
index 4ee481bd7e96..5a7c7741a881 100644
--- a/drivers/nfc/s3fwrn5/uart.c
+++ b/drivers/nfc/s3fwrn5/uart.c
@@ -15,8 +15,7 @@
#include <linux/netdevice.h>
#include <linux/of.h>
#include <linux/serdev.h>
-#include <linux/gpio.h>
-#include <linux/of_gpio.h>
+#include <linux/gpio/consumer.h>
#include "phy_common.h"
@@ -92,25 +91,6 @@ static const struct of_device_id s3fwrn82_uart_of_match[] = {
};
MODULE_DEVICE_TABLE(of, s3fwrn82_uart_of_match);
-static int s3fwrn82_uart_parse_dt(struct serdev_device *serdev)
-{
- struct s3fwrn82_uart_phy *phy = serdev_device_get_drvdata(serdev);
- struct device_node *np = serdev->dev.of_node;
-
- if (!np)
- return -ENODEV;
-
- phy->common.gpio_en = of_get_named_gpio(np, "en-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_en))
- return -ENODEV;
-
- phy->common.gpio_fw_wake = of_get_named_gpio(np, "wake-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_fw_wake))
- return -ENODEV;
-
- return 0;
-}
-
static int s3fwrn82_uart_probe(struct serdev_device *serdev)
{
struct s3fwrn82_uart_phy *phy;
@@ -144,20 +124,19 @@ static int s3fwrn82_uart_probe(struct serdev_device *serdev)
serdev_device_set_flow_control(serdev, false);
- ret = s3fwrn82_uart_parse_dt(serdev);
- if (ret < 0)
- goto err_serdev;
-
- ret = devm_gpio_request_one(&phy->ser_dev->dev, phy->common.gpio_en,
- GPIOF_OUT_INIT_HIGH, "s3fwrn82_en");
- if (ret < 0)
+ phy->common.gpio_en = devm_gpiod_get(&serdev->dev, "en", GPIOD_OUT_HIGH);
+ if (IS_ERR(phy->common.gpio_en)) {
+ ret = dev_err_probe(&serdev->dev, PTR_ERR(phy->common.gpio_en),
+ "failed to get en gpio\n");
goto err_serdev;
+ }
- ret = devm_gpio_request_one(&phy->ser_dev->dev,
- phy->common.gpio_fw_wake,
- GPIOF_OUT_INIT_LOW, "s3fwrn82_fw_wake");
- if (ret < 0)
+ phy->common.gpio_fw_wake = devm_gpiod_get(&serdev->dev, "wake", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->common.gpio_fw_wake)) {
+ ret = dev_err_probe(&serdev->dev, PTR_ERR(phy->common.gpio_fw_wake),
+ "failed to get wake gpio\n");
goto err_serdev;
+ }
ret = s3fwrn5_probe(&phy->common.ndev, phy, &phy->ser_dev->dev,
&uart_phy_ops);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
From: patchwork-bot+netdevbpf @ 2026-04-14 10:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-usb, netdev, linux-kernel, andrew+netdev, davem, edumazet,
kuba, pabeni, stable
In-Reply-To: <2026041134-dreamboat-buddhism-d1ec@gregkh>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 11 Apr 2026 13:01:35 +0200 you wrote:
> A malicious USB device claiming to be a CDC Phonet modem can overflow
> the skb_shared_info->frags[] array by sending an unbounded sequence of
> full-page bulk transfers.
>
> Drop the skb and increment the length error when the frag limit is
> reached. This matches the same fix that commit f0813bcd2d9d ("net:
> wwan: t7xx: fix potential skb->frags overflow in RX path") did for the
> t7xx driver.
>
> [...]
Here is the summary with links:
- [net] net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
https://git.kernel.org/netdev/net/c/600dc40554dc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: ethernet: ravb: Do not check URAM suspension when WoL is active
From: Geert Uytterhoeven @ 2026-04-14 10:20 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Yoshihiro Shimoda, netdev,
linux-renesas-soc
In-Reply-To: <20260412173213.3179426-1-niklas.soderlund+renesas@ragnatech.se>
On Sun, 12 Apr 2026 at 19:33, Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> 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>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
^ permalink raw reply
* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Marek Vasut @ 2026-04-14 10:07 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Jakub Kicinski
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Nicolai Buchwitz, Paolo Abeni, Ronald Wahl, Yicong Hui,
linux-kernel, Thomas Gleixner
In-Reply-To: <20260413161000.P_SLxmZl@linutronix.de>
On 4/13/26 6:10 PM, Sebastian Andrzej Siewior wrote:
>> TBH changing the driver feels like a workaround / invitation for a
>> whack-a-mole game. I'd prefer to fix the skb allocation.
>
> The problem is that _irq() implicitly disables bh processing but this
> does not happen. Forcing this is possible but expensive.
> However, I did remove lock from bh_disable() on RT.
>
> Marek: from which kernel version was this backtrace?
That was v6.12.79-rt17-rebase where it was easy to trigger , here is a
fresh one from next-20260413 with b44596ffe1b4 ("ARM: Allow to enable
RT") from stable-rt added on top:
"
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P127/5:b..l
rcu: (detected by 1, t=2102 jiffies, g=-503, q=1 ncpus=2)
task:irq/68-eth1 state:D stack:0 pid:127 tgid:127 ppid:2
task_flags:0x4208040 flags:0x00000000
Call trace:
__schedule from schedule_rtlock+0x1c/0x34
schedule_rtlock from rtlock_slowlock_locked+0x548/0x904
rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c
rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8
ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44
netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188
dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
sch_direct_xmit from __qdisc_run+0x1f8/0x4ec
__qdisc_run from qdisc_run+0x1c/0x28
qdisc_run from net_tx_action+0x1f0/0x268
net_tx_action from handle_softirqs+0x1a4/0x270
handle_softirqs from __local_bh_enable_ip+0xcc/0xe0
__local_bh_enable_ip from __alloc_skb+0xd8/0x128
__alloc_skb from __netdev_alloc_skb+0x3c/0x19c
__netdev_alloc_skb from ks8851_irq+0x388/0x4d4
ks8851_irq from irq_thread_fn+0x24/0x64
irq_thread_fn from irq_thread+0x178/0x28c
irq_thread from kthread+0x12c/0x138
kthread from ret_from_fork+0x14/0x28
Exception stack(0xf4c99fb0 to 0xf4c99ff8)
9fa0: 00000000 00000000 00000000
00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
"
^ permalink raw reply
* Re: [PATCH net] net: sched: em_text: require NUL-terminated algo name
From: Paolo Abeni @ 2026-04-14 10:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, netdev
Cc: linux-kernel, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Simon Horman, stable
In-Reply-To: <2026041150-task-path-81dd@gregkh>
On 4/11/26 1:10 PM, Greg Kroah-Hartman wrote:
> em_text_change() copies the user-supplied tcf_em_text struct from
> netlink and passes conf->algo straight to textsearch_prepare(), which
> forwards it to lookup_ts_algo() (strcmp) and request_module() (vsnprintf
> %s). But the algo[16] field is never validated to be NULL-terminated,
> so a fully populated array reads past it into the adjacent
> from_offset/to_offset/pattern_len fields and the trailing pattern bytes
> during the string operations.
>
> This type of pattern is properly checked in the string_mt_check() for
> xt_string netfilter matching function, but for some reason was not added
> here, so fix this up by doing the same exact thing.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Fixes: d675c989ed2d ("[PKT_SCHED]: Packet classification based on textsearch (ematch)")
> Cc: stable <stable@kernel.org>
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> Note, my tools flagged this, so I fixed this up the same way that
> string_mt_check() did, but if there is some other way that this should
> be resolved, or I got this totally wrong that this isn't an issue,
> please let me know, thanks!
>
>
> net/sched/em_text.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sched/em_text.c b/net/sched/em_text.c
> index 343f1aebeec2..24a8aa21971d 100644
> --- a/net/sched/em_text.c
> +++ b/net/sched/em_text.c
> @@ -58,6 +58,9 @@ static int em_text_change(struct net *net, void *data, int len,
> if (len < sizeof(*conf) || len < (sizeof(*conf) + conf->pattern_len))
> return -EINVAL;
>
> + if (conf->algo[sizeof(conf->algo) - 1] != '\0')
> + return -EINVAL;
The addressed issue looks real to me, but sashiko found a problem with
this fix:
---
Is this NUL-termination check too strict and could it introduce an ABI
regression?
If a userspace application sends a valid, NUL-terminated string that is
shorter than 15 characters, but does not explicitly zero-pad the
remaining uninitialized bytes in the tcf_em_text struct, this check will
fail with -EINVAL.
Prior to this patch, the kernel's string operations safely stopped
reading at the first \0 byte, correctly processing these shorter
strings. Rejecting previously valid structures breaks backward
compatibility with existing userspace binaries.
Would it be better to check for NUL-termination using memchr() or
strnlen() instead? For example, memchr(conf->algo, '\0',
sizeof(conf->algo)) == NULL.
---
/P
^ permalink raw reply
* Re: [PATCH] net: Optimize flush calculation in inet_gro_receive()
From: Eric Dumazet @ 2026-04-14 9:57 UTC (permalink / raw)
To: David Laight
Cc: Helge Deller, Kuniyuki Iwashima, deller, davem, dsahern,
linux-kernel, linux-parisc, netdev
In-Reply-To: <20260414103633.4d5fe92a@pumpkin>
On Tue, Apr 14, 2026 at 2:36 AM David Laight
<david.laight.linux@gmail.com> wrote:
> The network stack is supposed to ensure that all receive packets are
> aligned to that IP header is on a 4-byte boundary.
> This typically requires the ethernet receive buffer be 4n+2 aligned.
> Unfortunately there is some ethernet hardware that requires 4n aligned
> buffers (often on SoC devices with cpu that fault misaligned accesses).
> (Just writing two bytes of garbage before the frame solves the issue.)
This is mostly true, but depends on NET_IP_ALIGN,
On x86, this constant was changed to 0 back in 2010.
commit ea812ca1b06113597adcd8e70c0f84a413d97544
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue Jun 29 18:38:00 2010 +0000
x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
^ permalink raw reply
* Re: [PATCH net] net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
From: Paolo Abeni @ 2026-04-14 9:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb, netdev
Cc: linux-kernel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, stable
In-Reply-To: <2026041134-dreamboat-buddhism-d1ec@gregkh>
On 4/11/26 1:01 PM, Greg Kroah-Hartman wrote:
> A malicious USB device claiming to be a CDC Phonet modem can overflow
> the skb_shared_info->frags[] array by sending an unbounded sequence of
> full-page bulk transfers.
>
> Drop the skb and increment the length error when the frag limit is
> reached. This matches the same fix that commit f0813bcd2d9d ("net:
> wwan: t7xx: fix potential skb->frags overflow in RX path") did for the
> t7xx driver.
>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: stable <stable@kernel.org>
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It looks like the fixes tag should be:
Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver")
Right?
/P
^ permalink raw reply
* Re: [PATCH] net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler
From: Paolo Abeni @ 2026-04-14 9:41 UTC (permalink / raw)
To: Pavitra Jha, w; +Cc: chandrashekar.devegowda, linux-wwan, netdev, stable
In-Reply-To: <20260411083957.567676-1-jhapavitra98@gmail.com>
On 4/11/26 10:39 AM, Pavitra Jha wrote:
> t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as
> a loop bound over port_msg->data[] without checking that the message buffer
> contains sufficient data. A modem sending port_count=65535 in a 12-byte
> buffer triggers a slab-out-of-bounds read of up to 262140 bytes.
>
> Add a struct_size() check after extracting port_count and before the loop.
> Pass msg_len from both call sites: skb->len at the DPMAIF path after
> skb_pull(), and the captured rt_feature->data_len at the handshake path.
>
> Fixes: 1e3e8eb9b6e3 ("net: wwan: t7xx: Add control DMA interface")
Wrong fixes tag:
fatal: ambiguous argument '1e3e8eb9b6e3': unknown revision or path not
in the working tree.
> diff --git a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> index ae632ef96..d984a688d 100644
> --- a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> +++ b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> @@ -124,7 +124,7 @@ static int fsm_ee_message_handler(struct t7xx_port *port, struct t7xx_fsm_ctl *c
> * * 0 - Success.
> * * -EFAULT - Message check failure.
> */
> -int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg)
> +int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg, size_t msg_len)
Undocumented new argument
/P
^ permalink raw reply
* Re: [PATCH iwl-next 10/10] ice: promote Tx FIFO drain timeout message from dev_dbg to dev_warn
From: Simon Horman @ 2026-04-14 9:39 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller
In-Reply-To: <20260410074921.1254213-11-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:21AM +0200, Aleksandr Loktionov wrote:
> The message emitted when the Tx FIFO fails to drain within the
> timeout period is currently at dev_dbg level, making it invisible
> unless debug logging is enabled. Promote it to dev_warn so that
> users and administrators can detect Tx timestamp path issues
> without enabling extra logging.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH iwl-next 9/10] ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir
From: Simon Horman @ 2026-04-14 9:39 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Larysa Zaremba
In-Reply-To: <20260410074921.1254213-10-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:20AM +0200, Aleksandr Loktionov wrote:
> Replace static full_ipv6_addr_mask / zero_ipv6_addr_mask structs
> and the associated memcmp() calls in ice_ethtool_fdir.c with the
> kernel-provided ipv6_addr_any() helper and a new ice_ipv6_mask_full()
> inline, reducing boilerplate and making intent clearer.
>
> Suggested-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH iwl-next 8/10] ice: move ice_phy_get_speed_eth56g() from ice_ptp_hw.c to ice_common.c
From: Simon Horman @ 2026-04-14 9:38 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260410074921.1254213-9-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:19AM +0200, Aleksandr Loktionov wrote:
> ice_phy_get_speed_eth56g() is currently a file-local (static)
> helper in ice_ptp_hw.c. Future users outside that compilation
> unit require access to it.
FWIIW, I think it would be slightly better if this patch was accompanied by
such a user.
>
> Move the function to ice_common.c, add a declaration in
> ice_common.h, and relocate the enum ice_eth56g_link_spd from
> ice_ptp_hw.h to ice_type.h so it is visible to callers of the
> new exported function.
>
> Suggested-by: Karol Kolacinski <karol.kolacinski@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: Optimize flush calculation in inet_gro_receive()
From: David Laight @ 2026-04-14 9:36 UTC (permalink / raw)
To: Helge Deller
Cc: Kuniyuki Iwashima, deller, davem, dsahern, linux-kernel,
linux-parisc, netdev, edumazet
In-Reply-To: <49c05cd8-5ad0-4015-8f55-fed3416784bf@gmx.de>
On Tue, 14 Apr 2026 09:46:55 +0200
Helge Deller <deller@gmx.de> wrote:
> Hi Kikuyu and David,
...
> >>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> >>> index c7731e300a44..58cad2687c2c 100644
> >>> --- a/net/ipv4/af_inet.c
> >>> +++ b/net/ipv4/af_inet.c
> >>> @@ -1479,7 +1479,7 @@ struct sk_buff *inet_gro_receive(struct list_head *head, struct sk_buff *skb)
> >>> struct sk_buff *p;
> >>> unsigned int hlen;
> >>> unsigned int off;
> >>> - int flush = 1;
> >>> + u16 flush = 1;
> >>> int proto;
> >>>
> >>> off = skb_gro_offset(skb);
> >>> @@ -1504,7 +1504,8 @@ struct sk_buff *inet_gro_receive(struct list_head *head, struct sk_buff *skb)
> >>> goto out;
> >>>
> >>> NAPI_GRO_CB(skb)->proto = proto;
> >>> - flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (ntohl(*(__be32 *)&iph->id) & ~IP_DF));
> >>> + flush = (get_unaligned_be16(&iph->tot_len) ^ skb_gro_len(skb)) |
> >>> + (get_unaligned_be16(&iph->frag_off) & ~IP_DF);
> >>
> >> I think here we intentionally use 32-bit loads:
> >>
> >> commit
> >> Author: Herbert Xu <herbert@gondor.apana.org.au>
> >> Date: Tue May 26 18:50:29 2009
> >>
> >> ipv4: Use 32-bit loads for ID and length in GRO
>
> I see, this patch is exactly the opposite of mine.
>
> >> Before your patch, 32-bit load + bswap are used while
> >> 16-bit load + rol 8 after the change.
> >>
> >> I feel the 4-byte aligned load + bswap is faster than
> >> misaligned access + 8 times shift (Is this internally
> >> optimised like xchg for a single word size ?)
> >>
> >> Do you have some numbers ?
>
> No, I don't have.
> In the end it's very platform specific anyway.
>
> > Check on some architecture that doesn't support misaligned loads.
> > Actually, aren't the accesses aligned??
>
> The reason why I touched this code at all, is because I got unaligned
> accesses in that function on parisc.
> But those unaligned accesses were triggered by parisc-specific
> inline assembly, and not by this code here.
The network stack is supposed to ensure that all receive packets are
aligned to that IP header is on a 4-byte boundary.
This typically requires the ethernet receive buffer be 4n+2 aligned.
Unfortunately there is some ethernet hardware that requires 4n aligned
buffers (often on SoC devices with cpu that fault misaligned accesses).
(Just writing two bytes of garbage before the frame solves the issue.)
> So, I believe those accesses here are aligned, and the get_unaligned_XX()
> helpers make the code more readable, but are NOT necessary.
>
> That said, I suggest to drop my patch.
> It makes the code more readable, but probably will not improve speed.
I think the purpose of the change was to use the hardware's 32bit
byte-swapping memory loads rather than software swapping of the
16-bit items.
That shaves off a few instructions - and they can be measurable
in some of the network paths with specific workloads.
Remember, save 0.1% 100 times and the code runs 10% faster.
Every little bit can make a difference.
David
>
> Thanks for your help!
> Helge
>
> > Also on ones without 32bit byteswap (some do have byteswapping
> > memory reads).
> >
> > Also you may not want to change 'flush' to u16.
> > On non-x86 it may force the compiler add extra masking instructions.
> >
> > David
> >
> >>
> >>
> >> Before:
> >> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb))
> >> mov edx,DWORD PTR [rcx]
> >> bswap edx
> >> return skb->len - NAPI_GRO_CB(skb)->data_offset;
> >> mov r8d,DWORD PTR [rsi+0x38]
> >> mov r9d,DWORD PTR [rsi+0x70]
> >> sub r9d,r8d
> >> xor r9d,edx
> >> | (ntohl(*(__be32 *)&iph->id) & ~IP_DF));
> >> mov ebp,0xffbfffff
> >> and ebp,DWORD PTR [rcx+0x4]
> >> bswap ebp
> >> or ebp,r9d
> >>
> >>
> >> After:
> >> flush = (get_unaligned_be16(&iph->tot_len) ^ skb_gro_len(skb))
> >> movzx edx,WORD PTR [rcx+0x2]
> >> rol dx,0x8
> >> return skb->len - NAPI_GRO_CB(skb)->data_offset;
> >> mov r8d,DWORD PTR [rsi+0x38]
> >> mov r9d,DWORD PTR [rsi+0x70]
> >> sub r9d,r8d
> >> xor r9d,edx
> >> | (get_unaligned_be16(&iph->frag_off) & ~IP_DF);
> >> movzx ebp,WORD PTR [rcx+0x6]
> >> and ebp,0xffffffbf
> >> rol bp,0x8
> >> or ebp,r9d
> >>
> >
>
^ permalink raw reply
* Re: [PATCH iwl-next 7/10] ice: emit user-visible info message for non-contiguous ETS TC config
From: Simon Horman @ 2026-04-14 9:35 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Karen Ostrowska
In-Reply-To: <20260410074921.1254213-8-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:18AM +0200, Aleksandr Loktionov wrote:
> When the remote LLDP peer advertises a non-contiguous TC
> mapping the driver silently falls back to a default single-TC
> configuration. This leaves the user without any indication of
> why their DCB configuration was not honoured.
>
> Print an informational message at the entry of
> ice_dcb_noncontig_cfg() so the user knows ETS with
> non-contiguous TCs is not supported and that the driver
> has fallen back to defaults.
>
> Suggested-by: Karen Ostrowska <karen.ostrowska@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> index bd77f1c..1c53b09 100644
> --- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> @@ -712,6 +712,8 @@ static int ice_dcb_noncontig_cfg(struct ice_pf *pf)
> struct device *dev = ice_pf_to_dev(pf);
> int ret;
>
> + dev_info(dev, "Non-contiguous ETS TC config not supported, falling back to default single TC\n");
Sashiko points out that this seems to be controlled by user input.
If so, it should probably be rate limited.
> +
> /* Configure SW DCB default with ETS non-willing */
> ret = ice_dcb_sw_dflt_cfg(pf, false, true);
> if (ret) {
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH net 1/1] net: bridge: use a stable FDB dst snapshot in RCU readers
From: Nikolay Aleksandrov @ 2026-04-14 9:33 UTC (permalink / raw)
To: Ren Wei, bridge, netdev
Cc: idosch, davem, edumazet, kuba, pabeni, horms, makita.toshiaki,
vyasevic, yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
zcliangcn
In-Reply-To: <6570fabb85ecadb8baaf019efe856f407711c7b9.1776043229.git.zcliangcn@gmail.com>
On 13/04/2026 12:08, Ren Wei wrote:
> From: Zhengchuan Liang <zcliangcn@gmail.com>
>
> Local FDB entries can be rewritten in place by `fdb_delete_local()`, which
> updates `f->dst` to another port or to `NULL` while keeping the entry
> alive. Several bridge RCU readers inspect `f->dst`, including
> `br_fdb_fillbuf()` through the `brforward_read()` sysfs path.
>
> These readers currently load `f->dst` multiple times and can therefore
> observe inconsistent values across the check and later dereference.
> In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change
> `f->dst` after the NULL check and before the `port_no` dereference,
> leading to a NULL-ptr-deref.
>
> Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each
> affected RCU reader and using that snapshot for the rest of the access
> sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()`
> with `WRITE_ONCE()` so the readers and writer use matching access patterns.
>
> Fixes: 960b589f86c7 ("bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address")
> Cc: stable@kernel.org
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/bridge/br_arp_nd_proxy.c | 8 +++++---
> net/bridge/br_fdb.c | 28 ++++++++++++++++++----------
> 2 files changed, 23 insertions(+), 13 deletions(-)
>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH iwl-next 6/10] ice: increase OICR interrupt moderation rate to 20K interrupts/sec
From: Simon Horman @ 2026-04-14 9:33 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller
In-Reply-To: <20260410074921.1254213-7-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:17AM +0200, Aleksandr Loktionov wrote:
> The miscellaneous interrupt cause (OICR) is throttled to 8K
> interrupts per second (124 us minimum spacing). This interrupt
> handles VF mailbox messages and Tx timestamps, so the low rate
> imposes a minimum latency floor on both use-cases.
>
> Raise the rate to 20K interrupts per second (50 us minimum
> spacing) to allow lower latency handling for Tx timestamp
> bursts and high VF message rates.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@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