* Re: [PATCH net] NFC: digital: bound SENSF response copy into nfc_target
From: Jakub Kicinski @ 2026-04-13 18:41 UTC (permalink / raw)
To: Michael Bommarito
Cc: netdev, David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Kees Cook, stable, linux-kernel
In-Reply-To: <20260413174715.197640-1-michael.bommarito@gmail.com>
On Mon, 13 Apr 2026 13:47:15 -0400 Michael Bommarito wrote:
> Assisted-by: Claude:claude-opus-4-6
> Assisted-by: Codex:gpt-5-4
Could you do some experimentation and figure out what we can do to the
kernel to make the bots check the submission history? It's the 4th time
we received this (incorrect) patch.
^ permalink raw reply
* Re: [PATCH net-next v7 00/15] net: sleepable ndo_set_rx_mode
From: Jakub Kicinski @ 2026-04-13 18:45 UTC (permalink / raw)
To: netdev; +Cc: Stanislav Fomichev, davem, edumazet, pabeni
In-Reply-To: <20260413171131.550126-1-sdf@fomichev.me>
On Mon, 13 Apr 2026 10:11:16 -0700 Stanislav Fomichev wrote:
> This series adds a new ndo_set_rx_mode_async callback that enables
> drivers to handle address list updates in a sleepable context. The
> current ndo_set_rx_mode is called under the netif_addr_lock spinlock
> with BHs disabled, which prevents drivers from sleeping. This is
> problematic for ops-locked drivers that need to sleep.
A note to other reviewers - I asked Stanislav (off-list) to keep working
on this even tho he's targeting net-next, because the patch set
addresses a syzbot report. Chances of hitting the issue are low but
this is a fix, really.
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Russell King (Oracle) @ 2026-04-13 18:49 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev, Paolo Abeni,
Sam Edwards
In-Reply-To: <20260413110222.49fc3759@kernel.org>
On Mon, Apr 13, 2026 at 11:02:22AM -0700, Jakub Kicinski wrote:
> On Fri, 10 Apr 2026 14:07:51 +0100 Russell King (Oracle) wrote:
> > Since we are seeing receive buffer exhaustion on several platforms,
> > let's enable the interrupts so the statistics we publish via ethtool -S
> > actually work to aid diagnosis. I've been in two minds about whether
> > to send this patch, but given the problems with stmmac at the moment,
> > I think it should be merged.
>
> Sorry for a under-research response but wasn't there are person trying
> to fix the OOM starvation issue? Who was supposed to add a timer?
> Is your problem also OOM related or do you suspect something else?
It is not OOM related. I have this patch applied:
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 131ea887bedc..614d0e10e3e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5095,14 +5095,18 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
if (!buf->page) {
buf->page = page_pool_alloc_pages(rx_q->page_pool, gfp);
- if (!buf->page)
+ if (!buf->page) {
+ netdev_err(priv->dev, "q%u: no buffer 1\n", queue);
break;
+ }
}
if (priv->sph_active && !buf->sec_page) {
buf->sec_page = page_pool_alloc_pages(rx_q->page_pool, gfp);
- if (!buf->sec_page)
+ if (!buf->sec_page) {
+ netdev_err(priv->dev, "q%u: no buffer 2\n", queue);
break;
+ }
buf->sec_addr = page_pool_get_dma_addr(buf->sec_page);
}
and it is silent, so we are not suffering starvation of buffers.
However, the hardware hangs during iperf3, and because it triggers the
MAC to stream PAUSE frames, and my network uses Netgear GS108 and GS116
unmanaged switches that always use flow-control between them (there's no
way not to) it takes down the entire network - as we've discussed
before. So, this problem is pretty fatal to the *entire* network.
With this patch, the existing statistical counters for this condition
are incremented, and thus users can use ethtool -S to see what happened
and report whether they are seeing the same issue.
Without this patch applied, there are no diagnostics from stmmac that
report what the state is. ethtool -d doesn't list the appropriate
registers (as I suspect part of the problem is the number of queues
is somewhat dynamic - userspace can change that configuration through
ethtool).
Thus, one has to resort to using devmem2 to find out what's happened.
That's not user friendly.
For me, devmem2 shows:
Channel 0 status register:
Value at address 0x02491160: 0x00000484
bit 10: ETI early transmit interrupt - set
bit 9 : RWT receive watchdog - clear
bit 8 : RPS receieve process stopped - clear
bit 7 : RBU receive buffer unavailable - set
bit 6 : RI receive interrupt - clear
bit 2 : TBU transmit buffer unavailable - set
bit 1 : TPS transmit process stopped - clear
bit 0 : TI transmit interrupt - clear
Debug status register:
Value at address 0x0249100c: 0x00006300
TPS[3:0] = 6 = Suspended, Tx descriptor unavailable or Tx buffer
underflow
RPS[3:0] = 3 = Running, waiting for Rx packet
Metal Queue 0 debug register:
Value at address 0x02490d38: 0x002e0020
PRXQ[13:0] = 0x2e = 46 packets in receive queue
RXQSTS[1:0] = 2 = Rx queue fill-level above flow-control activate
threshold
RRCSTS[1:0] = 0 = Rx Queue Read Controller State = Idle
> Firing interrupts when Rx fill ring runs dry (which IIUC this patches
> dies?) is not a good idea.
Well, I'm thinking that at least on some platforms, such as the Jetson
Xavier NX, unless a different solution can be found, we need the RBU
interrupt to fire off a reset of the stmmac IP when this happens to
reduce the PAUSE frame flood on the network.
If we can't do that, then I think stmmac on these platforms needs to be
marked with CONFIG_BROKEN because right now there doesn't seem to be any
other viable solution.
My intention with this patch is merely to start collecting the already
existing statistics so other users can start seeing whether they are
hitting the same or similar problem. If we're not prepared to do that,
then we should delete the useless statistics from ethtool -S, but I
suspect they're now part of the UAPI, even though without this patch
they will remain stedfastly stuck at zero.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply related
* Re: [PATCH iproute 1/2] json_writer: support control character escaping
From: patchwork-bot+netdevbpf @ 2026-04-13 19:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20260410224745.93416-1-stephen@networkplumber.org>
Hello:
This series was applied to iproute2/iproute2.git (main)
by Stephen Hemminger <stephen@networkplumber.org>:
On Fri, 10 Apr 2026 15:47:44 -0700 you wrote:
> Iproute2 never handled control characters in strings correctly.
> There are some cases like where string is under user control
> like paths in ss command. Make iproute2 json output conform
> to RFC 8259.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
> [...]
Here is the summary with links:
- [iproute,1/2] json_writer: support control character escaping
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=9e99260759b7
- [iproute,2/2] json_writer: fix builtin test code
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=fe811be6564c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH iwl-net] ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
From: Petr Oros @ 2026-04-13 19:14 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Aleksandr Loktionov, Nikolay Aleksandrov, Daniel Zahka,
Paul Greenwalt, Dave Ertman, Michal Swiatkowski, jacob.e.keller,
intel-wired-lan, linux-kernel
On certain E810 configurations where firmware supports Tx scheduler
topology switching (tx_sched_topo_comp_mode_en), ice_cfg_tx_topo()
may need to apply a new 5-layer or 9-layer topology from the DDP
package. If the AQ command to set the topology fails (e.g. due to
invalid DDP data or firmware limitations), the global configuration
lock must still be cleared via a CORER reset.
Commit 86aae43f21cf ("ice: don't leave device non-functional if Tx
scheduler config fails") correctly fixed this by refactoring
ice_cfg_tx_topo() to always trigger CORER after acquiring the global
lock and re-initialize hardware via ice_init_hw() afterwards.
However, commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end
of deinit paths") later moved ice_init_dev_hw() into ice_init_hw(),
breaking the reinit path introduced by 86aae43f21cf. This creates an
infinite recursive call chain:
ice_init_hw()
ice_init_dev_hw()
ice_cfg_tx_topo() # topology change needed
ice_deinit_hw()
ice_init_hw() # reinit after CORER
ice_init_dev_hw() # recurse
ice_cfg_tx_topo()
... # stack overflow
Fix by moving ice_init_dev_hw() back out of ice_init_hw() and calling
it explicitly from ice_probe() and ice_devlink_reinit_up(). The third
caller, ice_cfg_tx_topo(), intentionally does not need ice_init_dev_hw()
during its reinit, it only needs the core HW reinitialization. This
breaks the recursion cleanly without adding flags or guards.
The deinit ordering changes from commit 8a37f9e2ff40 ("ice: move
ice_deinit_dev() to the end of deinit paths") which fixed slow rmmod
are preserved, only the init-side placement of ice_init_dev_hw() is
reverted.
Fixes: 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths")
Signed-off-by: Petr Oros <poros@redhat.com>
---
drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 ++
drivers/net/ethernet/intel/ice/ice_common.c | 2 --
drivers/net/ethernet/intel/ice/ice_main.c | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c b/drivers/net/ethernet/intel/ice/devlink/devlink.c
index 6144cee8034d77..641d6e289d5ce6 100644
--- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
+++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
@@ -1245,6 +1245,8 @@ static int ice_devlink_reinit_up(struct ice_pf *pf)
return err;
}
+ ice_init_dev_hw(pf);
+
/* load MSI-X values */
ice_set_min_max_msix(pf);
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
index ce11fea122d03e..b617a6bff89134 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -1126,8 +1126,6 @@ int ice_init_hw(struct ice_hw *hw)
if (status)
goto err_unroll_fltr_mgmt_struct;
- ice_init_dev_hw(hw->back);
-
mutex_init(&hw->tnl_lock);
ice_init_chk_recipe_reuse_support(hw);
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index e2a5534819d194..a27be29f9bbbfc 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5314,6 +5314,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
return err;
}
+ ice_init_dev_hw(pf);
+
adapter = ice_adapter_get(pdev);
if (IS_ERR(adapter)) {
err = PTR_ERR(adapter);
--
2.52.0
^ permalink raw reply related
* Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration
From: Leon Romanovsky @ 2026-04-13 19:19 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: <c3a6c6ca-3b71-476c-947a-5f2393d046bd@huawei.com>
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.
TPH is defined by the PCI specification. If a device intends to support it,
then it should conform to the specification.
Thanks
>
> Thanks
>
> >
> > Thanks
> >
> >>
> >> Best regards,
> >> Chengwen Feng
> >>
>
>
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-04-13 19:23 UTC (permalink / raw)
To: Zhiping Zhang
Cc: Keith Busch, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <CAH3zFs0hx_-3LetSUaPRMg=0jaL=GD7Mop3pEUhJ3O3qkaJrQg@mail.gmail.com>
On Mon, Apr 13, 2026 at 11:32:48AM -0700, Zhiping Zhang wrote:
> On Thu, Apr 9, 2026 at 5:04 AM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > >
> > On Tue, Mar 31, 2026 at 01:44:02PM -0600, Keith Busch wrote:
> > > On Tue, Mar 31, 2026 at 10:02:20PM +0300, Leon Romanovsky wrote:
> > > >
> > > > Right, what about adding TPH fields to struct vfio_region_dma_range
> > > > instead of struct vfio_device_feature_dma_buf?
> > >
> > > You might have to show me with code what you're talking about because I
> > > can't see any way we can add fields to any struct here without breaking
> > > backward compatibility.
> > >
> > > If we can't claim bits out of the unused "flags" field for this feature,
> > > then my initial reply is the only sane approach: we can introduce a new
> > > feature and struct for it that closely mirrors the existing one, but
> > > with the extra hint fields.
> >
> > Something like that, on top of this proposal:
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index 3961afa640391..70d5ee1e3ef7b 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -241,9 +241,7 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> > return -EFAULT;
> >
> > if (!get_dma_buf.nr_ranges ||
> > - (get_dma_buf.flags & ~(VFIO_DMABUF_FL_TPH |
> > - VFIO_DMABUF_TPH_PH_MASK |
> > - VFIO_DMABUF_TPH_ST_MASK)))
> > + (get_dma_buf.flags & ~VFIO_DMABUF_FLAG_TPH))
> > return -EINVAL;
> >
> > /*
> > @@ -300,13 +298,10 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> > ret = PTR_ERR(priv->dmabuf);
> > goto err_dev_put;
> > }
> > - if (get_dma_buf.flags & VFIO_DMABUF_FL_TPH) {
> > - priv->steering_tag = (get_dma_buf.flags &
> > - VFIO_DMABUF_TPH_ST_MASK) >>
> > - VFIO_DMABUF_TPH_ST_SHIFT;
> > - priv->ph = (get_dma_buf.flags &
> > - VFIO_DMABUF_TPH_PH_MASK) >>
> > - VFIO_DMABUF_TPH_PH_SHIFT;
> > + if (get_dma_buf.flags & VFIO_DMABUF_FLAG_TPH) {
> > + priv->steering_tag =
> > + dma_ranges[get_dma_buf.nr_ranges + 1].tph.tag;
> > + priv->ph = dma_ranges[get_dma_buf.nr_ranges + 1].tph.ph;
> > }
> > /* dma_buf_put() now frees priv */
> > INIT_LIST_HEAD(&priv->dmabufs_elm);
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index e2a8962641d2c..a8b8d8b1a3278 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -1497,20 +1497,30 @@ struct vfio_device_feature_bus_master {
> > */
> > #define VFIO_DEVICE_FEATURE_DMA_BUF 11
> >
> > +struct vfio_region_dma_tph {
> > + u16 tag;
> > + u8 ph;
> > +};
> > +
> > struct vfio_region_dma_range {
> > - __u64 offset;
> > - __u64 length;
> > + union {
> > + __u64 offset;
> > + struct vfio_region_dma_tph tph;
> > + };
> > + union {
> > + __u64 length;
> > + __u64 reserved;
> > + };
> > +};
> > +
> > +enum {
> > + VFIO_DMABUF_FLAG_TPH = 1 << 0,
> > };
> >
> > struct vfio_device_feature_dma_buf {
> > __u32 region_index;
> > __u32 open_flags;
> > __u32 flags;
> > -#define VFIO_DMABUF_FL_TPH (1U << 0) /* TPH info is present */
> > -#define VFIO_DMABUF_TPH_PH_SHIFT 1 /* bits 1-2: PH (2-bit) */
> > -#define VFIO_DMABUF_TPH_PH_MASK 0x6U
> > -#define VFIO_DMABUF_TPH_ST_SHIFT 16 /* bits 16-31: steering tag */
> > -#define VFIO_DMABUF_TPH_ST_MASK 0xffff0000U
> > __u32 nr_ranges;
> > struct vfio_region_dma_range dma_ranges[] __counted_by(nr_ranges);
> > };
>
> Sounds good, thanks! We will follow up and move this RFC to a formal patch.
Great. Also, please rename "struct vfio_region_dma_range dma_ranges" to
something that makes it clear this is a storage object, not something
limited to a DMA range.
Thanks
>
> Zhiping
>
^ permalink raw reply
* Re: [patch 15/38] ptp: ptp_vmclock: Replace get_cycles() usage
From: Arnd Bergmann @ 2026-04-13 19:30 UTC (permalink / raw)
To: David Woodhouse, Thomas Gleixner, LKML
Cc: x86, Baolu Lu, iommu, Michael Grzeschik, Netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka (SUSE), linux-mm,
Bernie Thompson, linux-fbdev, Theodore Ts'o, linux-ext4,
Andrew Morton, Uladzislau Rezki (Sony), Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A . Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc@vger.kernel.org, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S . Miller,
sparclinux
In-Reply-To: <7a48b636cb3146f4f7134c6d4fe42070ac2edb43.camel@infradead.org>
On Mon, Apr 13, 2026, at 17:33, David Woodhouse wrote:
> On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
>
> ... depend on TSC_RELIABLE¹, since if the guest doesn't believe that it
> is, then the guest shouldn't be trying to use it as the basis for
> precise timing.
>
> ¹ (Or... one of the other zoo of TSC flags for the gradually reducing
> brokenness over the years...)
It looks like this is sufficiently handled in the caller:
static int vmclock_get_crosststamp(struct vmclock_state *st,
struct ptp_system_timestamp *sts,
struct system_counterval_t *system_counter,
struct timespec64 *tspec)
{
....
#ifdef CONFIG_X86
/*
* We'd expect the hypervisor to know this and to report the clock
* status as VMCLOCK_STATUS_UNRELIABLE. But be paranoid.
*/
if (check_tsc_unstable())
return -EINVAL;
#endif
With 486 and ELAN out of the way, Winchip6 seems to be the only
one without X86_FEATURE_TSC, so I think the next logical step would
be to turn off Winchip6 as well and remove all X86_FEATURE_TSC
and CONFIG_X86_TSC checks.
Arnd
^ permalink raw reply
* [ANNOUNCE] iproute2 7.0 release
From: Stephen Hemminger @ 2026-04-13 19:44 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]
This is the regular release of iproute2 corresponding to the 7.0 kernel.
The main addition is `cake_mq` support for tc-cake, enabling CAKE on
multiqueue devices. The `dpll` command gained mode setting and
fractional frequency offset display in parts-per-trillion.
Devlink now supports displaying and resetting parameters to defaults.
The `ss` tool saw several cleanups: trailing whitespace in non-TTY
output, suppressed netlink errors for unsupported protocols, and
proper command name escaping.
The JSON writer gained control characterescaping.
Eric Biggers replaced the AF_ALG SHA-1 in legacy BPF with a
userspace implementation.
Chen Linxuan eliminated redundant mounts in
`ip netns`, and leftover `/usr/lib/route2` references were removed.
Matthieu Baerts added interface name display and colored output to
MPTCP monitor.
A large batch of man page fixes addressed grammar and
style across `dcb`, `devlink`, `netshaper`, `tipc`, `vdpa`, `rdma`,
and `ss`.
Download:
https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-7.0.0.tar.gz
Repository for current release:
https://github.com/shemminger/iproute2.git
git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
And future release (net-next):
git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git
[-- Attachment #2: changes-iproute2-7.0.0.txt --]
[-- Type: text/plain, Size: 2511 bytes --]
Andrea Claudi (1):
dpll: Fix missing notifications in monitor mode
Chen Linxuan (1):
ip/netns: avoid redundant mounts
Daniel Schulte (1):
ss: Remove trailing whitespace when output is not a TTY
Daniel Zahka (2):
devlink: Pull the value printing logic out of pr_out_param_value()
devlink: support displaying and resetting to default params
David Ahern (2):
Update kernel headers
Update kernel headers
Eric Biggers (1):
lib/bpf_legacy: Use userspace SHA-1 code instead of AF_ALG
Ivan Vecera (1):
dpll: add support for fractional frequency offset in ppt
Jonas Köppeler (1):
tc: cake: add cake_mq support
Matthieu Baerts (NGI0) (2):
mptcp: monitor: also show iface name
mptcp: display addr & ifname in color
Petr Oros (2):
dpll: add mode setting support
dpll: fix pin id-get type filter parsing
Sergei Trofimovich (1):
include/json_print.h: add includes for `__u32` and `timeval` declarations
Stephen Hemminger (17):
uapi: update mptcp and rdma headers
utils: do not be restrictive about alternate network device names
dcb: fix grammar and style issues in man pages
devlink: fix grammar and style issues in man pages
fix grammar and style issues in man pages for stat related pages
netshaper: fix grammar and style issues in man page
tipc: fix grammar and style issues in man pages
vdpa: fix grammar, titles, and formatting in man pages
rdma: fix grammar, formatting, and style in man pages
ss: fix grammar, articles, and phrasing in man page
uapi: headers update from 7.0-rc0
ss: suppress netlink errors for unsupported protocols
remove leftover references to /usr/lib/route2
ss: escape characters in command name
json_writer: support control character escaping
json_writer: fix builtin test code
vv7.0.0
Toke Høiland-Jørgensen (1):
man: Add cake_mq documentation to the tc-cake man page
Vincent Mailhol (7):
iplink_can: print_usage: fix the text indentation
iplink_can: print_usage: change unit for minimum time quanta to mtq
iplink_can: print_usage: describe the CAN bittiming units
iplink_can: add RESTRICTED operation mode support
iplink_can: add initial CAN XL support
iplink_can: add CAN XL transceiver mode setting (TMS) support
iplink_can: add CAN XL TMS PWM configuration support
^ permalink raw reply
* [syzbot ci] Re: veth: add Byte Queue Limits (BQL) support
From: syzbot ci @ 2026-04-13 19:49 UTC (permalink / raw)
To: andrew, ast, bpf, corbet, daniel, davem, edumazet, frederic, hawk,
horms, j.koeppeler, jhs, jiri, john.fastabend, kernel-team,
krikku, kuba, kuniyu, linux-doc, linux-kernel, linux-kselftest,
netdev, pabeni, sdf, shuah, skhan, yajun.deng
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260413094442.1376022-1-hawk@kernel.org>
syzbot ci has tested the following series
[v2] veth: add Byte Queue Limits (BQL) support
https://lore.kernel.org/all/20260413094442.1376022-1-hawk@kernel.org
* [PATCH net-next v2 1/5] net: add dev->bql flag to allow BQL sysfs for IFF_NO_QUEUE devices
* [PATCH net-next v2 2/5] veth: implement Byte Queue Limits (BQL) for latency reduction
* [PATCH net-next v2 3/5] veth: add tx_timeout watchdog as BQL safety net
* [PATCH net-next v2 4/5] net: sched: add timeout count to NETDEV WATCHDOG message
* [PATCH net-next v2 5/5] selftests: net: add veth BQL stress test
and found the following issue:
WARNING in veth_napi_del_range
Full report is available here:
https://ci.syzbot.org/series/ee732006-8545-4abd-a105-b4b1592a7baf
***
WARNING in veth_napi_del_range
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: 8806d502e0a7e7d895b74afbd24e8550a65a2b17
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/90743a26-f003-44cf-abcc-5991c47588b2/config
syz repro: https://ci.syzbot.org/findings/d068bfb2-9f8b-466a-95b4-cd7e7b00006c/syz_repro
------------[ cut here ]------------
index >= dev->num_tx_queues
WARNING: ./include/linux/netdevice.h:2672 at netdev_get_tx_queue include/linux/netdevice.h:2672 [inline], CPU#0: syz.1.27/6002
WARNING: ./include/linux/netdevice.h:2672 at veth_napi_del_range+0x3b7/0x4e0 drivers/net/veth.c:1142, CPU#0: syz.1.27/6002
Modules linked in:
CPU: 0 UID: 0 PID: 6002 Comm: syz.1.27 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:netdev_get_tx_queue include/linux/netdevice.h:2672 [inline]
RIP: 0010:veth_napi_del_range+0x3b7/0x4e0 drivers/net/veth.c:1142
Code: 00 e8 ad 96 69 fe 44 39 6c 24 10 74 5e e8 41 61 44 fb 41 ff c5 49 bc 00 00 00 00 00 fc ff df e9 6d ff ff ff e8 2a 61 44 fb 90 <0f> 0b 90 42 80 3c 23 00 75 8e eb 94 48 8b 0c 24 80 e1 07 80 c1 03
RSP: 0018:ffffc90003adf918 EFLAGS: 00010293
RAX: ffffffff86814ec6 RBX: 1ffff110227a6c03 RCX: ffff888103a857c0
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000002
RBP: 1ffff110227a6c9a R08: ffff888113f01ab7 R09: 0000000000000000
R10: ffff888113f01a98 R11: ffffed10227e0357 R12: dffffc0000000000
R13: 0000000000000002 R14: 0000000000000002 R15: ffff888113d36018
FS: 000055555ea16500(0000) GS:ffff88818de4a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007efc287456b8 CR3: 000000010cdd0000 CR4: 00000000000006f0
Call Trace:
<TASK>
veth_napi_del drivers/net/veth.c:1153 [inline]
veth_disable_xdp+0x1b0/0x310 drivers/net/veth.c:1255
veth_xdp_set drivers/net/veth.c:1693 [inline]
veth_xdp+0x48e/0x730 drivers/net/veth.c:1717
dev_xdp_propagate+0x125/0x260 net/core/dev_api.c:348
bond_xdp_set drivers/net/bonding/bond_main.c:5715 [inline]
bond_xdp+0x3ca/0x830 drivers/net/bonding/bond_main.c:5761
dev_xdp_install+0x42c/0x600 net/core/dev.c:10387
dev_xdp_detach_link net/core/dev.c:10579 [inline]
bpf_xdp_link_release+0x362/0x540 net/core/dev.c:10595
bpf_link_free+0x103/0x480 kernel/bpf/syscall.c:3292
bpf_link_put_direct kernel/bpf/syscall.c:3344 [inline]
bpf_link_release+0x6b/0x80 kernel/bpf/syscall.c:3351
__fput+0x44f/0xa70 fs/file_table.c:469
task_work_run+0x1d9/0x270 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0xed/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5bda39c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffdca2969e8 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 00007f5bda617da0 RCX: 00007f5bda39c819
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 00007f5bda617da0 R08: 00007f5bda616128 R09: 0000000000000000
R10: 000000000003fd78 R11: 0000000000000246 R12: 0000000000010fb8
R13: 00007f5bda61609c R14: 0000000000010cdd R15: 00007ffdca296af0
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] ice: fix ICE_AQ_LINK_SPEED_M for 200G
From: Mekala, SunithaX D @ 2026-04-13 19:55 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, Loktionov, Aleksandr
Cc: netdev@vger.kernel.org, Greenwalt, Paul
In-Reply-To: <20260320050537.422528-1-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Aleksandr Loktionov
> Sent: Thursday, March 19, 2026 10:06 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org; Greenwalt, Paul <paul.greenwalt@intel.com>
> Subject: [Intel-wired-lan] [PATCH] ice: fix ICE_AQ_LINK_SPEED_M for 200G
>
> From: Paul Greenwalt <paul.greenwalt@intel.com>
>
> When setting PHY configuration during driver initialization, 200G link
> speed is not being advertised even when the PHY is capable. This is
> because the get PHY capabilities link speed response is being masked by
> ICE_AQ_LINK_SPEED_M, which does not include the 200G link speed bit.
>
> ICE_AQ_LINK_SPEED_200GB is defined as BIT(11), but the mask 0x7FF only
> covers bits 0-10. Fix ICE_AQ_LINK_SPEED_M to use GENMASK(11, 0) so
> that it covers all defined link speed bits including 200G.
>
> Fixes: 24407a01e57c ("ice: Add 200G speed/phy type use")
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-10
From: Luiz Augusto von Dentz @ 2026-04-13 20:07 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, linux-bluetooth, netdev
In-Reply-To: <20260412091614.1786af4e@kernel.org>
Hi Jakub
On Sun, Apr 12, 2026 at 12:16 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 10 Apr 2026 13:22:06 -0400 Luiz Augusto von Dentz wrote:
> > bluetooth-next pull request for net-next:
> >
> > core:
> > - hci_core: Rate limit the logging of invalid ISO handle
> > - hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists
> > - hci_event: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER
> > - hci_event: fix potential UAF in SSP passkey handlers
> > - HCI: Avoid a couple -Wflex-array-member-not-at-end warnings
> > - L2CAP: CoC: Disconnect if received packet size exceeds MPS
> > - L2CAP: Add missing chan lock in l2cap_ecred_reconf_rsp
> > - L2CAP: Fix printing wrong information if SDU length exceeds MTU
> > - SCO: check for codecs->num_codecs == 1 before assigning to sco_pi(sk)->codec
> >
> > drivers:
> > - btusb: MT7922: Add VID/PID 0489/e174
> > - btusb: Add Lite-On 04ca:3807 for MediaTek MT7921
> > - btusb: Add MT7927 IDs ASUS ROG Crosshair X870E Hero, Lenovo Legion Pro 7
> > 16ARX9, Gigabyte Z790 AORUS MASTER X, MSI X870E Ace Max, TP-Link
> > Archer TBE550E, ASUS X870E / ProArt X870E-Creator.
> > - btusb: Add MT7902 IDs 13d3/3579, 13d3/3580, 13d3/3594, 13d3/3596, 0e8d/1ede
> > - btusb: MediaTek MT7922: Add VID 0489 & PID e11d
> > - btintel: Add support for Scorpious Peak2 support
> > - btintel: Add support for Scorpious Peak2F support
> > - btintel_pcie: Add device id of Scorpius Peak2, Nova Lake-PCD-H
> > - btintel_pcie: Add device id of Scorpious2, Nova Lake-PCD-S
> > - btmtk: Add reset mechanism if downloading firmware failed
> > - btmtk: Add MT6639 (MT7927) Bluetooth support
> > - btmtk: fix ISO interface setup for single alt setting
> > - btmtk: add MT7902 SDIO support
> > - Bluetooth: btmtk: add MT7902 MCU support
> > - btbcm: Add entry for BCM4343A2 UART Bluetooth
> > - qca: enable pwrseq support for wcn39xx devices
> > - hci_qca: Fix BT not getting powered-off on rmmod
> > - hci_qca: disable power control for WCN7850 when bt_en is not defined
> > - hci_qca: Fix missing wakeup during SSR memdump handling
> > - hci_ldisc: Clear HCI_UART_PROTO_INIT on error
> > - mmc: sdio: add MediaTek MT7902 SDIO device ID
> > - hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183x
>
> Two fixes tags are messed up here:
>
> Commit: 802446198014 ("Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array")
> Fixes tag: Fixes: 4cdd001ff03f ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support")
> Has these problem(s):
> - Target SHA1 does not exist
>
> Commit: 28c9cc700e30 ("Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU")
> Fixes tag: Fixes: fa768fce4aae ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU")
> Has these problem(s):
> - Target SHA1 does not exist
Would you be able to pull the for-net-next-2026-04-13?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH net-next v2] net: check qdisc_pkt_len_segs_init() return value on ingress
From: Eric Dumazet @ 2026-04-13 20:09 UTC (permalink / raw)
To: David Carlier
Cc: Jakub Kicinski, David S . Miller, Paolo Abeni, Simon Horman,
Stanislav Fomichev, Kuniyuki Iwashima, Samiullah Khawaja,
Hangbin Liu, Krishna Kumar, netdev, linux-kernel
In-Reply-To: <20260413182225.10683-1-devnexen@gmail.com>
On Mon, Apr 13, 2026 at 11:22 AM David Carlier <devnexen@gmail.com> wrote:
>
> Commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> changed qdisc_pkt_len_segs_init() to return an skb drop reason when
> it detects malicious GSO packets. The egress path in __dev_queue_xmit()
> checks this return value and drops bad packets, but the ingress path in
> sch_handle_ingress() ignores it.
>
> This means malformed GSO packets entering via TC ingress are not dropped
> and could be redirected to another interface or cause incorrect qdisc
> accounting.
>
> Check the return value and drop the packet when a bad GSO is detected.
>
> Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
>
> v1 -> v2: reorder variable declarations for reverse xmas tree
> v1: https://lore.kernel.org/netdev/20260408172307.46498-1-devnexen@gmail.com/
> net/core/dev.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
NACK. This is is not needed.
I will not even bother, this is an obvious LLM based patch.
^ permalink raw reply
* Re: [PATCH net-next] mlx4: correct error reporting in mlx4_master_process_vhcr()
From: Tariq Toukan @ 2026-04-13 20:13 UTC (permalink / raw)
To: Alok Tiwari, tariqt, andrew+netdev, kuba, davem, edumazet, pabeni,
horms, netdev
Cc: alok.a.tiwarilinux
In-Reply-To: <20260409092754.508880-1-alok.a.tiwari@oracle.com>
On 09/04/2026 12:27, Alok Tiwari wrote:
> mlx4_master_process_vhcr() logs vhcr->errno on failures, but this field
> is never populated by the PF path. As a result, all failures are reported
> with errno 0 and err print in status case which is misleading.
>
> Use the actual return value (err) instead, translate it to FW status
> before logging, and report both values.
>
> Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
> index de0193d82ec1..bdaf152e6712 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
> @@ -1782,6 +1782,7 @@ static int mlx4_master_process_vhcr(struct mlx4_dev *dev, int slave,
> }
>
> if (err) {
> + vhcr_cmd->status = mlx4_errno_to_status(err);
> if (!(dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)) {
> if (vhcr->op == MLX4_CMD_ALLOC_RES &&
> (vhcr->in_modifier & 0xff) == RES_COUNTER &&
> @@ -1791,9 +1792,8 @@ static int mlx4_master_process_vhcr(struct mlx4_dev *dev, int slave,
> slave, err);
> else
> mlx4_warn(dev, "vhcr command:0x%x slave:%d failed with error:%d, status %d\n",
> - vhcr->op, slave, vhcr->errno, err);
> + vhcr->op, slave, err, vhcr_cmd->status);
> }
> - vhcr_cmd->status = mlx4_errno_to_status(err);
> goto out_status;
> }
>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] net: check qdisc_pkt_len_segs_init() return value on ingress
From: David CARLIER @ 2026-04-13 20:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jakub Kicinski, David S . Miller, Paolo Abeni, Simon Horman,
Stanislav Fomichev, Kuniyuki Iwashima, Samiullah Khawaja,
Hangbin Liu, Krishna Kumar, netdev, linux-kernel
In-Reply-To: <CANn89iLE4k=N62i9hs+GumpP5v7CU7L+Qj644=4Zk74_P0zDxw@mail.gmail.com>
Hi Eric,
You're right on both counts. An LLM was used for the initial
bug-finding /
pre-analysis on this one, and clearly it wasn't deep enough.
Daniel's
question made me go back and trace the redirect paths properly — the
premise was wrong, __dev_queue_xmit() already catches them. I should
have
re-read your 7fb4c1967011 commit message before sending.
Dropping it. Sorry for the noise.
Cheers,
On Mon, 13 Apr 2026 at 21:09, Eric Dumazet <edumazet@google.com> wrote:
>
> On Mon, Apr 13, 2026 at 11:22 AM David Carlier <devnexen@gmail.com> wrote:
> >
> > Commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> > changed qdisc_pkt_len_segs_init() to return an skb drop reason when
> > it detects malicious GSO packets. The egress path in __dev_queue_xmit()
> > checks this return value and drops bad packets, but the ingress path in
> > sch_handle_ingress() ignores it.
> >
> > This means malformed GSO packets entering via TC ingress are not dropped
> > and could be redirected to another interface or cause incorrect qdisc
> > accounting.
> >
> > Check the return value and drop the packet when a bad GSO is detected.
> >
> > Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> > Signed-off-by: David Carlier <devnexen@gmail.com>
> > ---
> >
> > v1 -> v2: reorder variable declarations for reverse xmas tree
> > v1: https://lore.kernel.org/netdev/20260408172307.46498-1-devnexen@gmail.com/
> > net/core/dev.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
>
> NACK. This is is not needed.
>
> I will not even bother, this is an obvious LLM based patch.
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-10
From: Jakub Kicinski @ 2026-04-13 20:44 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, linux-bluetooth, netdev
In-Reply-To: <CABBYNZLg_Dz9ieQ+ioXf2+Oa+vdL8BMbnt=qOfkONOpNsUZ5qw@mail.gmail.com>
On Mon, 13 Apr 2026 16:07:55 -0400 Luiz Augusto von Dentz wrote:
> > Two fixes tags are messed up here:
> >
> > Commit: 802446198014 ("Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array")
> > Fixes tag: Fixes: 4cdd001ff03f ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support")
> > Has these problem(s):
> > - Target SHA1 does not exist
> >
> > Commit: 28c9cc700e30 ("Bluetooth: L2CAP: Fix printing wrong information if SDU length exceeds MTU")
> > Fixes tag: Fixes: fa768fce4aae ("Bluetooth: LE L2CAP: Disconnect if received packet's SDU exceeds IMTU")
> > Has these problem(s):
> > - Target SHA1 does not exist
>
> Would you be able to pull the for-net-next-2026-04-13?
I think so.
^ permalink raw reply
* [PATCH v4 net] net: ax25: fix integer overflow in ax25_rx_fragment()
From: Mashiro Chen @ 2026-04-13 20:49 UTC (permalink / raw)
To: netdev; +Cc: linux-hams, kuba, horms, davem, pabeni, edumazet, Mashiro Chen
In-Reply-To: <20260409025026.24575-1-mashiro.chen@mailbox.org>
ax25_rx_fragment() accumulates fragment lengths into ax25_cb->fraglen,
which is an unsigned short. When the total exceeds 65535, fraglen wraps
around to a small value. The subsequent alloc_skb(fraglen) allocates a
too-small buffer, and skb_put() in the copy loop triggers skb_over_panic().
Add pskb_may_pull(skb, 1) at function entry to ensure the segmentation
header byte is in the linear data area before dereferencing skb->data.
This also rejects zero-length skbs, which the original code did not
check for.
Two issues in the overflow error path are also fixed:
First, the current skb, after skb_pull(skb, 1), is neither enqueued
nor freed before returning 1, leaking it. Add kfree_skb(skb) before
the return.
Second, ax25->fraglen is not reset after skb_queue_purge(). Add
ax25->fraglen = 0 to restore a consistent state.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
---
net/ax25/ax25_in.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/ax25/ax25_in.c b/net/ax25/ax25_in.c
index d75b3e9ed93de8..e1834e11bb0b6a 100644
--- a/net/ax25/ax25_in.c
+++ b/net/ax25/ax25_in.c
@@ -35,12 +35,22 @@ static int ax25_rx_fragment(ax25_cb *ax25, struct sk_buff *skb)
{
struct sk_buff *skbn, *skbo;
+ if (!pskb_may_pull(skb, 1))
+ return 0;
+
if (ax25->fragno != 0) {
if (!(*skb->data & AX25_SEG_FIRST)) {
if ((ax25->fragno - 1) == (*skb->data & AX25_SEG_REM)) {
/* Enqueue fragment */
ax25->fragno = *skb->data & AX25_SEG_REM;
skb_pull(skb, 1); /* skip fragno */
+ if (ax25->fraglen + skb->len > USHRT_MAX) {
+ kfree_skb(skb);
+ skb_queue_purge(&ax25->frag_queue);
+ ax25->fragno = 0;
+ ax25->fraglen = 0;
+ return 1;
+ }
ax25->fraglen += skb->len;
skb_queue_tail(&ax25->frag_queue, skb);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Jakub Kicinski @ 2026-04-13 20:50 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev, Paolo Abeni,
Sam Edwards
In-Reply-To: <ad06yiZZbLC9k3jY@shell.armlinux.org.uk>
On Mon, 13 Apr 2026 19:49:46 +0100 Russell King (Oracle) wrote:
> > Firing interrupts when Rx fill ring runs dry (which IIUC this patches
> > dies?) is not a good idea.
>
> Well, I'm thinking that at least on some platforms, such as the Jetson
> Xavier NX, unless a different solution can be found, we need the RBU
> interrupt to fire off a reset of the stmmac IP when this happens to
> reduce the PAUSE frame flood on the network.
>
> If we can't do that, then I think stmmac on these platforms needs to be
> marked with CONFIG_BROKEN because right now there doesn't seem to be any
> other viable solution.
>
> My intention with this patch is merely to start collecting the already
> existing statistics so other users can start seeing whether they are
> hitting the same or similar problem. If we're not prepared to do that,
> then we should delete the useless statistics from ethtool -S, but I
> suspect they're now part of the UAPI, even though without this patch
> they will remain stedfastly stuck at zero.
Understood, thanks for the extra context. And the statistic we are
talking about is rx_buf_unav_irq ?
^ permalink raw reply
* Re: [PATCH net-next 2/3] rose: clear neighbour pointer after rose_neigh_put() in state machines
From: Jakub Kicinski @ 2026-04-13 20:53 UTC (permalink / raw)
To: f6bvp; +Cc: linux-hams, netdev, edumazet, pabeni
In-Reply-To: <20260413174238.112418-2-bernard.f6bvp@gmail.com>
On Mon, 13 Apr 2026 19:42:37 +0200 f6bvp wrote:
> Signed-off-by: f6bvp <bernard.f6bvp@gmail.com>
Human name is required when authoring patches.
Please do not post patches in reply to existing threads. See:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Russell King (Oracle) @ 2026-04-13 20:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev, Paolo Abeni,
Sam Edwards
In-Reply-To: <20260413135018.59fbd3a1@kernel.org>
On Mon, Apr 13, 2026 at 01:50:18PM -0700, Jakub Kicinski wrote:
> On Mon, 13 Apr 2026 19:49:46 +0100 Russell King (Oracle) wrote:
> > > Firing interrupts when Rx fill ring runs dry (which IIUC this patches
> > > dies?) is not a good idea.
> >
> > Well, I'm thinking that at least on some platforms, such as the Jetson
> > Xavier NX, unless a different solution can be found, we need the RBU
> > interrupt to fire off a reset of the stmmac IP when this happens to
> > reduce the PAUSE frame flood on the network.
> >
> > If we can't do that, then I think stmmac on these platforms needs to be
> > marked with CONFIG_BROKEN because right now there doesn't seem to be any
> > other viable solution.
> >
> > My intention with this patch is merely to start collecting the already
> > existing statistics so other users can start seeing whether they are
> > hitting the same or similar problem. If we're not prepared to do that,
> > then we should delete the useless statistics from ethtool -S, but I
> > suspect they're now part of the UAPI, even though without this patch
> > they will remain stedfastly stuck at zero.
>
> Understood, thanks for the extra context. And the statistic we are
> talking about is rx_buf_unav_irq ?
Yes, correct.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next 1/3] rose: fix race between loopback timer and module removal
From: Andrew Lunn @ 2026-04-13 21:21 UTC (permalink / raw)
To: f6bvp; +Cc: linux-hams, netdev, edumazet, pabeni
In-Reply-To: <20260413174238.112418-1-bernard.f6bvp@gmail.com>
On Mon, Apr 13, 2026 at 07:42:36PM +0200, f6bvp wrote:
> rose_loopback_clear() used timer_delete() which returns immediately
> without waiting for any running callback to complete. If the timer
> fired concurrently with module removal, rose_loopback_timer() would
> access rose_loopback_neigh after it was freed, causing a use-after-free.
>
> Three changes fix the race:
>
> 1. Add a loopback_stopping atomic flag. rose_loopback_timer() checks
> this at entry and mid-loop; when set it drains the queue and bails
> out without re-arming the timer.
>
> 2. Switch rose_loopback_clear() to timer_delete_sync() so it blocks
> until any in-flight callback has returned.
>
> 3. Wrap the timer body with rose_neigh_hold()/rose_neigh_put() so the
> loopback neighbour cannot be freed while the callback is running.
>
> Also fix a pre-existing bug: dev_put(dev) was only called on the
> failure path of rose_rx_call_request(); it is now called unconditionally
> so the device reference is always released.
Hi Barnard
Thanks for the patches.
A few process points.
We prefer lots of small patches, with good commit messages, which are
obviously correct. When i see a list like this, it makes me think the
patch can be split up into smaller patches.
When you have a patch series, please include a patch 0/X which
explains the big picture.
net-next is current closed for the merge window. You can post patches
as RFC, but don't post anything expecting it to be merged.
There is more information here:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
^ permalink raw reply
* Re: [PATCH net-next] mlx4: correct error reporting in mlx4_master_process_vhcr()
From: patchwork-bot+netdevbpf @ 2026-04-13 21:30 UTC (permalink / raw)
To: Alok Tiwari
Cc: tariqt, andrew+netdev, kuba, davem, edumazet, pabeni, horms,
netdev, alok.a.tiwarilinux
In-Reply-To: <20260409092754.508880-1-alok.a.tiwari@oracle.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 02:27:47 -0700 you wrote:
> mlx4_master_process_vhcr() logs vhcr->errno on failures, but this field
> is never populated by the PF path. As a result, all failures are reported
> with errno 0 and err print in status case which is misleading.
>
> Use the actual return value (err) instead, translate it to FW status
> before logging, and report both values.
>
> [...]
Here is the summary with links:
- [net-next] mlx4: correct error reporting in mlx4_master_process_vhcr()
https://git.kernel.org/netdev/net-next/c/bc174d054986
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] bluetooth-next 2026-04-13
From: patchwork-bot+netdevbpf @ 2026-04-13 21:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260413132247.320961-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 13 Apr 2026 09:22:47 -0400 you wrote:
> The following changes since commit 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7:
>
> tools: ynl: tests: fix leading space on Makefile target (2026-04-09 20:41:40 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git tags/for-net-next-2026-04-13
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth-next 2026-04-13
https://git.kernel.org/netdev/net-next/c/e9dc62f25ba6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-net] ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
From: Paul Menzel @ 2026-04-13 21:30 UTC (permalink / raw)
To: Petr Oros
Cc: netdev, Michal Swiatkowski, Paul Greenwalt, Daniel Zahka,
Przemek Kitszel, Nikolay Aleksandrov, Eric Dumazet, linux-kernel,
Aleksandr Loktionov, Andrew Lunn, Tony Nguyen, Dave Ertman,
jacob.e.keller, Jakub Kicinski, Paolo Abeni, David S. Miller,
intel-wired-lan
In-Reply-To: <20260413191420.3524013-1-poros@redhat.com>
Dear Petr,
Thank you very much for your patch.
Am 13.04.26 um 21:14 schrieb Petr Oros:
> On certain E810 configurations where firmware supports Tx scheduler
> topology switching (tx_sched_topo_comp_mode_en), ice_cfg_tx_topo()
> may need to apply a new 5-layer or 9-layer topology from the DDP
> package. If the AQ command to set the topology fails (e.g. due to
> invalid DDP data or firmware limitations), the global configuration
> lock must still be cleared via a CORER reset.
>
> Commit 86aae43f21cf ("ice: don't leave device non-functional if Tx
> scheduler config fails") correctly fixed this by refactoring
> ice_cfg_tx_topo() to always trigger CORER after acquiring the global
> lock and re-initialize hardware via ice_init_hw() afterwards.
>
> However, commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end
> of deinit paths") later moved ice_init_dev_hw() into ice_init_hw(),
> breaking the reinit path introduced by 86aae43f21cf. This creates an
> infinite recursive call chain:
>
> ice_init_hw()
> ice_init_dev_hw()
> ice_cfg_tx_topo() # topology change needed
> ice_deinit_hw()
> ice_init_hw() # reinit after CORER
> ice_init_dev_hw() # recurse
> ice_cfg_tx_topo()
> ... # stack overflow
>
> Fix by moving ice_init_dev_hw() back out of ice_init_hw() and calling
> it explicitly from ice_probe() and ice_devlink_reinit_up(). The third
> caller, ice_cfg_tx_topo(), intentionally does not need ice_init_dev_hw()
> during its reinit, it only needs the core HW reinitialization. This
> breaks the recursion cleanly without adding flags or guards.
>
> The deinit ordering changes from commit 8a37f9e2ff40 ("ice: move
> ice_deinit_dev() to the end of deinit paths") which fixed slow rmmod
> are preserved, only the init-side placement of ice_init_dev_hw() is
> reverted.
>
> Fixes: 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 ++
> drivers/net/ethernet/intel/ice/ice_common.c | 2 --
> drivers/net/ethernet/intel/ice/ice_main.c | 2 ++
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> index 6144cee8034d77..641d6e289d5ce6 100644
> --- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> +++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> @@ -1245,6 +1245,8 @@ static int ice_devlink_reinit_up(struct ice_pf *pf)
> return err;
> }
>
> + ice_init_dev_hw(pf);
> +
> /* load MSI-X values */
> ice_set_min_max_msix(pf);
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> index ce11fea122d03e..b617a6bff89134 100644
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -1126,8 +1126,6 @@ int ice_init_hw(struct ice_hw *hw)
> if (status)
> goto err_unroll_fltr_mgmt_struct;
>
> - ice_init_dev_hw(hw->back);
> -
> mutex_init(&hw->tnl_lock);
> ice_init_chk_recipe_reuse_support(hw);
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index e2a5534819d194..a27be29f9bbbfc 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5314,6 +5314,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> return err;
> }
>
> + ice_init_dev_hw(pf);
> +
> adapter = ice_adapter_get(pdev);
> if (IS_ERR(adapter)) {
> err = PTR_ERR(adapter);
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH net-next 0/3] Follow-ups to nk_qlease net selftests
From: Jakub Kicinski @ 2026-04-13 21:32 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: pabeni, dw, razor, netdev
In-Reply-To: <47b7d67b-2240-4815-87c8-368413c9ddee@iogearbox.net>
On Mon, 13 Apr 2026 15:02:22 +0200 Daniel Borkmann wrote:
> I'm planning to address these in a v2 of the series, but as per netdev rule
> will wait 24h before resend unless you'd like me to explicitly resend earlier
> (given merge win timing).
Please go ahead with v2 as soon as it's ready.
^ 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