* Re: [PATCH net-next 1/4] net: usb: move updating filter and status from cdc to usbnet
From: Manuel Ebner @ 2026-07-02 17:59 UTC (permalink / raw)
To: Oliver Neukum, andrew+netdev, davem, edumazet, kuba, pabeni,
shaoxul, netdev, linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-2-oneukum@suse.com>
Hi,
I have a couple suggestions for you patch. Some parts are
weird to read - it could also be that my perception today is off.
On Thu, 2026-07-02 at 16:25 +0200, Oliver Neukum wrote:
> These helpers are used by multiple drivers and do not depend
"and do not only depend on cdc core. They also depend on
other cdc drivers."
is this better?
> on the rest of cdc. Leavin them in a cdc driver means that
/Leavin/Leaving/
> more drivers are loaded just for infrastructure, not hardware
just for the support of other drivers, not their hardware.
> support.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
> drivers/net/usb/cdc_ether.c | 75 ------------------------------------
> drivers/net/usb/usbnet.c | 76 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 76 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
> index a0a5740590b9..b4df32e18461 100644
> --- a/drivers/net/usb/cdc_ether.c
> +++ b/drivers/net/usb/cdc_ether.c
> @@ -63,35 +63,6 @@ static const u8 mbm_guid[16] = {
> 0xa6, 0x07, 0xc0, 0xff, 0xcb, 0x7e, 0x39, 0x2a,
> };
>
> -void usbnet_cdc_update_filter(struct usbnet *dev)
> -{
> - struct net_device *net = dev->net;
> -
> - u16 cdc_filter = USB_CDC_PACKET_TYPE_DIRECTED
> - | USB_CDC_PACKET_TYPE_BROADCAST;
> -
> - /* filtering on the device is an optional feature and not worth
> - * the hassle so we just roughly care about snooping and if any
> - * multicast is requested, we take every multicast
> - */
> - if (net->flags & IFF_PROMISC)
> - cdc_filter |= USB_CDC_PACKET_TYPE_PROMISCUOUS;
> - if (!netdev_mc_empty(net) || (net->flags & IFF_ALLMULTI))
> - cdc_filter |= USB_CDC_PACKET_TYPE_ALL_MULTICAST;
> -
> - usb_control_msg(dev->udev,
> - usb_sndctrlpipe(dev->udev, 0),
> - USB_CDC_SET_ETHERNET_PACKET_FILTER,
> - USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> - cdc_filter,
> - dev->intf->cur_altsetting->desc.bInterfaceNumber,
> - NULL,
> - 0,
> - USB_CTRL_SET_TIMEOUT
> - );
> -}
> -EXPORT_SYMBOL_GPL(usbnet_cdc_update_filter);
> -
> /* We need to override usbnet_*_link_ksettings in bind() */
> static const struct ethtool_ops cdc_ether_ethtool_ops = {
> .get_link = usbnet_get_link,
> @@ -400,52 +371,6 @@ EXPORT_SYMBOL_GPL(usbnet_cdc_unbind);
> * (by Brad Hards) talked with, with more functionality.
> */
>
> -static void speed_change(struct usbnet *dev, __le32 *speeds)
> -{
> - dev->tx_speed = __le32_to_cpu(speeds[0]);
> - dev->rx_speed = __le32_to_cpu(speeds[1]);
> -}
> -
> -void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
> -{
> - struct usb_cdc_notification *event;
> -
> - if (urb->actual_length < sizeof(*event))
> - return;
> -
> - /* SPEED_CHANGE can get split into two 8-byte packets */
> - if (test_and_clear_bit(EVENT_STS_SPLIT, &dev->flags)) {
> - speed_change(dev, (__le32 *) urb->transfer_buffer);
> - return;
> - }
> -
> - event = urb->transfer_buffer;
> - switch (event->bNotificationType) {
> - case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> - netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
> - event->wValue ? "on" : "off");
> - if (netif_carrier_ok(dev->net) != !!event->wValue)
> - usbnet_link_change(dev, !!event->wValue, 0);
> - break;
> - case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
> - netif_dbg(dev, timer, dev->net, "CDC: speed change (len %d)\n",
> - urb->actual_length);
> - if (urb->actual_length != (sizeof(*event) + 8))
> - set_bit(EVENT_STS_SPLIT, &dev->flags);
> - else
> - speed_change(dev, (__le32 *) &event[1]);
> - break;
> - /* USB_CDC_NOTIFY_RESPONSE_AVAILABLE can happen too (e.g. RNDIS),
> - * but there are no standard formats for the response data.
> - */
> - default:
> - netdev_err(dev->net, "CDC: unexpected notification %02x!\n",
> - event->bNotificationType);
> - break;
> - }
> -}
> -EXPORT_SYMBOL_GPL(usbnet_cdc_status);
> -
> int usbnet_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
> {
> int status;
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 25518635b7b7..5544af1f4aa5 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -22,6 +22,7 @@
> #include <linux/init.h>
> #include <linux/netdevice.h>
> #include <linux/etherdevice.h>
> +#include <linux/usb/cdc.h>
why do you put it there?
it could be alphabetical instead.
> #include <linux/ctype.h>
> #include <linux/ethtool.h>
> #include <linux/workqueue.h>
> @@ -2271,6 +2272,81 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8
> reqtype,
>
> }
> EXPORT_SYMBOL_GPL(usbnet_write_cmd_async);
> +
> +void usbnet_cdc_update_filter(struct usbnet *dev)
> +{
> + struct net_device *net = dev->net;
> +
> + u16 cdc_filter = USB_CDC_PACKET_TYPE_DIRECTED
> + | USB_CDC_PACKET_TYPE_BROADCAST;
> +
Multi-line-comments in coding-style:
/*
* filtering on ..
> + /* filtering on the device is an optional feature and not worth
> + * the hassle so we just roughly care about snooping and if any
> + * multicast is requested, we take every multicast
, we take that multicast.
also that's a pretty long sentence.
> + */
> + if (net->flags & IFF_PROMISC)
> + cdc_filter |= USB_CDC_PACKET_TYPE_PROMISCUOUS;
> + if (!netdev_mc_empty(net) || (net->flags & IFF_ALLMULTI))
> + cdc_filter |= USB_CDC_PACKET_TYPE_ALL_MULTICAST;
> +
> + usb_control_msg(dev->udev,
> + usb_sndctrlpipe(dev->udev, 0),
> + USB_CDC_SET_ETHERNET_PACKET_FILTER,
> + USB_TYPE_CLASS | USB_RECIP_INTERFACE,
> + cdc_filter,
> + dev->intf->cur_altsetting->desc.bInterfaceNumber,
> + NULL,
> + 0,
> + USB_CTRL_SET_TIMEOUT
> + );
> +}
> +EXPORT_SYMBOL_GPL(usbnet_cdc_update_filter);
> +
> +static void speed_change(struct usbnet *dev, __le32 *speeds)
> +{
> + dev->tx_speed = __le32_to_cpu(speeds[0]);
> + dev->rx_speed = __le32_to_cpu(speeds[1]);
> +}
> +
> +void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
> +{
> + struct usb_cdc_notification *event;
> +
> + if (urb->actual_length < sizeof(*event))
> + return;
> +
> + /* SPEED_CHANGE can get split into two 8-byte packets */
> + if (test_and_clear_bit(EVENT_STS_SPLIT, &dev->flags)) {
> + speed_change(dev, (__le32 *)urb->transfer_buffer);
> + return;
> + }
> +
> + event = urb->transfer_buffer;
> + switch (event->bNotificationType) {
> + case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> + netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
> + event->wValue ? "on" : "off");
> + if (netif_carrier_ok(dev->net) != !!event->wValue)
> + usbnet_link_change(dev, !!event->wValue, 0);
> + break;
> + case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
> + netif_dbg(dev, timer, dev->net, "CDC: speed change (len %d)\n",
> + urb->actual_length);
> + if (urb->actual_length != (sizeof(*event) + 8))
> + set_bit(EVENT_STS_SPLIT, &dev->flags);
> + else
> + speed_change(dev, (__le32 *)&event[1]);
> + break;
/*
* USB ..
> + /* USB_CDC_NOTIFY_RESPONSE_AVAILABLE can happen too (e.g. RNDIS),
> + * but there are no standard formats for the response data.
> + */
> + default:
> + netdev_err(dev->net, "CDC: unexpected notification %02x!\n",
> + event->bNotificationType);
> + break;
> + }
> +}
> +EXPORT_SYMBOL_GPL(usbnet_cdc_status);
> /*-------------------------------------------------------------------------*/
>
> static int __init usbnet_init(void)
You can add my
Reviewed-by: Manuel Ebner <manuelebner@mailbox.org>
Thanks
Manuel
^ permalink raw reply
* Re: [PATCH net 1/2] octeon_ep: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:03 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <akUWzu9VjN5WEoJH@boxer>
Thanks Maciej. v2 addresses your comments. The check now runs before the
skb is built in both drivers. I kept octep_oq_drop_rx() as is, since it
derives data_len itself. The octeon_ep_vf dedup is left for net-next.
One more thing. The drop path does not free the dropped packet's pages. It
unmaps them but never calls put_page(). This is not new. The build_skb
failure path leaks the same way. But v2 makes the leak reachable from an
oversized packet. I will send a separate patch for it.
Thanks,
Maoyi
^ permalink raw reply
* Re: [PATCH net] net/tls: Consume empty data records in tls_sw_read_sock()
From: Sabrina Dubroca @ 2026-07-02 18:05 UTC (permalink / raw)
To: Chuck Lever; +Cc: john.fastabend, kuba, davem, edumazet, pabeni, horms, netdev
In-Reply-To: <20260630191551.875664-1-cel@kernel.org>
2026-06-30, 15:15:51 -0400, Chuck Lever wrote:
> A peer may send a zero-length TLS application_data record; TLS 1.3
> explicitly permits these as a traffic-analysis countermeasure (RFC
> 8446, Section 5.1). After decryption such a record has full_len ==
> 0. tls_sw_read_sock() hands it to the read_actor, which has no
> payload to consume and returns zero. The loop treats a zero return
> as backpressure (used <= 0), requeues the skb at the head of
> rx_list, and stops. rx_list is serviced head-first on the next
> call, so the empty record is dequeued, fails the same way, and is
> requeued again; every later record on the connection is blocked
> behind it.
>
> tls_sw_recvmsg() does not stall on this: a zero-length data record
> copies nothing and falls through to consume_skb(). Mirror that in
> the read_sock() path by recognizing an empty data record before
> the actor runs, consuming it, and continuing.
>
> Fixes: 662fbcec32f4 ("net/tls: implement ->read_sock()")
> Signed-off-by: Chuck Lever <cel@kernel.org>
> ---
> net/tls/tls_sw.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
I think tls_sw_splice_read() suffers from a similar issue (returning 0
even though more data may be available). Sashiko agrees, and also
found a few more pre-existing issues.
--
Sabrina
^ permalink raw reply
* [PATCH net v2 0/2] octeon_ep, octeon_ep_vf: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:05 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel
Both octeon_ep and octeon_ep_vf build an skb for a multi-buffer RX packet
by adding one fragment per buffer_size chunk of a device-reported length.
Neither bounds the count against MAX_SKB_FRAGS. A long packet yields about
18 fragments, one past the default MAX_SKB_FRAGS of 17, so
skb_add_rx_frag() writes past shinfo->frags[].
Each driver now checks the fragment count before it builds the skb and
drops a packet that would not fit.
v2:
- move the check before (napi_)build_skb() so the driver does not build an
skb only to free it, per Maciej Fijalkowski.
- the frag count check uses the same u16 length the fragment loop uses.
The repeated linear/non-linear code in octeon_ep_vf that Maciej noted is a
separate cleanup, left for net-next to keep this fix minimal.
v1: https://lore.kernel.org/r/20260701112825.1653044-1-maoyixie.tju@gmail.com
Maoyi Xie (2):
octeon_ep: fix skb frags overflow in the RX path
octeon_ep_vf: fix skb frags overflow in the RX path
.../net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
.../marvell/octeon_ep_vf/octep_vf_rx.c | 20 +++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH net v2 1/2] octeon_ep: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:05 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-1-maoyixie.tju@gmail.com>
__octep_oq_process_rx() builds an skb for a multi-buffer packet by adding
one fragment per buffer_size chunk:
data_len = buff_info->len - oq->max_single_buffer_size;
while (data_len) {
...
skb_add_rx_frag(skb, shinfo->nr_frags, buff_info->page, 0,
buff_info->len, buff_info->len);
...
}
buff_info->len comes from the device response header
(be64_to_cpu(resp_hw->length)). Nothing bounds the fragment count against
MAX_SKB_FRAGS. data_len can be close to 65535. buffer_size defaults to
about 3776 on 4K pages, so a full packet yields about 18 fragments. That
is one more than the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag()
writes past shinfo->frags[].
The fragment count is now checked before build_skb(). A packet that needs
more fragments than the skb can hold is dropped. octep_oq_drop_rx()
consumes its descriptors like the build_skb failure path. The same class
was fixed in other RX paths, including commit 5ffcb7b890f6 ("net: atlantic:
fix fragment overflow handling in RX path") and commit f0813bcd2d9d ("net:
wwan: t7xx: fix potential skb->frags overflow in RX path").
Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
index e6ebc7e44a..bdbed58c7b 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
@@ -453,6 +453,15 @@ static int __octep_oq_process_rx(struct octep_device *oct,
octep_oq_next_pkt(oq, buff_info, &read_idx, &desc_used);
+ if (buff_info->len > oq->max_single_buffer_size) {
+ u16 data_len = buff_info->len - oq->max_single_buffer_size;
+
+ if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
+ octep_oq_drop_rx(oq, buff_info, &read_idx, &desc_used);
+ continue;
+ }
+ }
+
skb = build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
octep_oq_drop_rx(oq, buff_info,
--
2.34.1
^ permalink raw reply related
* [PATCH net v2 2/2] octeon_ep_vf: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-02 18:05 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-1-maoyixie.tju@gmail.com>
__octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF
driver. buff_info->len comes from the device response header, and one
fragment is added per buffer_size chunk with no check against
MAX_SKB_FRAGS. A long packet yields about 18 fragments, one past the
default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past
shinfo->frags[].
The fragment count is now checked before napi_build_skb(). A packet that
needs more fragments than the skb can hold is dropped. Its descriptors are
drained the same way the build_skb failure path does.
Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
.../marvell/octeon_ep_vf/octep_vf_rx.c | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
index d982474082..7af6a80671 100644
--- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
@@ -431,6 +431,26 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
struct skb_shared_info *shinfo;
u16 data_len;
+ data_len = buff_info->len - oq->max_single_buffer_size;
+ if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
+ desc_used++;
+ read_idx = octep_vf_oq_next_idx(oq, read_idx);
+ while (data_len) {
+ dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
+ buff_info = (struct octep_vf_rx_buffer *)
+ &oq->buff_info[read_idx];
+ buff_info->page = NULL;
+ if (data_len < oq->buffer_size)
+ data_len = 0;
+ else
+ data_len -= oq->buffer_size;
+ desc_used++;
+ read_idx = octep_vf_oq_next_idx(oq, read_idx);
+ }
+ continue;
+ }
+
skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
oq->stats->alloc_failures++;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 8/8] clk: sunxi-ng: a733: Add reset lines
From: Enzo Adriano @ 2026-07-02 18:11 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-8-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Same exercise for the reset map: I compared all 121 entries' offsets
and bit positions against the public A733 User Manual V0.92. 115 match
the manual exactly (including the multi-bit GMAC0 entry - 0x141C bits
16/17 per section 4.1.6.212 - and RST_BUS_SYSDAP at 0x7ac, which is
what makes the gate offset in patch 7/8 stand out).
The six that have no register in the public manual, in case you want
to add provenance notes near them (as already discussed for other
undocumented IDs in this series):
- RST_BUS_SPI4 { 0x0F2C, BIT(16) }
- RST_BUS_SGPIO { 0x1064, BIT(16) }
- RST_BUS_LPC { 0x1084, BIT(16) }
- RST_BUS_GMAC1 { 0x142C, BIT(16) } [GMAC1 question]
- RST_BUS_GMAC1_AXI { 0x142C, BIT(17) } [GMAC1 question]
- RST_BUS_TCON_LCD2 { 0x1514, BIT(16) } - the manual documents only
VO0_TCONLCD0_BGR (0x1504) and VO0_TCONLCD1_BGR (0x150C); there is
no TCONLCD2 register set in V0.92
Everything else in the reset map checks out against the manual.
This analysis was done with AI assistance (Claude Code, claude-fable-5)
and each finding was checked against the cited sources.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: usb: move exported code to usbnet
From: Andrew Lunn @ 2026-07-02 18:15 UTC (permalink / raw)
To: Oliver Neukum
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, shaoxul, netdev,
linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-1-oneukum@suse.com>
On Thu, Jul 02, 2026 at 04:25:29PM +0200, Oliver Neukum wrote:
> Some drivers are reusing common code originating in other drivers.
> This means that two drivers need to be loaded for one device.
Maybe consider using 'framework' or 'library', rather than driver,
when referring to the shared code?
I tend to think of a driver as the leaf node which probes based on
enumeration of a bus. But usbnet.c itself is never probed.
Andrew
^ permalink raw reply
* Re: [RFC net-next] bonding: Retry updating slave MAC after a failure
From: Jay Vosburgh @ 2026-07-02 18:17 UTC (permalink / raw)
To: Paritosh Potukuchi; +Cc: netdev, linux-kernel, paritosh.potukuchi
In-Reply-To: <CAMfiSebUf6rbHu4bVL-5vCFRs5cafiEeiNDpX3eQRdxKuRgGeQ@mail.gmail.com>
Paritosh Potukuchi <paritoshpotukuchi@gmail.com> wrote:
>> I think the proper thing to do is remove this comment block and
>make no other changes.
>
> > This comment dates to sometime before git, when it was common
>for network device drivers to lack the ability to change the MAC while
>the interface is up. To the best of my knowledge, that isn't a issue
>today.
>
>Sure Jay. That makes sense. Should I go ahead and post a patch
>removing this comment?
Yes, please do so.
-J
> -Paritosh
>
>On Wed, 1 Jul 2026 at 04:29, Jay Vosburgh <jv@jvosburgh.net> wrote:
>
> Paritosh Potukuchi <paritoshpotukuchi@gmail.com> wrote:
>
> >I came across this TODO in bond_set_mac_address() :
> >
> > /* TODO: consider downing the slave
> > * and retry ?
> > * User should expect communications
> > * breakage anyway until ARP finish
> > * updating, so...
> > */
> >
> >Currently, if the dev_set_mac_address() fails on a slave, we go
> >ahead and unwind the bond and its slaves.
> >
> >As the TODO suggests, one possible solution is to try setting
> >the MAC again, after putting down the interface. This is because some
> >drivers may reject changing the MAC when the device is UP.
> >
> >The solution I am proposing is as follows:
> >
> >dev_set_mac_address on the slave
> > - If this fails, temporarily stop the slave - ndo_stop
> > - If stop fails, unwind
> > - call dev_set_mac_address() on the slave
> > - If this fails, unwind
> > - Bring up the slave by calling ndo_open
> > - If this fails, unwind
> >If dev_set_mac_address on slave passes, we go to the next slave
> >
> >
> >Before working on a patch, I wanted to get feedback on whether
> >this interpretation of the TODO makes sense and whether there
> >are concerns with temporarily stopping and restarting a slave
> >during bond_set_mac_address().
>
> I think the proper thing to do is remove this comment block
> and
> make no other changes.
>
> This comment dates to sometime before git, when it was common
> for network device drivers to lack the ability to change the MAC while
> the interface is up. To the best of my knowledge, that isn't a issue
> today.
>
> -J
>
---
-Jay Vosburgh, jv@jvosburgh.net
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: usb: move updating filter and status from cdc to usbnet
From: Andrew Lunn @ 2026-07-02 18:20 UTC (permalink / raw)
To: Oliver Neukum
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, shaoxul, netdev,
linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-2-oneukum@suse.com>
On Thu, Jul 02, 2026 at 04:25:30PM +0200, Oliver Neukum wrote:
> These helpers are used by multiple drivers and do not depend
> on the rest of cdc. Leavin them in a cdc driver means that
leaving.
> more drivers are loaded just for infrastructure, not hardware
> support.
Can there also be changes to Kconfig removing the dependency on
cdc_ether for some drivers? They now only depend on usbnet?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: usb: move exported code to usbnet
From: Manuel Ebner @ 2026-07-02 18:26 UTC (permalink / raw)
To: Oliver Neukum, andrew+netdev, davem, edumazet, kuba, pabeni,
shaoxul, netdev, linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-1-oneukum@suse.com>
Hallo,
On Thu, 2026-07-02 at 16:25 +0200, Oliver Neukum wrote:
I know this mail doesn't matter much, but i can't leave it as is.
> Some drivers are reusing common code originating in other drivers.
Some drivers are using code from other drivers.
> This means that two drivers need to be loaded for one device.
> Also maintainability is reduced if changes in one driver affect
> another driver.
> Shift common code to usbnet.
You can add my
Reviewed-by: Manuel Ebner <manuelebner@mailbox.org>
to the series.
Thanks
Manuel
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: usb: centralize usbnet_cdc_zte_rx_fixup in usbnet
From: Manuel Ebner @ 2026-07-02 18:19 UTC (permalink / raw)
To: Oliver Neukum, andrew+netdev, davem, edumazet, kuba, pabeni,
shaoxul, netdev, linux-usb, linux-kernel
In-Reply-To: <20260702143142.890654-3-oneukum@suse.com>
On Thu, 2026-07-02 at 16:25 +0200, Oliver Neukum wrote:
> This helper is used by multiple drivers using usbnet.
> It is better to be provided by usbnet than one of them.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
> drivers/net/usb/cdc_ether.c | 19 -------------------
> drivers/net/usb/usbnet.c | 19 +++++++++++++++++++
> 2 files changed, 19 insertions(+), 19 deletions(-)
>
> ...
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 5544af1f4aa5..7beea6d0e731 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -2347,6 +2347,25 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
> }
> }
> EXPORT_SYMBOL_GPL(usbnet_cdc_status);
> +
> +/* Make sure packets have correct destination MAC address
/*
* Make sure packets have the correct destination MAC address
> + *
> + * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
> + * device sends packets with a static, bogus, random MAC address (event if
(even if the device ...
> + * device MAC address has been updated). Always set MAC address to that of the
> + * device.
Always set the MAC address to the one of your device.
Thanks
Manuel
> + * device.
> + */
> +int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
> +{
> + if (skb->len < ETH_HLEN || !(skb->data[0] & 0x02))
> + return 1;
> +
> + skb_reset_mac_header(skb);
> + ether_addr_copy(eth_hdr(skb)->h_dest, dev->net->dev_addr);
> +
> + return 1;
> +}
> +EXPORT_SYMBOL_GPL(usbnet_cdc_zte_rx_fixup);
> /*-------------------------------------------------------------------------*/
>
> static int __init usbnet_init(void)
^ permalink raw reply
* Re: [PATCH net-next 3/9] octeontx2-pf: switch: Add pf files hierarchy
From: Julian Braha @ 2026-07-02 18:55 UTC (permalink / raw)
To: Ratheesh Kannoth, linux-kernel, netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, sgoutham
In-Reply-To: <20260630024715.4124281-4-rkannoth@marvell.com>
Hi Ratheesh,
On 6/30/26 03:47, Ratheesh Kannoth wrote:
> +config OCTEONTX_SWITCH
> + tristate "Marvell OcteonTX2 switch driver"
> + select OCTEONTX2_MBOX
> + select NET_DEVLINK
> + default n
> + select PAGE_POOL
> + depends on (64BIT && COMPILE_TEST) || ARM64
> + depends on OCTEONTX2_PF
Could you keep the 'select's together (move the 'default')?
- Julian Braha
^ permalink raw reply
* [PATCH ipsec] xfrm: policy: use hlist_del_init_rcu in xfrm_hash_rebuild to avoid bydst poison
From: Xiang Mei (Microsoft) @ 2026-07-02 18:58 UTC (permalink / raw)
To: steffen.klassert, herbert, davem, netdev
Cc: horms, fw, edumazet, kuba, pabeni, AutonomousCodeSecurity,
tgopinath, kys, Xiang Mei (Microsoft)
xfrm_hash_rebuild() unlinks each policy from its bydst chain with
hlist_del_rcu() and re-inserts it. For an inexact policy the re-insert goes
through xfrm_policy_inexact_insert(), which can fail on a GFP_ATOMIC
allocation; on failure the error path only WARN_ONCE()s and continues, so the
policy is left with a poisoned bydst node (LIST_POISON2). The next rebuild
calls hlist_del_rcu() on that node again, dereferences the poison, and takes a
general protection fault.
Use hlist_del_init_rcu() instead, so a failed-reinsert node is left unhashed
(pprev == NULL) rather than poisoned. The next rebuild's hlist_del_init_rcu()
is then a no-op for it, and the non-failing case is unchanged.
The reinsert allocation is GFP_ATOMIC (it runs under xfrm_policy_lock), so in
practice this is only reached under memory pressure; the crash below was
reproduced deterministically by forcing that allocation to fail with fault
injection (failslab).
Crash:
Oops: general protection fault, probably for non-canonical address
0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI
KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127]
...
Workqueue: events xfrm_hash_rebuild
RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190
RAX: dead000000000122 (LIST_POISON2 + offset)
...
Call Trace:
hlist_del_rcu (include/linux/rculist.h:599)
xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365)
process_one_work (kernel/workqueue.c:3322)
worker_thread (kernel/workqueue.c:3486)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
...
Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
---
net/xfrm/xfrm_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 7ef861a0e823..2612a405542b 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1362,7 +1362,7 @@ static void xfrm_hash_rebuild(struct work_struct *work)
if (xfrm_policy_is_dead_or_sk(policy))
continue;
- hlist_del_rcu(&policy->bydst);
+ hlist_del_init_rcu(&policy->bydst);
newpos = NULL;
dir = xfrm_policy_id2dir(policy->index);
--
2.43.0
^ permalink raw reply related
* RE: [EXTERNAL] Re: [PATCH net-next v4] net: mana: Add Interrupt Moderation support
From: Haiyang Zhang @ 2026-07-02 19:02 UTC (permalink / raw)
To: Paolo Abeni, Haiyang Zhang, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, KY Srinivasan, Wei Liu, Dexuan Cui,
Long Li, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Konstantin Taranov, Simon Horman,
Erni Sri Satya Vennela, Dipayaan Roy, Aditya Garg, Breno Leitao,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org
Cc: Paul Rosswurm
In-Reply-To: <8906f758-27fe-4ea8-8558-6d15089372d1@redhat.com>
> -----Original Message-----
> From: Paolo Abeni <pabeni@redhat.com>
> Sent: Thursday, July 2, 2026 4:57 AM
> To: Haiyang Zhang <haiyangz@linux.microsoft.com>; linux-
> hyperv@vger.kernel.org; netdev@vger.kernel.org; KY Srinivasan
> <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>; Wei Liu
> <wei.liu@kernel.org>; Dexuan Cui <DECUI@microsoft.com>; Long Li
> <longli@microsoft.com>; Andrew Lunn <andrew+netdev@lunn.ch>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Konstantin Taranov <kotaranov@microsoft.com>;
> Simon Horman <horms@kernel.org>; Erni Sri Satya Vennela
> <ernis@linux.microsoft.com>; Dipayaan Roy
> <dipayanroy@linux.microsoft.com>; Aditya Garg
> <gargaditya@linux.microsoft.com>; Breno Leitao <leitao@debian.org>; linux-
> kernel@vger.kernel.org; linux-rdma@vger.kernel.org
> Cc: Paul Rosswurm <paulros@microsoft.com>
> Subject: [EXTERNAL] Re: [PATCH net-next v4] net: mana: Add Interrupt
> Moderation support
>
> On 6/29/26 11:36 PM, Haiyang Zhang wrote:
> > diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c
> b/drivers/net/ethernet/microsoft/mana/mana_en.c
> > index 7438ea6b3f26..9391e9564605 100644
> > --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> > +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> > @@ -1591,6 +1591,9 @@ int mana_create_wq_obj(struct mana_port_context
> *apc,
> >
> > mana_gd_init_req_hdr(&req.hdr, MANA_CREATE_WQ_OBJ,
> > sizeof(req), sizeof(resp));
> > +
> > + req.hdr.req.msg_version = GDMA_MESSAGE_V3;
> > + req.hdr.resp.msg_version = GDMA_MESSAGE_V2;
>
> Double checking the above is intentional; it feels strange to me that
> request and reply use different versions. Possibly a comment for future
> memory would make sense.
Yes, it's intentional. The request and reply versions can be different.
I will add comments.
> > +
> > +/* The caller must update apc->rx/tx_dim_enabled before disabling and
> > + * after enabling. And synchronize_net() before draining the DIM work,
> > + * so that NAPI cannot observe a stale flag.
> > + */
> > +int mana_dim_change(struct mana_cq *cq, bool enable)
>
> This always return 0, and the return value is not checked by the
> callers; return type should likelly changed to void
Will update.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Mathieu Poirier @ 2026-07-02 19:14 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jenswi, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260702115835.167602-1-sumit.garg@kernel.org>
Hey Sumit - nice hearing from you...
Is there some kind of overarching design harminisation between what
you are proposing here and what Arnaud posted back in April [1] ?
[1]. https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmware.org/thread/VMKTRATYUFWL2TP7NHN5KJ37MSVZZMPK/
On Thu, 2 Jul 2026 at 05:59, Sumit Garg <sumit.garg@kernel.org> wrote:
>
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> The TEE PAS service ABI is designed to be extensible with additional API
> as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
> extensions of the PAS service needed while still maintaining backwards
> compatibility.
>
> Currently OP-TEE support is being added to provide the backend PAS
> service implementation which can be found as part of this PR [1].
> This implementation has been tested on Kodiak/RB3Gen2 and lemans
> EVK boards. In addition to that WIN/IPQ targets tested OP-TEE with
> this service too. Surely the backwards compatibility is maintained and
> tested for SCM backend.
>
> Note that kernel PAS service support while running in EL2 is at parity
> among OP-TEE vs QTEE. Especially the media (venus/iris) support depends
> on proper IOMMU support being worked out on the PAS client end.
>
> Patch summary:
> - Patch #1: adds generic PAS service.
> - Patch #2: migrates SCM backend to generic PAS service.
> - Patch #3: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #4-#12: migrates all client drivers to generic PAS service.
> - Patch #13: drops legacy PAS SCM exported APIs.
>
> The patch-set is based on v7.2-rc1 and can be found in git tree
> here [2].
>
> Merge strategy:
>
> It is expected due to APIs dependency, the entire patch-set to go via
> the Qcom tree. All other subsystem maintainers, it will be great if I
> can get acks for the corresponding subsystem patches.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged)
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v9
>
> ---
> Changes in v9:
> - Rebased to 7.2-rc1.
> - Enable SCM backend similar to TEE if ARCH_QCOM is set.
> - Address misc. comments from Konrad.
> - Add checks for corner cases (although not reachable as per OP-TEE ABI)
> reported by Shashiko on patch #3.
> - Picked up review tags from Konrad.
>
> Changes in v8:
> - Rebased on mainline tip (no functional changes).
> - Now Lemans EVK is also tested to support OP-TEE PAS here:
> https://github.com/OP-TEE/optee_os/pull/7845
> - Drop Kodiak DT patch as it is carried independently by Mukesh here:
> https://lore.kernel.org/lkml/20260624063952.2242702-1-mukesh.ojha@oss.qualcomm.com/
> - Regarding Sashiko comments, I have already replied in v6 the ones that
> don't apply but in v7 I got the same comments again. Specific context
> reasoning which Shashiko ignores:
> - ABI contract between Linux and TZ
> - No support for multiple concurrent backends
> - The TZ backend doesn’t detach during the entire boot cycle
>
> Changes in v7:
> - Rebased to qcom tree (for-next branch) tip.
> - Merged patch #5 and #7 due to build dependency.
> - Disabled modem for kodiak EL2 as it isn't tested yet.
> - Fix an issue found out by sashiko-bot for patch #4.
>
> Changes in v6:
> - Rebased to v7.1-rc4 tag.
> - Patch #14: fixed ret error print.
> - Add Kconfig descriptions for PAS symbols such that they are visible
> in menuconfig to update.
>
> Changes in v5:
> - Incorporated misc. comments from Mukesh.
> - Split up patch #11 into 2 to add an independent commit for passing
> proper PAS ID to set_remote_state API.
> - Picked up tags.
>
> Changes in v4:
> - Incorporate misc. comments on patch #4.
> - Picked up an ack for patch #10.
> - Clarify in cover letter about state of media support.
>
> Changes in v3:
> - Incorporated some style and misc. comments for patch #2, #3 and #4.
> - Add QCOM_PAS Kconfig dependency for various subsystems.
> - Switch from pseudo TA to proper TA invoke commands.
>
> Changes in v2:
> - Fixed kernel doc warnings.
> - Polish commit message and comments for patch #2.
> - Pass proper PAS ID in set_remote_state API for media firmware drivers.
> - Added Maintainer entry and dropped MODULE_AUTHOR.
>
> Sumit Garg (14):
> firmware: qcom: Add a generic PAS service
> firmware: qcom_scm: Migrate to generic PAS service
> firmware: qcom: Add a PAS TEE service
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> remoteproc: qcom: Select QCOM_PAS generic service
> drm/msm: Switch to generic PAS TZ APIs
> media: qcom: Switch to generic PAS TZ APIs
> media: qcom: Pass proper PAS ID to set_remote_state API
> net: ipa: Switch to generic PAS TZ APIs
> wifi: ath12k: Switch to generic PAS TZ APIs
> firmware: qcom_scm: Remove SCM PAS wrappers
> MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
>
> MAINTAINERS | 9 +
> drivers/firmware/qcom/Kconfig | 22 +-
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 299 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++
> drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
> drivers/media/platform/qcom/iris/Kconfig | 27 +-
> .../media/platform/qcom/iris/iris_firmware.c | 9 +-
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 +-
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 +-
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/ahb.c | 10 +-
> drivers/remoteproc/Kconfig | 4 +-
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
> drivers/remoteproc/qcom_wcnss.c | 12 +-
> drivers/soc/qcom/mdt_loader.c | 12 +-
> include/linux/firmware/qcom/qcom_pas.h | 43 ++
> include/linux/firmware/qcom/qcom_scm.h | 29 --
> include/linux/soc/qcom/mdt_loader.h | 6 +-
> 26 files changed, 1095 insertions(+), 321 deletions(-)
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH ipsec] xfrm: policy: use hlist_del_init_rcu in xfrm_hash_rebuild to avoid bydst poison
From: Florian Westphal @ 2026-07-02 19:19 UTC (permalink / raw)
To: Xiang Mei (Microsoft)
Cc: steffen.klassert, herbert, davem, netdev, horms, edumazet, kuba,
pabeni, AutonomousCodeSecurity, tgopinath, kys
In-Reply-To: <20260702185805.615241-1-xmei5@asu.edu>
Xiang Mei (Microsoft) <xmei5@asu.edu> wrote:
> xfrm_hash_rebuild() unlinks each policy from its bydst chain with
> hlist_del_rcu() and re-inserts it. For an inexact policy the re-insert goes
> through xfrm_policy_inexact_insert(), which can fail on a GFP_ATOMIC
> allocation; on failure the error path only WARN_ONCE()s and continues, so the
> policy is left with a poisoned bydst node (LIST_POISON2). The next rebuild
> calls hlist_del_rcu() on that node again, dereferences the poison, and takes a
> general protection fault.
>
> Use hlist_del_init_rcu() instead, so a failed-reinsert node is left unhashed
> (pprev == NULL) rather than poisoned. The next rebuild's hlist_del_init_rcu()
> is then a no-op for it, and the non-failing case is unchanged.
>
> The reinsert allocation is GFP_ATOMIC (it runs under xfrm_policy_lock), so in
> practice this is only reached under memory pressure; the crash below was
> reproduced deterministically by forcing that allocation to fail with fault
> injection (failslab).
>
> Crash:
> Oops: general protection fault, probably for non-canonical address
> 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI
> KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127]
> ...
> Workqueue: events xfrm_hash_rebuild
> RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190
> RAX: dead000000000122 (LIST_POISON2 + offset)
> ...
> Call Trace:
> hlist_del_rcu (include/linux/rculist.h:599)
> xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365)
> process_one_work (kernel/workqueue.c:3322)
> worker_thread (kernel/workqueue.c:3486)
> kthread (kernel/kthread.c:436)
> ret_from_fork (arch/x86/kernel/process.c:158)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
> ...
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype")
> Reported-by: AutonomousCodeSecurity@microsoft.com
> Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
> ---
> net/xfrm/xfrm_policy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 7ef861a0e823..2612a405542b 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -1362,7 +1362,7 @@ static void xfrm_hash_rebuild(struct work_struct *work)
> if (xfrm_policy_is_dead_or_sk(policy))
> continue;
>
> - hlist_del_rcu(&policy->bydst);
> + hlist_del_init_rcu(&policy->bydst);
This patch is dubious. I looks to me as if it papers over the
actual bug.
Why is there a memory allocation error?
The first loop -- before unlink -- is supposed to preallocate the new
bins and chain heads.
This is also why there is a WARN. No memory allocations are supposed to
occur after the hlist_del_rcu(), there is supposed to be a guarantee
that the insertion succeeds.
^ permalink raw reply
* Re: [PATCH net-next v6 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Julian Braha @ 2026-07-02 19:29 UTC (permalink / raw)
To: Selvamani.Rajagopal, Andrew Lunn, Piergiorgio Beruto,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andrew Lunn, Parthiban Veerasooran,
Richard Cochran, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, linux-kernel, devicetree, linux-doc, Jerry Ray
In-Reply-To: <20260629-s2500-mac-phy-support-v6-12-18ce79500371@onsemi.com>
Hi Selvamani,
On 6/29/26 18:23, Selvamani Rajagopal via B4 Relay wrote:
> +if NET_VENDOR_ONSEMI
> +
> +source "drivers/net/ethernet/onsemi/s2500/Kconfig"
> +
> +endif # NET_VENDOR_ONSEMI
> +
> diff --git a/drivers/net/ethernet/onsemi/Makefile b/drivers/net/ethernet/onsemi/Makefile
> new file mode 100644
> index 000000000000..f3d4eb154313
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Makefile for the onsemi network device drivers.
> +#
> +
> +obj-$(CONFIG_S2500_MACPHY) += s2500/
> +
> diff --git a/drivers/net/ethernet/onsemi/s2500/Kconfig b/drivers/net/ethernet/onsemi/s2500/Kconfig
> new file mode 100644
> index 000000000000..f2e8d5d1429d
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi S2500 Driver Support
> +#
> +
> +if NET_VENDOR_ONSEMI
> +
> +config S2500_MACPHY
> + tristate "S2500 support"
> + depends on SPI
> + select NCN26000_PHY
> + select OA_TC6
> + help
> + Support for the onsemi TS2500 MACPHY Ethernet chip.
> + It works under the framework that conform to OPEN Alliance
> + 10BASE-T1x Serial Interface specification.
> +
> + To compile this driver as a module, choose M here. The module will be
> + called s2500.
> +
> +endif # NET_VENDOR_ONSEMI
S2500_MACPHY still has that duplicate dependency from being inside two
of these:
'if NET_VENDOR_ONSEMI..endif'
And I already pointed it out on v5:
https://lore.kernel.org/all/90f84945-e83f-40a8-8d9e-a477c45579e9@gmail.com/
:(
- Julian Braha
^ permalink raw reply
* Re: [PATCH net-next v7 1/2] dinghai: add ZTE network driver support
From: Julian Braha @ 2026-07-02 19:35 UTC (permalink / raw)
To: han.junyang, andrew+netdev, davem, edumazet, kuba, pabeni, horms
Cc: linux-kernel, netdev, ran.ming, han.chengfei, zhang.yanze
In-Reply-To: <20260630111300830lukBczfNSgWE5wt6qR95k@zte.com.cn>
Hi Junyang,
On 6/30/26 04:13, han.junyang@zte.com.cn wrote:
> +if NET_VENDOR_ZTE
> +
> +source "drivers/net/ethernet/zte/dinghai/Kconfig"
> +
> +endif # NET_VENDOR_ZTE
> +++ b/drivers/net/ethernet/zte/dinghai/Kconfig
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# ZTE DingHai Ethernet driver configuration
> +#
> +
> +config DINGHAI
> + bool "ZTE DingHai Ethernet driver"
> + depends on NET_VENDOR_ZTE && PCI
DINGHAI has a duplicate dependency on NET_VENDOR_ZTE since you put the
import for the file inside 'if NET_VENDOR_ZTE..endif' and then also gave
it the 'depends on NET_VENDOR_ZTE'.
- Julian Braha
^ permalink raw reply
* Re: [PATCH net] net/tls: Consume empty data records in tls_sw_read_sock()
From: Chuck Lever @ 2026-07-02 19:52 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: john.fastabend, Jakub Kicinski, davem, edumazet, Paolo Abeni,
Simon Horman, netdev
In-Reply-To: <akaoXcfamBp8_mYe@krikkit>
On Thu, Jul 2, 2026, at 2:05 PM, Sabrina Dubroca wrote:
> 2026-06-30, 15:15:51 -0400, Chuck Lever wrote:
>> A peer may send a zero-length TLS application_data record; TLS 1.3
>> explicitly permits these as a traffic-analysis countermeasure (RFC
>> 8446, Section 5.1). After decryption such a record has full_len ==
>> 0. tls_sw_read_sock() hands it to the read_actor, which has no
>> payload to consume and returns zero. The loop treats a zero return
>> as backpressure (used <= 0), requeues the skb at the head of
>> rx_list, and stops. rx_list is serviced head-first on the next
>> call, so the empty record is dequeued, fails the same way, and is
>> requeued again; every later record on the connection is blocked
>> behind it.
>>
>> tls_sw_recvmsg() does not stall on this: a zero-length data record
>> copies nothing and falls through to consume_skb(). Mirror that in
>> the read_sock() path by recognizing an empty data record before
>> the actor runs, consuming it, and continuing.
>>
>> Fixes: 662fbcec32f4 ("net/tls: implement ->read_sock()")
>> Signed-off-by: Chuck Lever <cel@kernel.org>
>> ---
>> net/tls/tls_sw.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>
> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
>
> I think tls_sw_splice_read() suffers from a similar issue (returning 0
> even though more data may be available). Sashiko agrees, and also
> found a few more pre-existing issues.
Do you want a v2 series with those issues addressed?
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH net 1/2] vsock/virtio: collapse receive queue under memory pressure
From: Bobby Eshleman @ 2026-07-02 20:09 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, Jason Wang, Jakub Kicinski, Paolo Abeni,
Michael S. Tsirkin, kvm, virtualization, Xuan Zhuo, Eric Dumazet,
Simon Horman, linux-kernel, Stefan Hajnoczi, David S. Miller,
Eugenio Pérez, stable, Brien Oberstein
In-Reply-To: <akYl38_9Y4ydXuqE@sgarzare-redhat>
On Thu, Jul 02, 2026 at 10:56:04AM +0200, Stefano Garzarella wrote:
> On Wed, Jul 01, 2026 at 09:34:35AM -0700, Bobby Eshleman wrote:
> > On Fri, Jun 26, 2026 at 03:48:22PM +0200, Stefano Garzarella wrote:
>
> [...]
>
> > > +out:
> > > + if (new_skb)
> > > + __skb_queue_tail(&new_queue, new_skb);
> > > +
> > > + skb_queue_splice(&new_queue, &vvs->rx_queue);
> >
> > I think the new skbs will also need skb_set_owner_sk_safe(skb, sk)
> > when adding to rx_queue?
>
> IIRC we added it in the rx path, mainily for loopback to pass the ownership
> from the tx socket to the rx socket, but here we are already in the rx path,
> so the skb will never leave this socket.
>
Ah that's right, I stand corrected. There is no sender to leak in this
case.
> Maybe it's necessary for the eBPF path?
Looking through sockmap, I don't think it depends on skb->sk being
non-null either (it reassigns owner to the redirect socket anyway using
skb_set_owner_r()).
Sorry for the false alarm. LGTM.
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
^ permalink raw reply
* [PATCH net] af_unix: fix listen() succeeding on sockets in the wrong state
From: John Ericson @ 2026-07-02 20:20 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima
Cc: John Ericson, Simon Horman, Christian Brauner, David Rheinsberg,
Cong Wang, John Ericson, Sergei Zimmerman, netdev, linux-kernel
From: John Ericson <mail@johnericson.me>
Commit fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for
reaped sk->sk_peer_pid") inserted a `prepare_peercred()` call between
`err = -EINVAL` and the socket-state check in `unix_listen()`. Since
`prepare_peercred()` leaves `err` at 0 on success, `listen()` on an
AF_UNIX socket that is not in `TCP_CLOSE` or `TCP_LISTEN` state (e.g.
one that is already connected) now silently returns success without
doing anything, instead of failing with `EINVAL` as it did before.
To fix this bug, and avoid such bugs in the future, switch to a style
where `err = -E...;` instead happens right before the `goto`. (`err =
other_function(...);` is not changed.) Then there is no spooky-action-
at-a-distance between the `err` initialization and the `goto`, something
which is easier to slip by code review.
Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
Assisted-by: Claude:claude-fable-5
Signed-off-by: John Ericson <mail@johnericson.me>
---
net/unix/af_unix.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index f7a9d55eee8a..7878b27bbaf8 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -813,18 +813,22 @@ static int unix_listen(struct socket *sock, int backlog)
struct unix_sock *u = unix_sk(sk);
struct unix_peercred peercred = {};
- err = -EOPNOTSUPP;
- if (sock->type != SOCK_STREAM && sock->type != SOCK_SEQPACKET)
+ if (sock->type != SOCK_STREAM && sock->type != SOCK_SEQPACKET) {
+ err = -EOPNOTSUPP;
goto out; /* Only stream/seqpacket sockets accept */
- err = -EINVAL;
- if (!READ_ONCE(u->addr))
+ }
+ if (!READ_ONCE(u->addr)) {
+ err = -EINVAL;
goto out; /* No listens on an unbound socket */
+ }
err = prepare_peercred(&peercred);
if (err)
goto out;
unix_state_lock(sk);
- if (sk->sk_state != TCP_CLOSE && sk->sk_state != TCP_LISTEN)
+ if (sk->sk_state != TCP_CLOSE && sk->sk_state != TCP_LISTEN) {
+ err = -EINVAL;
goto out_unlock;
+ }
if (backlog > sk->sk_max_ack_backlog)
wake_up_interruptible_all(&u->peer_wait);
sk->sk_max_ack_backlog = backlog;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] net: fman: move IRQ registration after init to prevent NULL deref and UAF
From: Andrew Lunn @ 2026-07-02 20:42 UTC (permalink / raw)
To: ZhaoJinming
Cc: pabeni, andrew+netdev, davem, edumazet, horms, kuba, linux-kernel,
madalin.bucur, netdev, sean.anderson
In-Reply-To: <20260702092815.1206704-2-zhaojinming@uniontech.com>
On Thu, Jul 02, 2026 at 05:28:15PM +0800, ZhaoJinming wrote:
> read_dts_node() registers shared interrupt handlers via
> devm_request_irq() with fman as dev_id. Two bugs exist in the
> current code:
Please start a new thread with a new version of the patch. The CI
system just thinks this is part of the discussion, not something it
must test.
Please also read:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
and set the Subject: line correctly, etc.
Andrew
^ permalink raw reply
* Re: [PATCHv2 net-next] net: dsa: qca8k: fall back to ethernet-ports node name for LEDs
From: Andrew Lunn @ 2026-07-02 20:43 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, open list
In-Reply-To: <20260630015137.1591152-1-rosenp@gmail.com>
On Mon, Jun 29, 2026 at 06:51:37PM -0700, Rosen Penev wrote:
> The device tree binding allows both "ports" and "ethernet-ports" as
> the container node name. Try "ethernet-ports" when "ports" is absent
> so that newer DTBs with the preferred name work.
>
> This matches the handling already present in qca8k-8xxx.c
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next v4 0/2] net: dsa: realtek: rtl8365mb: add SGMII/HSGMII support for RTL8367S
From: Johan Alvarado @ 2026-07-02 20:47 UTC (permalink / raw)
To: linusw, alsi, andrew, olteanv, kuba, davem, edumazet, pabeni,
linux
Cc: luizluca, maxime.chevallier, namiltd, netdev, linux-kernel,
contact
The RTL8367S is a 5+2 port switch from the same family as the
RTL8365MB-VC already supported by this driver. Its chip info table
entry declares SGMII and HSGMII on external interface 1, but the
driver so far only implements RGMII, leaving boards that wire the
switch to the CPU over the SerDes without a working CPU port.
This series implements both modes. The configuration sequence and the
SerDes tuning parameters are derived from the GPL-licensed Realtek
rtl8367c vendor driver, as distributed in the Mercusys MR80X GPL code
drop, and cross-checked against the real register sequence captured at
runtime by chainloading a custom U-Boot ahead of the stock firmware
and logging the live SerDes accesses on hardware.
The vendor driver brings up the SerDes by loading firmware into the
switch's embedded DW8051 microcontroller. Analysis of that firmware
(by Luiz Angelo Daros de Luca) showed it only performs a SerDes
data-path reset right after the SerDes reset is deasserted, and then
runs a link-polling loop that writes the external interface force
registers -- duplicating, and racing with, the link management phylink
already performs. This series therefore keeps the DW8051 disabled and
performs the one necessary action (the data-path reset via the SerDes
BMCR register) directly in the driver, avoiding both the race and a
dependency on a redistributable firmware blob.
The SerDes is modelled as a phylink PCS: mac_select_pcs() hands the
SerDes interfaces to a phylink_pcs whose pcs_config()/pcs_link_up()
ops own the SerDes register sequence, keeping it out of the MAC
operations. In-band autonegotiation is not implemented; the link is
forced (fixed-link or conventional PHY), as for RGMII, and the PCS
reports this to phylink through pcs_inband_caps().
Patch 1 adds the SerDes indirect access helpers, the PCS and SGMII
(1 Gbps) support. Patch 2 extends the PCS to HSGMII (2.5 Gbps), which
phylink represents as 2500base-x.
Tested on a Mercusys MR80X v2.20 (RTL8367S wired to the SoC over the
SerDes), in both SGMII and HSGMII modes with a fixed-link device tree
description: link bring-up verified across cold boots, warm reboots,
module reloads and link down/up cycles, with sustained traffic and no
CRC/symbol errors. The HSGMII link is confirmed running at 2.5G at the
register level (SoC uniphy mode and gmac clocks); per-direction
throughput could not be pushed past ~1 Gbps on this board because the
SoC side is driven by the IPQ5018 SSDK and the user-facing PHY is 1G,
so full 2.5G line-rate throughput remains unverified on my hardware.
The RTL8367SB also declares SGMII and HSGMII in its chip info entry
and therefore gains both modes as well. The vendor driver drives the
two chips through the same code path, keyed only on the chip option
register (both report chip id 0x6367), so this is expected to work
there too, but I have no RTL8367SB hardware to confirm it.
Signed-off-by: Johan Alvarado <contact@c127.dev>
---
v4:
- Drop the chip model name from the driver's NOTE comment; which
interfaces a given chip exposes is described by its chip_info entry,
not the file header. Pointed out by Luiz Angelo Daros de Luca.
- Build the SerDes BMCR data-path-reset values from the standard
BMCR_ANENABLE | BMCR_ISOLATE bits instead of a bare magic number, so
the meaning is in the code rather than only in a comment. Pointed
out by Luiz Angelo Daros de Luca.
- Use a temporary for the DIGITAL_INTERFACE_SELECT value instead of
wrapping the expression across the regmap_update_bits() arguments.
Pointed out by Luiz Angelo Daros de Luca.
- Reject the untested SerDes tuning variant. The vendor driver keeps
two sets of SerDes tuning parameters and selects between them based
on the chip option register (0x13C1); the tables in this series are
the variant for a non-zero option, which is what the RTL8367S parts
seen so far report. The option is probed once at setup and the
SerDes interface modes are only advertised to phylink when the
tuning parameters match, so an unsupported variant fails at phylink
validation time instead of when configuring the link. Thanks to
Luiz Angelo Daros de Luca for pointing out the conditional.
- Express the external interface line rate bypass bit through a
parametric macro keyed on the port number (with port 5 as the base),
instead of an open-coded BIT(interface id) that only matched by
coincidence; other RTL8367 families index this register differently.
Suggested by Luiz Angelo Daros de Luca.
- Drop the arbitrary usleep_range() after each SerDes indirect access.
SerDes writes are now fire-and-forget and reads poll the self-clearing
BUSY bit with regmap_read_poll_timeout(), matching the vendor driver,
which never sleeps. On the MR80X the BUSY bit is never even observed
set: the access completes within the register transaction. Pointed out
by Luiz Angelo Daros de Luca; poll approach suggested by Mieczyslaw
Nalewaj.
- Drop the always-zero SerDes index argument from the SerDes indirect
access helpers, along with the INDACS command index field whose
width was questioned during review; this chip has a single SerDes
block reachable through this window, so the index served no purpose.
Raised by Luiz Angelo Daros de Luca.
- Stop hardcoding external interface 1 with an early -EOPNOTSUPP in
the SerDes configuration path. The SerDes interface modes are now
advertised in phylink_get_caps() from the chip_info
supported_interfaces, and mac_select_pcs() returns the PCS only for
those modes. Pointed out by Luiz Angelo Daros de Luca.
- Keep the new register definitions as raw hex masks, matching the
prevailing style of the file. A file-wide GENMASK/BIT conversion,
raised by Luiz Angelo Daros de Luca during review, is left for a
separate cleanup patch so this series stays focused on the feature.
- Convert the SerDes path to a phylink_pcs, as suggested by Maxime
Chevallier. The SGMII/HSGMII SerDes handling now lives in
pcs_config()/pcs_get_state()/pcs_link_up() selected via
mac_select_pcs(), instead of being driven from the MAC
mac_config()/mac_link_up()/mac_link_down() operations. This
separates the MAC and SerDes layers and makes future in-band
autonegotiation an additive change. No functional change intended
for the forced-link path; retested on the MR80X v2.20. In-band
autonegotiation remains unimplemented and is left for a follow-up,
once hardware is available to validate it.
- Implement pcs_inband_caps(), returning LINK_INBAND_DISABLE so that
phylink knows this PCS cannot do in-band autonegotiation and never
selects an in-band-enabled negotiation mode for it. pcs_config()
rejects PHYLINK_PCS_NEG_INBAND_ENABLED with -EOPNOTSUPP instead of
the previous warn-and-force.
- Program the SerDes pause controls in SDS_MISC from the resolved
pause modes when forcing the MAC external interface, as the vendor
driver does, instead of leaving whatever state the boot firmware
left there. Done in mac_link_up() because pcs_link_up() carries no
pause information.
- Set the PCS poll flag: the SerDes has no link interrupt wired up,
so phylink must poll pcs_get_state() when it tracks the link
through the PCS (in-band mode with autonegotiation disabled).
- Report link down from pcs_get_state() if reading back the forced
speed/duplex fails, rather than reporting link up with a stale
state.
- Reword the misleading "disable in-band aneg" comment.
v3: https://lore.kernel.org/netdev/20260613232136.24246-1-contact@c127.dev/
- Drop the DW8051 firmware loading entirely. Analysis of the vendor
firmware showed it only duplicates the link management phylink
already does; the one needed action (SerDes data-path reset via
the BMCR register) is now performed directly in the driver, with
the DW8051 kept disabled. This removes the dependency on the
rtl8367s-sgmii.bin firmware blob, which could not be redistributed
via linux-firmware (the GPL vendor source ships it as a byte array
without the corresponding microcode source). Thanks to Luiz Angelo
Daros de Luca for the firmware analysis.
v2: https://lore.kernel.org/netdev/0100019eb0b1822e-ffc5626c-1b9f-4c8a-8a1a-759a9e665f4f-000000@email.amazonses.com/
- No code changes; resend because the SMTP provider used for v1
corrupted the mails and patch 1/2 never reached the list.
v1: https://lore.kernel.org/netdev/aebccaad-eca3-4ea4-99dd-ae7edbc8981b@smtp-relay.sendinblue.com/
Johan Alvarado (2):
net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
drivers/net/dsa/realtek/rtl8365mb_main.c | 563 ++++++++++++++++++++++-
1 file changed, 558 insertions(+), 5 deletions(-)
base-commit: d6e81529749190123aa0040626c7e5dbc20fdc9a
--
2.55.0
^ 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