* Re: [PATCH 1/1] xfrm: nat_keepalive: avoid double free on send error
From: Qianyu Luo @ 2026-06-19 9:06 UTC (permalink / raw)
To: Eyal Birger
Cc: Ren Wei, netdev, steffen.klassert, herbert, davem, yuantan098,
bird
In-Reply-To: <CAHsH6Gvsf-JEQyetucAVT6mjaJDi=gMT1pDWFDagb1fhjmveGg@mail.gmail.com>
On Fri, Jun 19, 2026 at 1:21 AM Eyal Birger <eyal.birger@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 9:36 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
> >
> > From: Qianyu Luo <qianyuluo3@gmail.com>
> >
> > nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6
> > send helper reports an error.
> >
> > That cleanup is only correct before the skb is handed to the output
> > path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the
> > networking stack may already have consumed the skb before returning an
> > error, so freeing it again is unsafe.
> >
> > Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4()
> > and nat_keepalive_send_ipv6(), where the caller still owns the skb, and
> > keep nat_keepalive_send() responsible only for family dispatch and the
> > unsupported-family cleanup path.
>
> Thanks for the fix!
>
> >
> > Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states")
> > Cc: stable@vger.kernel.org
> > Reported-by: Yuan Tan <yuantan098@gmail.com>
> > Reported-by: Xin Liu <bird@lzu.edu.cn>
> > Signed-off-by: Qianyu Luo <qianyuluo3@gmail.com>
> > Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> > ---
> > net/xfrm/xfrm_nat_keepalive.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c
> > index 458931062a04..f71328096f11 100644
> > --- a/net/xfrm/xfrm_nat_keepalive.c
> > +++ b/net/xfrm/xfrm_nat_keepalive.c
> > @@ -55,8 +55,10 @@ static int nat_keepalive_send_ipv4(struct sk_buff *skb,
> > ka->encap_sport, sock_net_uid(net, NULL));
> >
> > rt = ip_route_output_key(net, &fl4);
> > - if (IS_ERR(rt))
> > + if (IS_ERR(rt)) {
> > + kfree_skb(skb);
> > return PTR_ERR(rt);
> > + }
> >
> > skb_dst_set(skb, &rt->dst);
> >
> > @@ -100,6 +102,7 @@ static int nat_keepalive_send_ipv6(struct sk_buff *skb,
> > sock_net_set(sk, net);
> > dst = ip6_dst_lookup_flow(net, sk, &fl6, NULL);
> > if (IS_ERR(dst)) {
> > + kfree_skb(skb);
> > local_unlock_nested_bh(&nat_keepalive_sk_ipv6.bh_lock);
>
> Any reason to do the kfree under lock?
>
Thank you for your reply! I did this without particular reason.
Just to keep the pre-handoff cleanup in the same error path.
kfree_skb() does not need the bh lock there, so I can move it after the
unlock in v2 if you need!
> Eyal
^ permalink raw reply
* Re: [PATCH net] net: mana: Sync page pool RX frags for CPU
From: Simon Horman @ 2026-06-19 9:05 UTC (permalink / raw)
To: Dexuan Cui
Cc: kys, haiyangz, wei.liu, longli, andrew+netdev, davem, edumazet,
kuba, pabeni, kotaranov, ernis, dipayanroy, kees, jacob.e.keller,
ssengar, linux-hyperv, netdev, linux-kernel, linux-rdma, stable
In-Reply-To: <20260618035029.249361-1-decui@microsoft.com>
On Wed, Jun 17, 2026 at 08:50:29PM -0700, Dexuan Cui wrote:
> MANA allocates RX buffers from page pool fragments when frag_count is
> greater than 1. In that case the buffers remain DMA mapped by page pool
> and the RX completion path does not call dma_unmap_single(). As a result,
> the implicit sync-for-CPU normally performed by dma_unmap_single() is
> missing before the packet data is passed to the networking stack.
>
> This breaks RX on configurations which require explicit DMA syncing, for
> example when booted with swiotlb=force.
>
> Fix this by recording the page pool page and DMA sync offset when the RX
> buffer is allocated, and syncing the received packet range for CPU access
> before handing the RX buffer to the stack.
>
> Also validate the packet length reported in the RX CQE before using it as
> a DMA sync length or passing it to skb processing. The CQE is supplied
> by the device and should not be blindly trusted by Confidential VMs.
I think this last part warrants being split out into a separate patch.
>
> Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
...
^ permalink raw reply
* [PATCH net] net: wwan: iosm: bound device offsets in the MUX downlink decoder
From: Maoyi Xie @ 2026-06-19 9:03 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, linux-kernel, stable
mux_dl_adb_decode() walks a chain of aggregated datagram tables using
offsets and lengths taken from the modem. first_table_index,
next_table_index, table_length, datagram_index and datagram_length are
all device supplied le values. Only first_table_index was checked, and
only for being non zero. The decoder then formed adth = block +
adth_index and read the table header and the datagram entries with no
bound against the received skb. A modem that reports an index or a
length past the downlink buffer makes the decoder read out of bounds.
The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most
that, so skb->len is the real limit, but none of these in band offsets
were checked against it.
Validate every device offset and length against skb->len before use.
The block header must fit. Each table header, on entry and after every
next_table_index, must lie inside the skb. The datagram table must fit.
Each datagram index and length must stay inside the skb. The header
padding must not exceed the datagram length so the receive length does
not wrap.
This was reproduced under KASAN as a slab out of bounds read on a normal
downlink receive once the iosm net device is up.
Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support")
Cc: stable@vger.kernel.org
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/net/wwan/iosm/iosm_ipc_mux_codec.c | 23 ++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
index bff46f7ca59f..1c021bb0aa7a 100644
--- a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
+++ b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
@@ -557,15 +557,21 @@ static int mux_dl_process_dg(struct iosm_mux *ipc_mux, struct mux_adbh *adbh,
< sizeof(struct mux_adbh))
goto dg_error;
- /* Is the packet inside of the ADB */
+ /* Is the packet inside of the ADB and the received skb ? */
if (le32_to_cpu(dg->datagram_index) >=
- le32_to_cpu(adbh->block_length)) {
+ le32_to_cpu(adbh->block_length) ||
+ le32_to_cpu(dg->datagram_index) >= skb->len ||
+ le16_to_cpu(dg->datagram_length) >
+ skb->len - le32_to_cpu(dg->datagram_index)) {
goto dg_error;
} else {
packet_offset =
le32_to_cpu(dg->datagram_index) +
dl_head_pad_len;
dg_len = le16_to_cpu(dg->datagram_length);
+ /* The header padding must not exceed the datagram. */
+ if (dl_head_pad_len >= dg_len)
+ goto dg_error;
/* Pass the packet to the netif layer. */
rc = ipc_mux_net_receive(ipc_mux, if_id, ipc_mux->wwan,
packet_offset,
@@ -595,6 +601,10 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
block = skb->data;
adbh = (struct mux_adbh *)block;
+ /* The block header itself must fit in the received skb. */
+ if (skb->len < sizeof(struct mux_adbh))
+ goto adb_decode_err;
+
/* Process the aggregated datagram tables. */
adth_index = le32_to_cpu(adbh->first_table_index);
@@ -606,6 +616,11 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
/* Loop through mixed session tables. */
while (adth_index) {
+ /* The table header must lie within the received skb. */
+ if (adth_index < sizeof(struct mux_adbh) ||
+ adth_index > skb->len - sizeof(struct mux_adth))
+ goto adb_decode_err;
+
/* Get the reference to the table header. */
adth = (struct mux_adth *)(block + adth_index);
@@ -629,6 +644,10 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
if (le16_to_cpu(adth->table_length) < sizeof(struct mux_adth))
goto adb_decode_err;
+ /* The whole datagram table must fit in the received skb. */
+ if (le16_to_cpu(adth->table_length) > skb->len - adth_index)
+ goto adb_decode_err;
+
/* Calculate the number of datagrams. */
nr_of_dg = (le16_to_cpu(adth->table_length) -
sizeof(struct mux_adth)) /
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net 1/2] net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap
From: David Laight @ 2026-06-19 9:01 UTC (permalink / raw)
To: Daniel Golle
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <599327521db465a534d277de53ab9b6cac01928b.1781702256.git.daniel@makrotopia.org>
On Fri, 19 Jun 2026 04:39:25 +0100
Daniel Golle <daniel@makrotopia.org> wrote:
> The MXL862XX_API_* macros pass the address of a stack-allocated, __packed
> firmware-ABI struct to mxl862xx_api_wrap() as a void *. The struct has an
> alignment of 1, so the compiler is free to place it at an odd address.
>
> mxl862xx_api_wrap() reinterprets that buffer as a __le16 * and accesses it
> with data[i], for which the compiler assumes the natural 2-byte alignment
> of __le16 and emits aligned 16-bit loads/stores (e.g. lhu/sh on MIPS).
> When the buffer lands on an odd address these fault on architectures that
> do not support unaligned access, such as MIPS32.
Isn't the correct fix to not pack the structure?
(or probably any of the associated structures??)
David
>
> -Waddress-of-packed-member does not catch this: the packed origin is
> laundered through the void * parameter, so the cast inside api_wrap looks
> alignment-safe to the compiler and no warning is emitted.
>
> Use get_unaligned_le16()/put_unaligned_le16() for the three 16-bit word
> accesses. The byte accesses (*(u8 *)&data[i], crc16()) are already safe
> and are left unchanged.
>
> Link: https://sashiko.dev/#/patchset/cover.1781319534.git.daniel%40makrotopia.org?part=4
> Fixes: 23794bec1cb6 ("net: dsa: add basic initial driver for MxL862xx switches")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> drivers/net/dsa/mxl862xx/mxl862xx-host.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/dsa/mxl862xx/mxl862xx-host.c b/drivers/net/dsa/mxl862xx/mxl862xx-host.c
> index d55f9dff6433..882c5d960941 100644
> --- a/drivers/net/dsa/mxl862xx/mxl862xx-host.c
> +++ b/drivers/net/dsa/mxl862xx/mxl862xx-host.c
> @@ -12,6 +12,7 @@
> #include <linux/crc16.h>
> #include <linux/iopoll.h>
> #include <linux/limits.h>
> +#include <linux/unaligned.h>
> #include <net/dsa.h>
> #include "mxl862xx.h"
> #include "mxl862xx-host.h"
> @@ -349,7 +350,7 @@ int mxl862xx_api_wrap(struct mxl862xx_priv *priv, u16 cmd, void *_data,
> * zero words individually.
> */
> for (i = 0, zeros = 0; i < size / 2 && zeros < RST_DATA_THRESHOLD; i++)
> - if (!data[i])
> + if (!get_unaligned_le16(&data[i]))
> zeros++;
>
> if (zeros < RST_DATA_THRESHOLD && (size & 1) && !*(u8 *)&data[i])
> @@ -395,7 +396,7 @@ int mxl862xx_api_wrap(struct mxl862xx_priv *priv, u16 cmd, void *_data,
> */
> val = *(u8 *)&data[i] | ((crc & 0xff) << 8);
> } else {
> - val = le16_to_cpu(data[i]);
> + val = get_unaligned_le16(&data[i]);
> }
>
> /* After RST_DATA, skip zero data words as the registers
> @@ -453,7 +454,7 @@ int mxl862xx_api_wrap(struct mxl862xx_priv *priv, u16 cmd, void *_data,
> *(uint8_t *)&data[i] = ret & 0xff;
> crc = (ret >> 8) & 0xff;
> } else {
> - data[i] = cpu_to_le16((u16)ret);
> + put_unaligned_le16((u16)ret, &data[i]);
> }
> }
>
^ permalink raw reply
* Re: [PATCH] net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit
From: Maxime Chevallier @ 2026-06-19 8:49 UTC (permalink / raw)
To: Jan Klos, Heiner Kallweit, Andrew Lunn, Russell King, netdev; +Cc: linux-kernel
In-Reply-To: <20260619011519.50009-2-honza.klos@gmail.com>
Hi,
On 6/19/26 03:15, Jan Klos wrote:
> On RTL8127A connected to a link partner that advertises 10000baseT
> speed cannot be changed to anything other than 10000baseT as 10GbE
> is always advertised regardless of any setting. Fix this by
> clearing MDIO_AN_10GBT_CTRL_ADV10G bit in rtl822x_config_aneg()'s
> call to phy_modify_mmd_changed().
Makes sense, this is also done as part of the C45 config_aneg sequence.
You're missing a few things process-wise :
- a Fixes tag to indicate the commit that introduced the bug
- You must CC all the relevant maintainers, including the top-level networking
maintainers, use ./scripts/get_maintainers.pl to get the list
- The patch must have in the subject an indication that this targets the
'net' tree, for bugfixes, see :
https://docs.kernel.org/process/maintainer-netdev.html
Feel free to re-send a V2 (after waiting 24h), and add my review tag :
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
>
> Signed-off-by: Jan Klos <honza.klos@gmail.com>
> ---
> drivers/net/phy/realtek/realtek_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index 27268811f564..b65d0f5fa1a0 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -1802,7 +1802,8 @@ static int rtl822x_config_aneg(struct phy_device *phydev)
> ret = phy_modify_mmd_changed(phydev, MDIO_MMD_VEND2,
> RTL_MDIO_AN_10GBT_CTRL,
> MDIO_AN_10GBT_CTRL_ADV2_5G |
> - MDIO_AN_10GBT_CTRL_ADV5G, adv);
> + MDIO_AN_10GBT_CTRL_ADV5G |
> + MDIO_AN_10GBT_CTRL_ADV10G, adv);
> if (ret < 0)
> return ret;
> }
>
> base-commit: 7d8297e26b4e20b5d1c3c3fe51fe81a1c7fbc823
^ permalink raw reply
* Re: [net PATCH v3] octeontx2-af: Validate NIX maximum LFs correctly
From: Simon Horman @ 2026-06-19 8:46 UTC (permalink / raw)
To: Subbaraya Sundeep
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, sgoutham, gakula,
bbhushan2, rkannoth, netdev, linux-kernel
In-Reply-To: <1781710853-23420-1-git-send-email-sbhatta@marvell.com>
On Wed, Jun 17, 2026 at 09:10:53PM +0530, Subbaraya Sundeep wrote:
> NIX maximum number of LFs can be set via devlink command
> but that can be done before assigning any LFs to a PF/VF.
> The condition used to check whether any LFs are assigned is
> incorrect. This patch fixes that condition.
>
> Fixes: dd7842878633 ("octeontx2-af: Add new devlink param to configure maximum usable NIX block LFs")
> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> ---
> v3 changes:
> None, updated changelog
> v2 changes:
> Fixed AI review by updating error message
> Updated comment to mention modifying NIXLFs has to be done prior
> to attaching NIXLFs to any PFs/VFs.
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: AW: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
From: Nicolai Buchwitz @ 2026-06-19 8:30 UTC (permalink / raw)
To: Sven Schuchmann
Cc: Thangaraj Samynathan, Rengarajan Sundararajan, UNGLinuxDriver,
Woojung.Huh, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-usb, linux-kernel
In-Reply-To: <BEZP281MB2245740AE8E3221DD076CE7DD9E22@BEZP281MB2245.DEUP281.PROD.OUTLOOK.COM>
Hi Sven
On 19.6.2026 10:11, Sven Schuchmann wrote:
> Hello Nicolai,
> thank you for the quick response and the quick patch!
>
> But actually it is not working for me... If I disconnect and connect
> the LAN Cable (I have setup an automated test already with two adapters
> connected to my RaspberryPi CM5) the lan78xx_reset() function is not
> called.
>
> Here is a dmesg output from my test.
> I defined DEBUG at the beginning of the driver and added
> netdev_info(dev->net, "function()"); to nearly every function
> in the driver. Also I added my a VLAN compare function:
>
> static void lan78xx_check_vlan_table(struct net_device *netdev)
> {
> struct lan78xx_net *dev = netdev_priv(netdev);
> struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
>
> for (int i = 0; i < 1; i++) {
> u32 buf;
> lan78xx_dataport_read(dev, DP_SEL_RSEL_VLAN_DA_, i, 1, &buf);
> if (pdata->vlan_table[i] != buf)
> netdev_err(dev->net, "VLAN TABLE %d: 0x%02x 0x%02x - ERROR", i,
> pdata->vlan_table[i], buf);
> else
> netdev_info(dev->net, "VLAN TABLE %d: 0x%02x 0x%02x - Ok", i,
> pdata->vlan_table[i], buf);
> }
> }
>
> I call this at the end of lan78xx_start_rx_path() and
> lan78xx_mac_link_up().
> I now I get this output. The output ends after 16 disconnects and
> connects.
> Then it is broken. What I am wondering is what is happening after
> lan78xx_start_rx_path() that destroys the table...
> [...]
Can you please try with the following changes to lan78xx_mac_reset()?
ret = lan78xx_stop_rx_path(dev);
if (ret < 0)
goto link_down_fail;
- /* MAC reset seems to not affect MAC configuration, no idea if it is
- * really needed, but it was done in previous driver version. So,
leave
- * it here.
- */
- ret = lan78xx_mac_reset(dev);
- if (ret < 0)
- goto link_down_fail;
-
return;
BR
Nicolai
self NACK (or whatever it takes to withdraw this patch for now)
^ permalink raw reply
* AW: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
From: Sven Schuchmann @ 2026-06-19 8:11 UTC (permalink / raw)
To: Nicolai Buchwitz, Thangaraj Samynathan, Rengarajan Sundararajan,
UNGLinuxDriver@microchip.com, Woojung.Huh@microchip.com
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260618191109.4086598-1-nb@tipi-net.de>
Hello Nicolai,
thank you for the quick response and the quick patch!
But actually it is not working for me... If I disconnect and connect
the LAN Cable (I have setup an automated test already with two adapters
connected to my RaspberryPi CM5) the lan78xx_reset() function is not called.
Here is a dmesg output from my test.
I defined DEBUG at the beginning of the driver and added
netdev_info(dev->net, "function()"); to nearly every function
in the driver. Also I added my a VLAN compare function:
static void lan78xx_check_vlan_table(struct net_device *netdev)
{
struct lan78xx_net *dev = netdev_priv(netdev);
struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
for (int i = 0; i < 1; i++) {
u32 buf;
lan78xx_dataport_read(dev, DP_SEL_RSEL_VLAN_DA_, i, 1, &buf);
if (pdata->vlan_table[i] != buf)
netdev_err(dev->net, "VLAN TABLE %d: 0x%02x 0x%02x - ERROR", i, pdata->vlan_table[i], buf);
else
netdev_info(dev->net, "VLAN TABLE %d: 0x%02x 0x%02x - Ok", i, pdata->vlan_table[i], buf);
}
}
I call this at the end of lan78xx_start_rx_path() and lan78xx_mac_link_up().
I now I get this output. The output ends after 16 disconnects and connects.
Then it is broken. What I am wondering is what is happening after
lan78xx_start_rx_path() that destroys the table...
[Fri Jun 19 09:40:25 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:40:27 2026] Connect LAN Cable
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:40:27 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:40:29 2026] Disconnect LAN Cable
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:40:29 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:40:31 2026] Connect LAN Cable
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x00 - ERROR
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x00 - ERROR
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:40:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_terminate_urbs()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: configuring for phy/rgmii-id link mode
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_config()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:01 2026] 8021q: adding VLAN 0 to HW filter on device 100BASE-T1-1
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x01 0x01 - Ok
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x01 0x01 - Ok
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:01 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_terminate_urbs()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: configuring for phy/rgmii-id link mode
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_config()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:02 2026] 8021q: adding VLAN 0 to HW filter on device 100BASE-T1-2
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x01 0x01 - Ok
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x01 0x01 - Ok
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:02 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_terminate_urbs()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: configuring for phy/rgmii-id link mode
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_config()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] 8021q: adding VLAN 0 to HW filter on device 100BASE-T1-1
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_terminate_urbs()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: configuring for phy/rgmii-id link mode
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_config()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] 8021q: adding VLAN 0 to HW filter on device 100BASE-T1-2
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] Connect LAN Cable
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_write_vlan_table()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: receive multicast hash filter
[Fri Jun 19 09:43:03 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: receive multicast hash filter
[Fri Jun 19 09:43:04 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: deferred multicast write 0x00007ca2
[Fri Jun 19 09:43:06 2026] Connect LAN Cable
[Fri Jun 19 09:43:08 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:09 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:11 2026] Connect LAN Cable
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:11 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:13 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:14 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:15 2026] Connect LAN Cable
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:15 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:17 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:18 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:19 2026] Connect LAN Cable
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:19 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:20 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:21 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:22 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:24 2026] Connect LAN Cable
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:24 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:26 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:26 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:28 2026] Connect LAN Cable
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:28 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:30 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:31 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:32 2026] Connect LAN Cable
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:32 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:34 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:35 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:36 2026] Connect LAN Cable
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:37 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:38 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:39 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:41 2026] Connect LAN Cable
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:43 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:45 2026] Connect LAN Cable
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:45 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:47 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:48 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:49 2026] Connect LAN Cable
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:49 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:51 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:53 2026] Connect LAN Cable
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:56 2026] Disconnect LAN Cable
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 09:43:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 09:43:58 2026] Connect LAN Cable
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x00 - ERROR
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x00 - ERROR
[Fri Jun 19 09:43:58 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
Regards,
Sven
________________________________________
Von: Nicolai Buchwitz <nb@tipi-net.de>
Gesendet: Donnerstag, 18. Juni 2026 21:11
An: Thangaraj Samynathan <Thangaraj.S@microchip.com>; Rengarajan Sundararajan <Rengarajan.S@microchip.com>; UNGLinuxDriver@microchip.com <UNGLinuxDriver@microchip.com>; Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>; David S . Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Sven Schuchmann <schuchmann@schleissheimer.de>; netdev@vger.kernel.org <netdev@vger.kernel.org>; linux-usb@vger.kernel.org <linux-usb@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; Nicolai Buchwitz <nb@tipi-net.de>
Betreff: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
Configured VLANs stop receiving traffic after a USB autosuspend/resume
cycle, e.g. when a cable is unplugged long enough for the device to
suspend and then plugged back in. VLAN filtering stays enabled but all
VLAN-tagged frames are dropped until a VLAN is added or removed again.
The reset on resume clears the hardware VLAN filter table, but unlike
the multicast and address filters it is never reprogrammed from the
driver's shadow copy, so it stays empty.
Restore the VLAN filter table as part of the reset sequence.
Reported-by: Sven Schuchmann <schuchmann@schleissheimer.de>
Closes: https://lore.kernel.org/netdev/BEZP281MB224501E38B30BFDC4BD3D364D9E32@BEZP281MB2245.DEUP281.PROD.OUTLOOK.COM/T/#u
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
drivers/net/usb/lan78xx.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index bcf293ea1bd3..52c76de64eb9 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -3065,14 +3065,20 @@ static int lan78xx_set_features(struct net_device *netdev,
return lan78xx_write_reg(dev, RFE_CTL, pdata->rfe_ctl);
}
+static int lan78xx_write_vlan_table(struct lan78xx_net *dev)
+{
+ struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
+
+ return lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_, 0,
+ DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
+}
+
static void lan78xx_deferred_vlan_write(struct work_struct *param)
{
struct lan78xx_priv *pdata =
container_of(param, struct lan78xx_priv, set_vlan);
- struct lan78xx_net *dev = pdata->dev;
- lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_, 0,
- DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
+ lan78xx_write_vlan_table(pdata->dev);
}
static int lan78xx_vlan_rx_add_vid(struct net_device *netdev,
@@ -3353,6 +3359,15 @@ static int lan78xx_reset(struct lan78xx_net *dev)
lan78xx_set_multicast(dev->net);
+ /* The chip reset above also clears the VLAN filter table held in the
+ * shared VLAN/DA hash RAM. The network stack does not re-add VLANs
+ * after a silent device reset (e.g. on reset_resume after USB
+ * autosuspend), so restore the table from our shadow copy here.
+ */
+ ret = lan78xx_write_vlan_table(dev);
+ if (ret < 0)
+ return ret;
+
/* reset PHY */
ret = lan78xx_read_reg(dev, PMT_CTL, &buf);
if (ret < 0)
base-commit: 7d8297e26b4e20b5d1c3c3fe51fe81a1c7fbc823
--
2.53.0
^ permalink raw reply related
* Re: [PATCH bpf v3 2/2] selftests/bpf: Cover partial copy of non-linear test_run output
From: Paul Chaignon @ 2026-06-19 8:03 UTC (permalink / raw)
To: sun jian
Cc: bot+bpf-ci, bpf, netdev, linux-kselftest, linux-kernel, ast,
daniel, andrii, martin.lau, eddyz87, memxor, song, yonghong.song,
jolsa, davem, edumazet, kuba, pabeni, horms, shuah, hawk,
john.fastabend, sdf, toke, lorenzo, martin.lau, clm,
ihor.solodrai
In-Reply-To: <CABFUUZHCr=4kb7kSaaPGpc4nkyn32i-svD9v7ONF+TYrrQ-xaQ@mail.gmail.com>
On Thu, Jun 18, 2026 at 06:45:18PM +0800, sun jian wrote:
> On Thu, Jun 18, 2026 at 4:44 PM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> >
> > On Wed, Jun 17, 2026 at 10:19:52PM +0800, sun jian wrote:
> > > On Wed, Jun 17, 2026 at 6:31 PM <bot+bpf-ci@kernel.org> wrote:
[...]
> > > I tried reusing pkt_v4 and the existing TC program, but they do not fit
> > > the skb case this test is trying to cover.
> > >
> > > For skb test_run, IPv4/IPv6 inputs with a too-short L3 header in the
> > > linear area are rejected before bpf_test_finish(). With pkt_v4 and a
> > > linear area of ETH_HLEN, the test fails with -EINVAL before reaching the
> > > partial copy-out path. If the linear area is increased enough to pass the
> > > IPv4 check, pkt_v4 is too small to both trigger the old
> > > copy_size - frag_size path and verify that the copied prefix spans the
> > > linear data and the first fragment. pkt_v6 has the same issue: after
> > > making the IPv6 header linear, only 20 bytes remain in frags.
> > >
> > > The existing test_pkt_access program has its own packet-access coverage
> > > goals and is not just a pass-through carrier. With such a short linear
> > > area or small packet fixture, it can fail before the test hits the
> > > bpf_test_finish()'s partial copy-out path. A pass-through TC program is
> > > therefore a better fit, because it keeps the test focused on the
> > > bpf_test_finish() copy-out semantics.
> >
> > If we're keeping tc_pass_prog() then can't we use pkt_v4 and get rid of
> > init_pkt?
> >
>
> pkt_v4 is too small to construct a meaningful nonlinear skb with a stable
> linear/frag split while still exercising the partial copy-out boundary in
> bpf_test_finish().
>
> With pkt_v4, we either do not reach a fragmented layout, or lose control over
> the linear/frag boundary needed to exercise the regression path.
I think I'm missing something. Why can't we use pkt_v4 with
tc_pass_prog() and a linear area of ETH_HLEN? That would leave 42 bytes
of non-linear area, so a SHORT_OUT_LEN of 30 should work to trigger the
bug, no?
>
> This test uses a 9000B packet so it does not depend on small-packet
> allocation details. Smaller packets might work depending on allocation
> state, but 9000B reliably gives us a non-linear skb with page frags and a
> stable linear/frag boundary for the copy-out regression.
>
> init_pkt() is needed to ensure deterministic byte content across both linear
> and fragmented regions so that the memcmp-based validation is stable.
>
> Thanks,
> Sun Jian
>
>
> > >
> > > For XDP, this object does not have an existing xdp.frags pass-through
> > > program, so the small XDP frags program is needed to cover the other
> > > caller of the shared bpf_test_finish() path.
> > >
> > > Thanks,
> > > Sun Jian
^ permalink raw reply
* [PATCH net v2] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Wayen Yan @ 2026-06-19 7:52 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
- channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
- channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
- channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
- channel 3: clears bit 24..31 (channel 3 only) - correct by accident
While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
mask parameter, the loop still incorrectly clears queues within the
same channel beyond queue 7.
Even though this is functionally harmless (the register resets to 0
and is only ever cleared, never set — so clearing extra bits is a
no-op), the loop bound is semantically wrong and should be fixed for
correctness and clarity.
Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Wayen Yan <win847@gmail.com>
---
Changes in v2:
- Add Lorenzo's Acked-by tag.
- Clarify in commit message that this is semantically wrong but
functionally harmless (register resets to 0, only cleared), as
Lorenzo pointed out in review.
- Rebase on current net tree.
Link: https://lore.kernel.org/netdev/ajJIWMs4dVbfkHZ5@lore-desk/
Link: https://lore.kernel.org/netdev/CAL_ptrs6J3Ryw_4mVTq5VgzkB4RreF5S0huHyLvd9YwWr1m6jAA@mail.gmail.com/
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index d0c0c0ec8a..ca77747b44 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -2212,7 +2212,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
struct airoha_gdm_port *port = netdev_priv(dev);
int i;
- for (i = 0; i < AIROHA_NUM_TX_RING; i++)
+ for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
--
2.51.0
^ permalink raw reply related
* [PATCH net v4] net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()
From: Wayen Yan @ 2026-06-19 7:50 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_dev_select_queue(), the expression:
queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES;
implicitly converts to unsigned arithmetic: when skb->priority is 0
(the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX,
and UINT_MAX % 8 = 7, routing default best-effort packets to the
highest-priority QoS queue. This causes QoS inversion where the
majority of traffic on a PON gateway starves actual high-priority
flows (VoIP, gaming, etc.).
The "- 1" offset was a leftover from the ETS offload implementation
that has since been removed. The correct mapping is a direct modulo:
queue = skb->priority % AIROHA_NUM_QOS_QUEUES;
This maps priority 0 → queue 0 (lowest), priority 7 → queue 7
(highest), with higher priorities wrapping around. This is the
standard Linux sk_prio → HW queue mapping used by other drivers.
Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback")
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Wayen Yan <win847@gmail.com>
---
Changes in v4:
- Remove the "- 1" offset entirely as suggested by Lorenzo and Jakub.
The offset was an ETS offload leftover; the correct mapping is a
direct modulo of skb->priority to AIROHA_NUM_QOS_QUEUES, matching
the standard Linux sk_prio → HW queue convention. (v3 used a
ternary guard which addressed the underflow but kept the unneeded
offset.)
Link: https://lore.kernel.org/netdev/20260617164448.31e189bc@kernel.org/
Link: https://lore.kernel.org/netdev/ajPCgH7E_ke6Fdur@lore-desk/
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index d0c0c0ec8a..9ec3f22754 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1928,7 +1928,7 @@ static u16 airoha_dev_select_queue(struct net_device *dev, struct sk_buff *skb,
*/
channel = netdev_uses_dsa(dev) ? skb_get_queue_mapping(skb) : port->id;
channel = channel % AIROHA_NUM_QOS_CHANNELS;
- queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES; /* QoS queue */
+ queue = skb->priority % AIROHA_NUM_QOS_QUEUES;
queue = channel * AIROHA_NUM_QOS_QUEUES + queue;
return queue < dev->num_tx_queues ? queue : 0;
--
2.51.0
^ permalink raw reply related
* Re: net: wwan: iosm: possible out of bounds read in the MUX downlink decoder
From: Loic Poulain @ 2026-06-19 7:43 UTC (permalink / raw)
To: Maoyi Xie; +Cc: Sergey Ryazanov, Johannes Berg, netdev, linux-kernel
In-Reply-To: <178183832043.3878023.3610072137230679925@maoyixie.com>
Hi Maoyi,
On Fri, Jun 19, 2026 at 5:05 AM Maoyi Xie <maoyixie.tju@gmail.com> wrote:
>
> Hi all,
>
> I think mux_dl_adb_decode() in drivers/net/wwan/iosm/iosm_ipc_mux_codec.c can
> read past the downlink buffer when the modem reports a large table index. I
> would appreciate it if you could take a look.
>
> The decoder takes the table offset straight from the device ADB header.
>
> block = skb->data;
> adbh = (struct mux_adbh *)block;
> adth_index = le32_to_cpu(adbh->first_table_index);
> if (adth_index < 1)
> goto adb_decode_err;
> ...
> adth = (struct mux_adth *)(block + adth_index);
>
> first_table_index is a device le32 and the only check is that it is not
> zero. After that adth points at block + adth_index with no upper bound and
> the code reads adth->table_length and the datagram table from there. The
> downlink buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE, 2048 bytes, so an index
> past 2048 reads past the slab object.
>
> mux_dl_process_dg() has the same issue further down. It reads
> dg->datagram_index and dg->datagram_length per entry, bounded only by the
> device block_length, which is itself never checked against skb->len.
>
> The protocol layer below only caps the total transfer at the pipe buffer
> size and skb_put()s it, so skb->len is at most 2048, but none of these
> in band offsets and lengths are checked against it.
>
> The data here comes from the modem, so it is device input we should not
> trust, especially with an external or compromised PCIe baseband. It fires on
> a normal downlink receive once the iosm net device is up.
>
> I reproduced the adth_index read under KASAN on 7.1-rc7. With an index that
> fits the buffer the read stays inside. With an index past the buffer KASAN
> reports a slab out of bounds read past the downlink buffer.
>
> The fix I have in mind validates every device offset and length against
> skb->len before use, rejecting an adth_index that leaves no room for a
> struct mux_adth and a datagram that runs past the buffer.
>
> Does this look like a real bug to you? The aggregation decoder has moved
> around over the years, so I am not certain of the exact introducing commit.
> 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") is the
> broadly cited landing point. I am happy to send a proper patch.
Yes, please submit a fix. This looks like a typical lack of boundary
checking, we should enforce proper sanitization and avoid blindly
trusting firmware.
>
> Thanks,
> Maoyi
> https://maoyixie.com/
^ permalink raw reply
* Re: [PATCH v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
From: Nicolai Buchwitz @ 2026-06-19 7:39 UTC (permalink / raw)
To: Andrea della Porta
Cc: Théo Lebrun, netdev, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
Lukasz Raczylo, Steffen Jaeckel
In-Reply-To: <ajTtF2xy3WS6NfBi@apocalypse>
On 19.6.2026 09:17, Andrea della Porta wrote:
> [...]
>> Any news from the Raspberry Pi community about this bug investigation?
>
> Not from my side, unfortunately.
If I remember it correctly, the downstream kernel carries earlier
versions of Lukasz patches,
which he also submitted there. If time permits, I will run some tests
with mainline kernel
on Pi5 + downstream kernel with reverted patches + only the upstream
patches.
But realistically this won't happen before end of next week.
BR
Nicolai
> [...]
^ permalink raw reply
* Re: building ynl afaics requires updating the UAPI headers first
From: Thorsten Leemhuis @ 2026-06-19 7:28 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Donald Hunter, netdev, Riana Tauro
In-Reply-To: <20260618170605.0e2e4dd4@kernel.org>
On 6/19/26 02:06, Jakub Kicinski wrote:
> On Thu, 18 Jun 2026 15:39:46 +0200 Thorsten Leemhuis wrote:
>> DRM_RAS_CMD_CLEAR_ERROR_COUNTER was introduced to mainline yesterday as
>> ee18d39a087792 ("drm/drm_ras: Add clear-error-counter netlink command to
>> drm_ras") [v7.1-post].
>>
>> I finally looked closer today and noticed how to prevent this: update
>> the kernel's UAPI files (e.g. the stuff that lives in /usr/include/) on
>> the builder. Thing is: that's basically impossible to do from a srpm, as
>> those should not change the build environment and can't even when
>> working as non-root.
>> [...]
>
> Can't repro for some reason, but we probably need something like
> commit 46e9b0224475abc to add the explicit include rule.
Thx for the pointer. So I guess you mean something like the below,
which did the trick for me. Will submit this as properly, unless
someone points out something stupid in it.
Ciao, Thorsten
diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index cc53b2f21c444..43d06ecbae93d 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -14,10 +14,12 @@ UAPI_PATH:=../../../../include/uapi/
get_hdr_inc=-D$(1) -include $(UAPI_PATH)/linux/$(2)
get_hdr_inc2=-D$(1) -D$(2) -include $(UAPI_PATH)/linux/$(3)
+get_hdr_inc_drm=-D$(1) -include $(UAPI_PATH)/drm/$(2)
CFLAGS_dev-energymodel:=$(call get_hdr_inc,_LINUX_DEV_ENERGYMODEL_H,dev_energymodel.h)
CFLAGS_devlink:=$(call get_hdr_inc,_LINUX_DEVLINK_H_,devlink.h)
CFLAGS_dpll:=$(call get_hdr_inc,_LINUX_DPLL_H,dpll.h)
+CFLAGS_drm_ras:=$(call get_hdr_inc_drm,_LINUX_DRM_RAS_H,drm_ras.h)
CFLAGS_ethtool:=$(call get_hdr_inc,_LINUX_TYPELIMITS_H,typelimits.h) \
$(call get_hdr_inc,_LINUX_ETHTOOL_H,ethtool.h) \
$(call get_hdr_inc,_LINUX_ETHTOOL_NETLINK_H_,ethtool_netlink.h) \
^ permalink raw reply related
* [PATCH v4 net] net: mana: Optimize irq affinity for low vcpu configs
From: Shradha Gupta @ 2026-06-19 7:33 UTC (permalink / raw)
To: Dexuan Cui, Wei Liu, Haiyang Zhang, K. Y. Srinivasan, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Konstantin Taranov, Simon Horman, Erni Sri Satya Vennela,
Dipayaan Roy, Shiraz Saleem, Michael Kelley, Long Li, Yury Norov
Cc: Shradha Gupta, linux-hyperv, linux-kernel, netdev, Paul Rosswurm,
Shradha Gupta, Saurabh Singh Sengar, stable
In mana driver, the number of IRQs allocated is capped by the
min(num_cpu + 1, queue count). In cases, where the IRQ count is greater
than the vcpu count, we want to utilize all the vCPUs, irrespective of
their NUMA/core bindings.
This is important, especially in the envs where number of vCPUs are so
few that the softIRQ handling overhead on two IRQs on the same vCPU is
much more than their overheads if they were spread across sibling vCPUs.
This behaviour is more evident with dynamic IRQ allocation. Since MANA
IRQs are assigned at a later stage compared to static allocation, other
device IRQs may already be affinitized to the vCPUs. As a result, IRQ
weights become imbalanced, causing multiple MANA IRQs to land on the
same vCPU, while some vCPUs have none.
In such cases when many parallel TCP connections are tested, the
throughput drops significantly.
We also studied the results of setting the affinity and hint to
NULL in these cases, and observed that, with this logic if there are
pre existing IRQs allocated on the VM(apart from MANA), during MANA
IRQs allocation, it leads to clustering of the MANA queue IRQs again.
These results can be seen through case 3 in the following data.
Test envs:
=======================================================
Case 1: without this patch
=======================================================
4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
TYPE effective vCPU aff
=======================================================
IRQ0: HWC 0
IRQ1: mana_q1 0
IRQ2: mana_q2 2
IRQ3: mana_q3 0
IRQ4: mana_q4 3
%soft on each vCPU(mpstat -P ALL 1) on receiver
vCPU 0 1 2 3
=======================================================
pass 1: 38.85 0.03 24.89 24.65
pass 2: 39.15 0.03 24.57 25.28
pass 3: 40.36 0.03 23.20 23.17
=======================================================
Case 2: with this patch
=======================================================
4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
TYPE effective vCPU aff
=======================================================
IRQ0: HWC 0
IRQ1: mana_q1 0
IRQ2: mana_q2 1
IRQ3: mana_q3 2
IRQ4: mana_q4 3
%soft on each vCPU(mpstat -P ALL 1) on receiver
vCPU 0 1 2 3
=======================================================
pass 1: 15.42 15.85 14.99 14.51
pass 2: 15.53 15.94 15.81 15.93
pass 3: 16.41 16.35 16.40 16.36
=======================================================
Case 3: with affinity set to NULL
=======================================================
4 vCPU(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
TYPE effective vCPU aff
=======================================================
IRQ0: HWC 0
IRQ1: mana_q1 2
IRQ2: mana_q2 3
IRQ3: mana_q3 2
IRQ4: mana_q4 3
=======================================================
Throughput Impact(in Gbps, same env)
=======================================================
TCP conn with patch w/o patch aff NULL
20480 15.65 7.73 5.25
10240 15.63 8.93 5.77
8192 15.64 9.69 7.16
6144 15.64 13.16 9.33
4096 15.69 15.75 13.50
2048 15.69 15.83 13.61
1024 15.71 15.28 13.60
Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically")
Cc: stable@vger.kernel.org
Co-developed-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
Changes in v4
* Add mana prefix on irq_affinity_*() in mana driver
* Corrected grammar, comment for mana_irq_setup_linear()
* added new line as per guidelines
* added case 3 in commit message for when affinity is NULL
---
Changes in v3
* Optimize the comments in mana_gd_setup_dyn_irqs()
* add more details in the dev_dbg for extra IRQs
---
Changes in v2
* Removed the unused skip_first_cpu variable
* fixed exit condition in irq_setup_linear() with len == 0
* changed return type of irq_setup_linear() as it will always be 0
* removed the unnecessary rcu_read_lock() in irq_setup_linear()
* added appropriate comments to indicate expected behaviour when
IRQs are more than or equal to num_online_cpus()
---
.../net/ethernet/microsoft/mana/gdma_main.c | 78 +++++++++++++++----
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index a0fdd052d7f1..e8b7ffb47eb9 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -210,6 +210,8 @@ static int mana_gd_query_max_resources(struct pci_dev *pdev)
} else {
/* If dynamic allocation is enabled we have already allocated
* hwc msi
+ * Also, we make sure in this case the following is always true
+ * (num_msix_usable - 1 HWC) <= num_online_cpus()
*/
gc->num_msix_usable = min(resp.max_msix, num_online_cpus() + 1);
}
@@ -1909,8 +1911,8 @@ void mana_gd_free_res_map(struct gdma_resource *r)
* do the same thing.
*/
-static int irq_setup(unsigned int *irqs, unsigned int len, int node,
- bool skip_first_cpu)
+static int mana_irq_setup_numa_aware(unsigned int *irqs, unsigned int len,
+ int node, bool skip_first_cpu)
{
const struct cpumask *next, *prev = cpu_none_mask;
cpumask_var_t cpus __free(free_cpumask_var);
@@ -1946,11 +1948,24 @@ static int irq_setup(unsigned int *irqs, unsigned int len, int node,
return 0;
}
+/* must be called with cpus_read_lock() held */
+static void mana_irq_setup_linear(unsigned int *irqs, unsigned int len)
+{
+ int cpu;
+
+ for_each_online_cpu(cpu) {
+ if (len == 0)
+ break;
+
+ irq_set_affinity_and_hint(*irqs++, cpumask_of(cpu));
+ len--;
+ }
+}
+
static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
{
struct gdma_context *gc = pci_get_drvdata(pdev);
struct gdma_irq_context *gic;
- bool skip_first_cpu = false;
int *irqs, err, i, msi;
irqs = kmalloc_objs(int, nvec);
@@ -1958,10 +1973,12 @@ static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
return -ENOMEM;
/*
+ * In this function, num_msix_usable = HWC IRQ + Queue IRQ.
+ * nvec is only Queue IRQ (HWC already setup).
* While processing the next pci irq vector, we start with index 1,
* as IRQ vector at index 0 is already processed for HWC.
* However, the population of irqs array starts with index 0, to be
- * further used in irq_setup()
+ * further used in mana_irq_setup_numa_aware()
*/
for (i = 1; i <= nvec; i++) {
msi = i;
@@ -1975,18 +1992,51 @@ static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
}
/*
- * When calling irq_setup() for dynamically added IRQs, if number of
- * CPUs is more than or equal to allocated MSI-X, we need to skip the
- * first CPU sibling group since they are already affinitized to HWC IRQ
+ * When calling mana_irq_setup_numa_aware() for dynamically added IRQs,
+ * if number of CPUs is more than or equal to allocated MSI-X, we need to
+ * skip the first CPU sibling group since they are already affinitized to
+ * HWC IRQ
*/
cpus_read_lock();
- if (gc->num_msix_usable <= num_online_cpus())
- skip_first_cpu = true;
+ if (gc->num_msix_usable <= num_online_cpus()) {
+ err = mana_irq_setup_numa_aware(irqs, nvec, gc->numa_node,
+ true);
+ if (err) {
+ cpus_read_unlock();
+ goto free_irq;
+ }
+ } else {
+ /*
+ * When num_msix_usable are more than num_online_cpus, our
+ * queue IRQs should be equal to num of online vCPUs.
+ * We try to make sure queue IRQs spread across all vCPUs.
+ * In such a case NUMA or CPU core affinity does not matter.
+ * Note: in this case the total mana IRQ should always be
+ * num_online_cpus + 1. The first HWC IRQ is already handled
+ * in HWC setup calls
+ * However, if CPUs went offline since num_msix_usable was
+ * computed, queue IRQs will be more than num_online_cpus().
+ * In such cases remaining extra IRQs will retain their default
+ * affinity.
+ */
+ int first_unassigned = num_online_cpus();
- err = irq_setup(irqs, nvec, gc->numa_node, skip_first_cpu);
- if (err) {
- cpus_read_unlock();
- goto free_irq;
+ if (nvec > first_unassigned) {
+ char buf[32];
+
+ if (first_unassigned == nvec - 1)
+ snprintf(buf, sizeof(buf), "%d",
+ first_unassigned);
+ else
+ snprintf(buf, sizeof(buf), "%d-%d",
+ first_unassigned, nvec - 1);
+
+ dev_dbg(&pdev->dev,
+ "MANA IRQ indices #%s will retain the default CPU affinity\n",
+ buf);
+ }
+
+ mana_irq_setup_linear(irqs, nvec);
}
cpus_read_unlock();
@@ -2041,7 +2091,7 @@ static int mana_gd_setup_irqs(struct pci_dev *pdev, int nvec)
nvec -= 1;
}
- err = irq_setup(irqs, nvec, gc->numa_node, false);
+ err = mana_irq_setup_numa_aware(irqs, nvec, gc->numa_node, false);
if (err) {
cpus_read_unlock();
goto free_irq;
base-commit: 96e7f9122aae0ed000ee321f324b812a447906d9
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] net/sched: dualpi2: fix GSO backlog accounting
From: Xingquan Liu @ 2026-06-19 7:31 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, Jiri Pirko, Victor Nogueira, Chia-Yu Chang, Xingquan Liu,
stable
When DualPI2 splits a GSO skb into N segments, it propagates N
additional packets to its parent before returning NET_XMIT_SUCCESS.
The parent then accounts for the original skb once more, leaving its
qlen one larger than the number of packets actually queued.
With QFQ as the parent, after all real packets are dequeued, QFQ still
has a non-zero qlen while its in-service aggregate has no active
classes. qfq_choose_next_agg() returns NULL and qfq_dequeue() passes
the result to qfq_peek_skb(), causing a NULL pointer dereference.
Follow the same pattern used by tbf_segment() and taprio: count only
successfully queued segments, propagate the difference between the
original skb and those segments, and return NET_XMIT_SUCCESS whenever
at least one segment was queued.
Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc")
Cc: stable@vger.kernel.org
Signed-off-by: Xingquan Liu <b1n@b1n.io>
---
v2:
- Change patch commit message.
- Add tdc test.
net/sched/sch_dualpi2.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c
index d7c3254ef800..5434df6ca8ef 100644
--- a/net/sched/sch_dualpi2.c
+++ b/net/sched/sch_dualpi2.c
@@ -461,7 +461,7 @@ static int dualpi2_qdisc_enqueue(struct sk_buff *skb, struct Qdisc *sch,
if (IS_ERR_OR_NULL(nskb))
return qdisc_drop(skb, sch, to_free);
- cnt = 1;
+ cnt = 0;
byte_len = 0;
orig_len = qdisc_pkt_len(skb);
skb_list_walk_safe(nskb, nskb, next) {
@@ -488,16 +488,15 @@ static int dualpi2_qdisc_enqueue(struct sk_buff *skb, struct Qdisc *sch,
byte_len += nskb->len;
}
}
- if (cnt > 1) {
+ if (cnt > 0) {
/* The caller will add the original skb stats to its
* backlog, compensate this if any nskb is enqueued.
*/
- --cnt;
- byte_len -= orig_len;
+ qdisc_tree_reduce_backlog(sch, 1 - cnt,
+ orig_len - byte_len);
}
- qdisc_tree_reduce_backlog(sch, -cnt, -byte_len);
consume_skb(skb);
- return err;
+ return cnt > 0 ? NET_XMIT_SUCCESS : err;
}
return dualpi2_enqueue_skb(skb, sch, to_free);
}
base-commit: 96e7f9122aae0ed000ee321f324b812a447906d9
--
Xingquan Liu
^ permalink raw reply related
* [PATCH v2 2/2] selftests/tc-testing: Add DualPI2 GSO backlog accounting test
From: Xingquan Liu @ 2026-06-19 7:31 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, Jiri Pirko, Victor Nogueira, Chia-Yu Chang, Xingquan Liu
In-Reply-To: <20260619073211.637928-1-b1n@b1n.io>
Add a regression test for DualPI2 GSO backlog accounting when it is
used as a child qdisc of QFQ.
The test sends one UDP GSO datagram through a QFQ class with DualPI2 as
the leaf qdisc. DualPI2 splits the skb into two segments. After the
traffic drains, both QFQ and DualPI2 must report zero backlog and zero
qlen.
On kernels with the broken accounting, QFQ can keep a stale non-zero
qlen after all real packets have been dequeued.
Signed-off-by: Xingquan Liu <b1n@b1n.io>
---
.../tc-testing/tc-tests/qdiscs/dualpi2.json | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/qdiscs/dualpi2.json b/tools/testing/selftests/tc-testing/tc-tests/qdiscs/dualpi2.json
index cd1f2ee8f354..ffd6fd5ba8f7 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/qdiscs/dualpi2.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/qdiscs/dualpi2.json
@@ -250,5 +250,49 @@
"teardown": [
"$TC qdisc del dev $DUMMY handle 1: root"
]
+ },
+ {
+ "id": "891f",
+ "name": "Verify DualPI2 GSO backlog accounting with QFQ parent",
+ "category": [
+ "qdisc",
+ "dualpi2",
+ "qfq",
+ "gso"
+ ],
+ "plugins": {
+ "requires": "nsPlugin"
+ },
+ "setup": [
+ "$IP link set dev $DUMMY up || true",
+ "$IP addr add 10.10.10.10/24 dev $DUMMY || true",
+ "$TC qdisc add dev $DUMMY root handle 1: qfq",
+ "$TC class add dev $DUMMY parent 1: classid 1:1 qfq weight 1 maxpkt 4096",
+ "$TC qdisc add dev $DUMMY parent 1:1 handle 2: dualpi2",
+ "$TC filter add dev $DUMMY parent 1: matchall classid 1:1"
+ ],
+ "cmdUnderTest": "python3 -c 'import socket,struct; SOL_UDP=getattr(socket,\"SOL_UDP\",socket.IPPROTO_UDP); UDP_SEGMENT=getattr(socket,\"UDP_SEGMENT\",103); s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM); s.bind((\"10.10.10.10\",0)); p=b\"X\"*2400; n=s.sendmsg([p],[(SOL_UDP,UDP_SEGMENT,struct.pack(\"=H\",1200))],0,(\"10.10.10.1\",9000)); raise SystemExit(n != len(p))'",
+ "expExitCode": "0",
+ "verifyCmd": "$TC -j -s qdisc ls dev $DUMMY",
+ "matchJSON": [
+ {
+ "kind": "qfq",
+ "handle": "1:",
+ "packets": 2,
+ "backlog": 0,
+ "qlen": 0
+ },
+ {
+ "kind": "dualpi2",
+ "handle": "2:",
+ "packets": 2,
+ "backlog": 0,
+ "qlen": 0
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $DUMMY root",
+ "$IP addr del 10.10.10.10/24 dev $DUMMY || true"
+ ]
}
]
--
Xingquan Liu
^ permalink raw reply related
* RE: [PATCH net] igb: only strip Rx timestamp header on the first buffer of a frame
From: Tjerk Kusters @ 2026-06-19 7:22 UTC (permalink / raw)
To: Tony Nguyen, Kurt Kanzenbach, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, przemyslaw.kitszel@intel.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, richardcochran@gmail.com,
hawk@kernel.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <55ab9b13-ee51-4ac6-af7b-b3feb159eb51@intel.com>
Hello
> > b4 has a web submission endpoint. Maybe you can use that one:
> It would be great if you could get this setup as it makes patch handling easier.
>
> Sign off should be your full name.
>
> Thanks,
> Tony
I send an updated version via the b4 endpoint
Regards
Tjerk
^ permalink raw reply
* [PATCH net v2] igb: only strip Rx timestamp header on the first buffer of a frame
From: Tjerk Kusters via B4 Relay @ 2026-06-19 7:14 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Jesper Dangaard Brouer, Kurt Kanzenbach
Cc: intel-wired-lan, netdev, linux-kernel, stable, Tjerk Kusters
From: Tjerk Kusters <tkusters@aweta.nl>
When Rx hardware timestamping is enabled (e.g. ptp4l, which configures
HWTSTAMP_FILTER_ALL), the NIC prepends a 16-byte timestamp header to the
first Rx buffer of every received frame. igb_clean_rx_irq() strips this
header inside its per-buffer loop:
if (igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
ts_hdr_len = igb_ptp_rx_pktstamp(rx_ring->q_vector,
pktbuf, ×tamp);
pkt_offset += ts_hdr_len;
size -= ts_hdr_len;
}
For a frame that spans more than one Rx buffer (e.g. a jumbo frame), this
block runs once per buffer. The timestamp header only exists at the start
of the first buffer, but igb_ptp_rx_pktstamp() is called for every buffer.
On a continuation buffer the data is packet payload, not a timestamp
header. igb_ptp_rx_pktstamp() already has two guards against acting on a
non-header buffer: it returns 0 if PTP is disabled, and returns 0 if the
reserved dwords (the first 8 bytes) are non-zero. Neither is sufficient
here: PTP is enabled, and a continuation buffer whose payload happens to
begin with 8 zero bytes passes the reserved-dword check. In that case the
payload is mistaken for a valid timestamp header and igb_ptp_rx_pktstamp()
returns IGB_TS_HDR_LEN, so the caller strips 16 bytes of real data from
that buffer. A frame spanning N buffers whose continuation buffers start
with zero bytes therefore loses 16 * (N - 1) bytes from its tail.
This is easily triggered by a GigE Vision camera streaming dark frames
(mostly 0x00 pixel data) over jumbo UDP with PTP active on the receiver:
the all-zero frames arrive truncated while frames with non-zero content
are fine. There is no error indication.
No content-based check can reliably tell a continuation buffer that begins
with zero bytes from a real timestamp header, because both are all zero.
Fix it structurally instead: only attempt the strip on the first buffer of
a frame, which is the only buffer that can contain a timestamp header. In
igb_clean_rx_irq() skb is NULL until the first buffer has been processed,
so guarding the strip with !skb restricts it to the first buffer
regardless of payload content.
Fixes: 5379260852b0 ("igb: Fix XDP with PTP enabled")
Cc: stable@vger.kernel.org
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Signed-off-by: Tjerk Kusters <tkusters@aweta.nl>
---
Changes in v2:
- resend via b4 (v1 was sent with a mail client)
- use full author name "Tjerk Kusters" (Jacob Keller)
- add Reviewed-by from Kurt Kanzenbach
- no functional change
Link to v1: https://lore.kernel.org/all/PAWPR05MB1069106D52F4E17F1EDB99C67B9182@PAWPR05MB10691.eurprd05.prod.outlook.com/
---
drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index ce91dda00ec0..abb55cd589a9 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -9061,7 +9061,8 @@ static int igb_clean_rx_irq(struct igb_q_vector *q_vector, const int budget)
pktbuf = page_address(rx_buffer->page) + rx_buffer->page_offset;
/* pull rx packet timestamp if available and valid */
- if (igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
+ if (!skb &&
+ igb_test_staterr(rx_desc, E1000_RXDADV_STAT_TSIP)) {
int ts_hdr_len;
ts_hdr_len = igb_ptp_rx_pktstamp(rx_ring->q_vector,
---
base-commit: 2d3090a8aeb596a26935db0955d46c9a5db5c6ce
change-id: 20260619-igb-rx-ts-fix-cd70585ee316
Best regards,
--
Tjerk Kusters <tkusters@aweta.nl>
^ permalink raw reply related
* Re: [PATCH v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
From: Andrea della Porta @ 2026-06-19 7:17 UTC (permalink / raw)
To: Théo Lebrun
Cc: Andrea della Porta, netdev, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
Nicolai Buchwitz, Lukasz Raczylo, Steffen Jaeckel
In-Reply-To: <DJAKGHKZGUI2.29AHYNFX4LGBJ@bootlin.com>
Hi Theo,
On 17:07 Tue 16 Jun , Théo Lebrun wrote:
> Hello Andrea,
>
> On Tue Jun 16, 2026 at 3:23 PM CEST, Andrea della Porta wrote:
> > From: Lukasz Raczylo <lukasz@raczylo.com>
> >
> > The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on
> > the TX queue.
> > While the exact root cause is not yet fully understood, it is likely
> > related to a hardware issue where a TSTART write to the NCR register
> > is missed, preventing the transmission from being kicked off.
> >
> > Implement a timeout callback to handle TX queue stalls, triggering the
> > existing restart mechanism to recover.
> >
> > Link: https://lore.kernel.org/all/20260514215459.36109-1-lukasz@raczylo.com/
> > Fixes: dc110d1b23564 ("net: cadence: macb: Add support for Raspberry Pi RP1 ethernet controller")
> > Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
> > Co-developed-by: Steffen Jaeckel <sjaeckel@suse.de>
> > Signed-off-by: Steffen Jaeckel <sjaeckel@suse.de>
> > Co-developed-by: Andrea della Porta <andrea.porta@suse.com>
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
>
> Thanks for this V2.
>
> Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
>
> Any news from the Raspberry Pi community about this bug investigation?
Not from my side, unfortunately.
Regards,
Andrea
>
> Thanks,
>
> --
> Théo Lebrun, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
^ permalink raw reply
* [PATCH net 01/15] batman-adv: gw: don't deselect gateway with active hardif
From: Simon Wunderlich @ 2026-06-19 7:00 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, b.a.t.m.a.n, Sven Eckelmann, stable, Nora Schiffer,
Simon Wunderlich
In-Reply-To: <20260619070045.438101-1-sw@simonwunderlich.de>
From: Sven Eckelmann <sven@narfation.org>
The batadv_hardif_cnt() was previously checking if there is an
batadv_hard_iface->mesh_iface which is has the same mesh_iface. And since
batadv_hardif_disable_interface() was resetting the
batadv_hard_iface->mesh_iface after this check, it had to verify whether
*1* interface was still part of the mesh_iface before it started the
gateway deselection.
But after batadv_hardif_cnt() is now checking the lower interfaces of
mesh_iface and batadv_hardif_disable_interface() already removed the
interface via netdev_upper_dev_unlink() earlier in this function, the check
must now make sure that *0* interfaces can be found by batadv_hardif_cnt()
before selected gateway must be deselected. Otherwise the deselection would
already happen one batadv_hard_iface too early.
Because a 0 hardif count from batadv_hardif_cnt() is equal to an empty
list, it is possible to replace the counting with a simple list_empty().
Cc: stable@kernel.org
Fixes: 7dc284702bcd ("batman-adv: store hard_iface as iflink private data")
Reviewed-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/hard-interface.c | 28 ++--------------------------
1 file changed, 2 insertions(+), 26 deletions(-)
diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index 60cee2c2f2f41..03d01c20a9548 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -814,30 +814,6 @@ int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
return ret;
}
-/**
- * batadv_hardif_cnt() - get number of interfaces enslaved to mesh interface
- * @mesh_iface: mesh interface to check
- *
- * This function is only using RCU for locking - the result can therefore be
- * off when another function is modifying the list at the same time. The
- * caller can use the rtnl_lock to make sure that the count is accurate.
- *
- * Return: number of connected/enslaved hard interfaces
- */
-static size_t batadv_hardif_cnt(struct net_device *mesh_iface)
-{
- struct batadv_hard_iface *hard_iface;
- struct list_head *iter;
- size_t count = 0;
-
- rcu_read_lock();
- netdev_for_each_lower_private_rcu(mesh_iface, hard_iface, iter)
- count++;
- rcu_read_unlock();
-
- return count;
-}
-
/**
* batadv_hardif_disable_interface() - Remove hard interface from mesh interface
* @hard_iface: hard interface to be removed
@@ -878,8 +854,8 @@ void batadv_hardif_disable_interface(struct batadv_hard_iface *hard_iface)
netdev_upper_dev_unlink(hard_iface->net_dev, hard_iface->mesh_iface);
batadv_hardif_recalc_extra_skbroom(hard_iface->mesh_iface);
- /* nobody uses this interface anymore */
- if (batadv_hardif_cnt(hard_iface->mesh_iface) <= 1)
+ /* nobody uses this mesh interface anymore */
+ if (list_empty(&hard_iface->mesh_iface->adj_list.lower))
batadv_gw_check_client_stop(bat_priv);
hard_iface->mesh_iface = NULL;
--
2.47.3
^ permalink raw reply related
* [PATCH net 04/15] batman-adv: frag: ensure fragment is writable before modifying TTL
From: Simon Wunderlich @ 2026-06-19 7:00 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, b.a.t.m.a.n, Sven Eckelmann, stable,
Simon Wunderlich
In-Reply-To: <20260619070045.438101-1-sw@simonwunderlich.de>
From: Sven Eckelmann <sven@narfation.org>
Before batman-adv is allowed to write to an skb, it either has to have its
own copy of the skb or use skb_cow() to ensure that the data part is not
shared. But batadv_frag_skb_fwd() modifies the TTL even when it is shared.
Adding a skb_cow() right before this operation avoids this and can at the
same time prepare it for the modifications required to forward the
fragment.
Cc: stable@kernel.org
Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/fragmentation.c | 15 ++++++++++++++-
net/batman-adv/fragmentation.h | 3 ++-
net/batman-adv/routing.c | 3 +--
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
index 1e42cf99f8b33..f311a42203d2e 100644
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -386,6 +386,8 @@ bool batadv_frag_skb_buffer(struct sk_buff **skb,
* @skb: skb to forward
* @recv_if: interface that the skb is received on
* @orig_node_src: originator that the skb is received from
+ * @rx_result: set to NET_RX_SUCCESS when the fragment was forwarded and
+ * NET_RX_DROP when it was dropped; only valid when true is returned
*
* Look up the next-hop of the fragments payload and check if the merged packet
* will exceed the MTU towards the next-hop. If so, the fragment is forwarded
@@ -395,7 +397,8 @@ bool batadv_frag_skb_buffer(struct sk_buff **skb,
*/
bool batadv_frag_skb_fwd(struct sk_buff *skb,
struct batadv_hard_iface *recv_if,
- struct batadv_orig_node *orig_node_src)
+ struct batadv_orig_node *orig_node_src,
+ int *rx_result)
{
struct batadv_priv *bat_priv = netdev_priv(recv_if->mesh_iface);
struct batadv_neigh_node *neigh_node = NULL;
@@ -414,12 +417,22 @@ bool batadv_frag_skb_fwd(struct sk_buff *skb,
*/
total_size = ntohs(packet->total_size);
if (total_size > neigh_node->if_incoming->net_dev->mtu) {
+ if (skb_cow(skb, ETH_HLEN) < 0) {
+ kfree_skb(skb);
+ *rx_result = NET_RX_DROP;
+ ret = true;
+ goto out;
+ }
+
+ packet = (struct batadv_frag_packet *)skb->data;
+
batadv_inc_counter(bat_priv, BATADV_CNT_FRAG_FWD);
batadv_add_counter(bat_priv, BATADV_CNT_FRAG_FWD_BYTES,
skb->len + ETH_HLEN);
packet->ttl--;
batadv_send_unicast_skb(skb, neigh_node);
+ *rx_result = NET_RX_SUCCESS;
ret = true;
}
diff --git a/net/batman-adv/fragmentation.h b/net/batman-adv/fragmentation.h
index dbf0871f87030..51e281027ab63 100644
--- a/net/batman-adv/fragmentation.h
+++ b/net/batman-adv/fragmentation.h
@@ -19,7 +19,8 @@ void batadv_frag_purge_orig(struct batadv_orig_node *orig,
bool (*check_cb)(struct batadv_frag_table_entry *));
bool batadv_frag_skb_fwd(struct sk_buff *skb,
struct batadv_hard_iface *recv_if,
- struct batadv_orig_node *orig_node_src);
+ struct batadv_orig_node *orig_node_src,
+ int *rx_result);
bool batadv_frag_skb_buffer(struct sk_buff **skb,
struct batadv_orig_node *orig_node);
int batadv_frag_send_packet(struct sk_buff *skb,
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 8786b66c8a924..9db57fd36e7d4 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -1168,10 +1168,9 @@ int batadv_recv_frag_packet(struct sk_buff *skb,
/* Route the fragment if it is not for us and too big to be merged. */
if (!batadv_is_my_mac(bat_priv, frag_packet->dest) &&
- batadv_frag_skb_fwd(skb, recv_if, orig_node_src)) {
+ batadv_frag_skb_fwd(skb, recv_if, orig_node_src, &ret)) {
/* skb was consumed */
skb = NULL;
- ret = NET_RX_SUCCESS;
goto put_orig_node;
}
--
2.47.3
^ permalink raw reply related
* [PATCH net 00/15] pull request: batman-adv 2026-06-19
From: Simon Wunderlich @ 2026-06-19 7:00 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, b.a.t.m.a.n, Simon Wunderlich
Dear net maintainers,
here are some bugfixes for batman-adv which we would like to have integrated into net.
Please pull or let me know of any problem!
Thank you,
Simon
The following changes since commit dad4d4b92a9b9f0edb8c66deda049da1b62f6089:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-06-11 14:33:35 -0700)
are available in the Git repository at:
https://git.open-mesh.org/batadv.git tags/batadv-net-pullrequest-20260619
for you to fetch changes up to edb557b2ba38fea2c5eb710cf366c797e187218c:
batman-adv: tvlv: avoid race of cifsnotfound handler state (2026-06-14 12:33:18 +0200)
----------------------------------------------------------------
Here are some batman-adv bugfixes, all by Sven Eckelmann:
- gw: don't deselect gateway with active hardif
- TTL fixes in bcast/mcast and fragmentation handling (4 patches)
- BATMAN V: prevent OGM aggregation on disabled hardif
- tp_meter: concurrency and range fixes, add cap to unacked list
(4 patches)
- tt: fix unchecked VLAN ID in tt for local add and roam (2 patches)
- dat: check VLAN ID in the hash
- tvlv: enforce 2-byte alignment
- tvlv: avoid race of cifsnotfound handler state
----------------------------------------------------------------
Sven Eckelmann (15):
batman-adv: gw: don't deselect gateway with active hardif
batman-adv: ensure bcast is writable before modifying TTL
batman-adv: fix (m|b)cast csum after decrementing TTL
batman-adv: frag: ensure fragment is writable before modifying TTL
batman-adv: frag: avoid underflow of TTL
batman-adv: v: prevent OGM aggregation on disabled hardif
batman-adv: tp_meter: restrict number of unacked list entries
batman-adv: tp_meter: annotate last_recv_time access with READ/WRITE_ONCE
batman-adv: tp_meter: prevent parallel modifications of last_recv
batman-adv: tp_meter: handle overlapping packets
batman-adv: tt: don't merge change entries with different VIDs
batman-adv: tt: track roam count per VID
batman-adv: dat: prevent false sharing between VLANs
batman-adv: tvlv: enforce 2-byte alignment
batman-adv: tvlv: avoid race of cifsnotfound handler state
net/batman-adv/bat_iv_ogm.c | 11 ++++-
net/batman-adv/bat_v.c | 1 +
net/batman-adv/bat_v_ogm.c | 23 ++++++++++-
net/batman-adv/distributed-arp-table.c | 12 ++++--
net/batman-adv/fragmentation.c | 22 +++++++++-
net/batman-adv/fragmentation.h | 3 +-
net/batman-adv/hard-interface.c | 28 +------------
net/batman-adv/routing.c | 73 +++++++++++++++++++++++++++++++--
net/batman-adv/tp_meter.c | 74 ++++++++++++++++++++++------------
net/batman-adv/translation-table.c | 12 +++++-
net/batman-adv/tvlv.c | 69 ++++++++++++++++++++++++++++---
net/batman-adv/types.h | 21 ++++++----
12 files changed, 270 insertions(+), 79 deletions(-)
^ permalink raw reply
* [PATCH net 03/15] batman-adv: fix (m|b)cast csum after decrementing TTL
From: Simon Wunderlich @ 2026-06-19 7:00 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, b.a.t.m.a.n, Sven Eckelmann, stable,
Simon Wunderlich
In-Reply-To: <20260619070045.438101-1-sw@simonwunderlich.de>
From: Sven Eckelmann <sven@narfation.org>
The broadcast and multicast packets can be received at the same time by the
local system and forwarded to other nodes. Both are simply decrementing the
TTL at the beginning of the receive path - independent of chosen paths
(receive/forward). But such a modification of the data conflicts with the
hw csum. This is not a problem when the packet is directly forwarded but
can cause errors in the local receive path.
Such a problem can then trigger a "hw csum failure". The receiver path must
therefore ensure that the csum is fixed for each modification of the
payload before batadv_interface_rx() is reached.
Since all batman-adv packet types with a ttl have it as u8 at offset 2, a
helper can be used for all of them. But it is only used at the moment for
batadv_bcast_packet and batadv_mcast_packet because they are the only ones
which deliver the packet locally but unconditionally modify the TTL.
Cc: stable@kernel.org
Fixes: 3f69339068f9 ("batman-adv: bcast: queue per interface, if needed")
Fixes: 07afe1ba288c ("batman-adv: mcast: implement multicast packet reception and forwarding")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/routing.c | 58 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 7b4acd1ad991a..8786b66c8a924 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -8,6 +8,7 @@
#include "main.h"
#include <linux/atomic.h>
+#include <linux/build_bug.h>
#include <linux/byteorder/generic.h>
#include <linux/compiler.h>
#include <linux/errno.h>
@@ -204,6 +205,59 @@ bool batadv_check_management_packet(struct sk_buff *skb,
return true;
}
+/**
+ * batadv_skb_decrement_ttl() - decrement ttl in a batman-adv header, csum-safe
+ * @skb: the received packet with @skb->data pointing to the batman-adv header
+ *
+ * Supports the following packet types, all of which carry the TTL at offset 2:
+ *
+ * - batadv_ogm_packet
+ * - batadv_ogm2_packet
+ * - batadv_icmp_header
+ * - batadv_icmp_packet
+ * - batadv_icmp_tp_packet
+ * - batadv_icmp_packet_rr
+ * - batadv_unicast_packet
+ * - batadv_frag_packet
+ * - batadv_bcast_packet
+ * - batadv_mcast_packet
+ * - batadv_coded_packet
+ * - batadv_unicast_tvlv_packet
+ *
+ * Return: true if the packet may be forwarded (ttl decremented),
+ * false if it must be dropped (ttl would expire)
+ */
+static bool batadv_skb_decrement_ttl(struct sk_buff *skb)
+{
+ static const size_t ttl_offset = 2;
+ u8 *ttl_pos;
+
+ BUILD_BUG_ON(offsetof(struct batadv_ogm_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_ogm2_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_header, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_tp_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_icmp_packet_rr, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_unicast_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_frag_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_bcast_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_mcast_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_coded_packet, ttl) != ttl_offset);
+ BUILD_BUG_ON(offsetof(struct batadv_unicast_tvlv_packet, ttl) != ttl_offset);
+
+ ttl_pos = skb->data + ttl_offset;
+
+ /* would expire on this hop -> drop, leave header + csum untouched */
+ if (*ttl_pos < 2)
+ return false;
+
+ skb_postpull_rcsum(skb, ttl_pos, 1);
+ (*ttl_pos)--;
+ skb_postpush_rcsum(skb, ttl_pos, 1);
+
+ return true;
+}
+
/**
* batadv_recv_my_icmp_packet() - receive an icmp packet locally
* @bat_priv: the bat priv with all the mesh interface information
@@ -1197,7 +1251,7 @@ int batadv_recv_bcast_packet(struct sk_buff *skb,
bcast_packet = (struct batadv_bcast_packet *)skb->data;
- if (bcast_packet->ttl-- < 2)
+ if (!batadv_skb_decrement_ttl(skb))
goto free_skb;
orig_node = batadv_orig_hash_find(bat_priv, bcast_packet->orig);
@@ -1304,7 +1358,7 @@ int batadv_recv_mcast_packet(struct sk_buff *skb,
goto free_skb;
mcast_packet = (struct batadv_mcast_packet *)skb->data;
- if (mcast_packet->ttl-- < 2)
+ if (!batadv_skb_decrement_ttl(skb))
goto free_skb;
tvlv_buff = (unsigned char *)(skb->data + hdr_size);
--
2.47.3
^ permalink raw reply related
* [PATCH net 02/15] batman-adv: ensure bcast is writable before modifying TTL
From: Simon Wunderlich @ 2026-06-19 7:00 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, b.a.t.m.a.n, Sven Eckelmann, stable,
Simon Wunderlich
In-Reply-To: <20260619070045.438101-1-sw@simonwunderlich.de>
From: Sven Eckelmann <sven@narfation.org>
Before batman-adv is allowed to write to an skb, it either has to have its
own copy of the skb or used skb_cow() to ensure that the data part is not
shared.
The old implementation used a shared queue and created copies before
attempting to write to it. But with the new implementation, the broadcast
packet is already modified when it gets received. Potentially writing to
shared buffers in this process.
Adding a skb_cow() right before this operation avoids this and can at the
same time prepare it for the modifications required to rebroadcast the
packet.
Cc: stable@kernel.org
Fixes: 3f69339068f9 ("batman-adv: bcast: queue per interface, if needed")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/routing.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index cd4368b846add..7b4acd1ad991a 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -1191,6 +1191,12 @@ int batadv_recv_bcast_packet(struct sk_buff *skb,
if (batadv_is_my_mac(bat_priv, bcast_packet->orig))
goto free_skb;
+ /* create a copy of the skb, if needed, to modify it. */
+ if (skb_cow(skb, ETH_HLEN) < 0)
+ goto free_skb;
+
+ bcast_packet = (struct batadv_bcast_packet *)skb->data;
+
if (bcast_packet->ttl-- < 2)
goto free_skb;
--
2.47.3
^ permalink raw reply related
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