* 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
* Re: [PATCH bpf v4 1/3] selftests/bpf: don't modify the skb in the strparser parser prog
From: bot+bpf-ci @ 2026-06-19 7:08 UTC (permalink / raw)
To: rhkrqnwk98, ast, andrii, daniel, eddyz87, memxor, john.fastabend,
jakub, davem, kuba, edumazet, pabeni, kuniyu, willemb, shuah
Cc: jolsa, martin.lau, song, yonghong.song, horms, bobbyeshleman,
jiayuan.chen, bpf, netdev, linux-kernel, linux-kselftest, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260619062959.3277612-2-rhkrqnwk98@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
> selftests/bpf: don't modify the skb in the strparser parser prog
>
> sockmap_parse_prog.c is attached as an SK_SKB stream parser and modifies
> the skb. It calls bpf_skb_pull_data() and writes a byte into the packet.
> A stream parser runs on strparser's message head and must not modify it.
> A resize frees the frag_list segments strparser still tracks, leading to
> a use-after-free.
>
> Make the parser read-only. It only needs to return the message length,
> which keeps it attaching once packet-modifying parsers are rejected.
>
> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
This removes a use-after-free where bpf_skb_pull_data(skb, 10) resizes and
frees the frag_list segments that strparser still tracks for the message
head. The buggy bpf_skb_pull_data(skb, 10) call and the packet write being
removed here were added by commit 82a8616889d5 ("bpf: add map tests for
BPF_PROG_TYPE_SK_MSG").
Should this carry a Fixes: tag?
Fixes: 82a8616889d5 ("bpf: add map tests for BPF_PROG_TYPE_SK_MSG")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27809861429
^ permalink raw reply
* Re: [PATCH bpf v4 3/3] selftests/bpf: test rejection of a packet-modifying SK_SKB stream parser
From: bot+bpf-ci @ 2026-06-19 7:08 UTC (permalink / raw)
To: rhkrqnwk98, ast, andrii, daniel, eddyz87, memxor, john.fastabend,
jakub, davem, kuba, edumazet, pabeni, kuniyu, willemb, shuah
Cc: jolsa, martin.lau, song, yonghong.song, horms, bobbyeshleman,
jiayuan.chen, bpf, netdev, linux-kernel, linux-kselftest, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260619062959.3277612-4-rhkrqnwk98@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
> selftests/bpf: test rejection of a packet-modifying SK_SKB stream parser
>
> Verify that attaching an SK_SKB stream parser that can modify the packet
> is rejected, while a read-only parser still attaches.
>
> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
This test exercises the rejection of a stream parser that resizes the skb,
which is the use-after-free path introduced when sk_skb programs gained
access to packet data. An earlier single-patch version of this work
carried a Fixes: tag pointing at that commit, and it appears to have been
dropped when the series was split into multiple patches.
Should this commit include:
Fixes: 8a31db561566 ("bpf: add access to sock fields and pkt data from sk_skb programs")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27809861429
^ permalink raw reply
* [PATCH net 15/15] batman-adv: tvlv: avoid race of cifsnotfound handler state
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>
TVLV handlers can have the flag BATADV_TVLV_HANDLER_OGM_CIFNOTFND set to
signal that the OGM handler should be called (with NULL for data) when the
specific TVLV container was not found in the OGM. This is used by:
* DAT
* GW
* Multicast (OGM + Tracker)
The state whether the handler was executed was stored in the struct
batadv_tvlv_handler. But the TVLV processing is started without any lock.
Multiple parallel contexts processing TVLVs would therefore overwrite each
others BATADV_TVLV_HANDLER_OGM_CALLED flag in the shared
batadv_tvlv_handler.
Drop the shared BATADV_TVLV_HANDLER_OGM_CALLED flag and instead determine,
per TVLV buffer, whether a matching container was present by scanning the
packet's buffer.
Cc: stable@kernel.org
Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/tvlv.c | 63 ++++++++++++++++++++++++++++++++++++++----
net/batman-adv/types.h | 7 -----
2 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/net/batman-adv/tvlv.c b/net/batman-adv/tvlv.c
index a957555d8958d..1c9fb21985f6a 100644
--- a/net/batman-adv/tvlv.c
+++ b/net/batman-adv/tvlv.c
@@ -411,7 +411,6 @@ static int batadv_tvlv_call_handler(struct batadv_priv *bat_priv,
tvlv_handler->ogm_handler(bat_priv, orig_node,
BATADV_NO_FLAGS,
tvlv_value, tvlv_value_len);
- tvlv_handler->flags |= BATADV_TVLV_HANDLER_OGM_CALLED;
break;
case BATADV_UNICAST_TVLV:
if (!skb)
@@ -443,6 +442,48 @@ static int batadv_tvlv_call_handler(struct batadv_priv *bat_priv,
return NET_RX_SUCCESS;
}
+/**
+ * batadv_tvlv_containers_contain() - check if a tvlv buffer holds a container
+ * @tvlv_value: tvlv content
+ * @tvlv_value_len: tvlv content length
+ * @type: tvlv container type to look for
+ * @version: tvlv container version to look for
+ *
+ * Return: true if a container of the given type and version is present in the
+ * tvlv buffer, false otherwise.
+ */
+static bool batadv_tvlv_containers_contain(void *tvlv_value,
+ u16 tvlv_value_len, u8 type,
+ u8 version)
+{
+ struct batadv_tvlv_hdr *tvlv_hdr;
+ u16 tvlv_value_cont_len;
+
+ while (tvlv_value_len >= sizeof(*tvlv_hdr)) {
+ tvlv_hdr = tvlv_value;
+ tvlv_value_cont_len = ntohs(tvlv_hdr->len);
+ tvlv_value = tvlv_hdr + 1;
+ tvlv_value_len -= sizeof(*tvlv_hdr);
+
+ if (tvlv_value_cont_len > tvlv_value_len)
+ break;
+
+ /* the next tvlv header is accessed assuming (at least) 2-byte
+ * alignment, so it must start at an even offset.
+ */
+ if (tvlv_value_cont_len & 1)
+ break;
+
+ if (tvlv_hdr->type == type && tvlv_hdr->version == version)
+ return true;
+
+ tvlv_value = (u8 *)tvlv_value + tvlv_value_cont_len;
+ tvlv_value_len -= tvlv_value_cont_len;
+ }
+
+ return false;
+}
+
/**
* batadv_tvlv_containers_process() - parse the given tvlv buffer to call the
* appropriate handlers
@@ -462,7 +503,9 @@ int batadv_tvlv_containers_process(struct batadv_priv *bat_priv,
struct sk_buff *skb, void *tvlv_value,
u16 tvlv_value_len)
{
+ u16 tvlv_value_start_len = tvlv_value_len;
struct batadv_tvlv_handler *tvlv_handler;
+ void *tvlv_value_start = tvlv_value;
struct batadv_tvlv_hdr *tvlv_hdr;
u16 tvlv_value_cont_len;
u8 cifnotfound = BATADV_TVLV_HANDLER_OGM_CIFNOTFND;
@@ -506,12 +549,20 @@ int batadv_tvlv_containers_process(struct batadv_priv *bat_priv,
if (!tvlv_handler->ogm_handler)
continue;
- if ((tvlv_handler->flags & BATADV_TVLV_HANDLER_OGM_CIFNOTFND) &&
- !(tvlv_handler->flags & BATADV_TVLV_HANDLER_OGM_CALLED))
- tvlv_handler->ogm_handler(bat_priv, orig_node,
- cifnotfound, NULL, 0);
+ if (!(tvlv_handler->flags & BATADV_TVLV_HANDLER_OGM_CIFNOTFND))
+ continue;
- tvlv_handler->flags &= ~BATADV_TVLV_HANDLER_OGM_CALLED;
+ /* if the corresponding container was present then the handler
+ * was already called from the loop above
+ */
+ if (batadv_tvlv_containers_contain(tvlv_value_start,
+ tvlv_value_start_len,
+ tvlv_handler->type,
+ tvlv_handler->version))
+ continue;
+
+ tvlv_handler->ogm_handler(bat_priv, orig_node,
+ cifnotfound, NULL, 0);
}
rcu_read_unlock();
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index 3de3c1ac0244f..b1f9f8964c3fd 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -2294,13 +2294,6 @@ enum batadv_tvlv_handler_flags {
* will call this handler even if its type was not found (with no data)
*/
BATADV_TVLV_HANDLER_OGM_CIFNOTFND = BIT(1),
-
- /**
- * @BATADV_TVLV_HANDLER_OGM_CALLED: interval tvlv handling flag - the
- * API marks a handler as being called, so it won't be called if the
- * BATADV_TVLV_HANDLER_OGM_CIFNOTFND flag was set
- */
- BATADV_TVLV_HANDLER_OGM_CALLED = BIT(2),
};
#endif /* _NET_BATMAN_ADV_TYPES_H_ */
--
2.47.3
^ permalink raw reply related
* [PATCH net 14/15] batman-adv: tvlv: enforce 2-byte alignment
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 fields of an aggregated OGM(v2) are accessed assuming (at least) 2-byte
alignment, so a following OGM must start at an even offset. As the header
length is even, an odd tvlv_len would misalign it and trigger unaligned
accesses on strict-alignment architectures.
Such a misaligned TVLV/OGM/OGMv2 is not created by a normal participant in
the mesh. Therefore, reject such malformed packets.
Cc: stable@kernel.org
Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/bat_iv_ogm.c | 11 ++++++++++-
net/batman-adv/bat_v_ogm.c | 11 ++++++++++-
net/batman-adv/routing.c | 6 ++++++
net/batman-adv/tvlv.c | 6 ++++++
4 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/bat_iv_ogm.c b/net/batman-adv/bat_iv_ogm.c
index 7588e64e7ba6f..bb2f012b454ea 100644
--- a/net/batman-adv/bat_iv_ogm.c
+++ b/net/batman-adv/bat_iv_ogm.c
@@ -316,14 +316,23 @@ batadv_iv_ogm_aggr_packet(int buff_pos, int packet_len,
const struct batadv_ogm_packet *ogm_packet)
{
int next_buff_pos = 0;
+ u16 tvlv_len;
/* check if there is enough space for the header */
next_buff_pos += buff_pos + sizeof(*ogm_packet);
if (next_buff_pos > packet_len)
return false;
+ tvlv_len = ntohs(ogm_packet->tvlv_len);
+
+ /* the fields of an aggregated OGM are accessed assuming (at least)
+ * 2-byte alignment, so a following OGM must start at an even offset.
+ */
+ if (tvlv_len & 1)
+ return false;
+
/* check if there is enough space for the optional TVLV */
- next_buff_pos += ntohs(ogm_packet->tvlv_len);
+ next_buff_pos += tvlv_len;
return next_buff_pos <= packet_len;
}
diff --git a/net/batman-adv/bat_v_ogm.c b/net/batman-adv/bat_v_ogm.c
index 95efd8a43c79d..037921aad35d5 100644
--- a/net/batman-adv/bat_v_ogm.c
+++ b/net/batman-adv/bat_v_ogm.c
@@ -849,14 +849,23 @@ batadv_v_ogm_aggr_packet(int buff_pos, int packet_len,
const struct batadv_ogm2_packet *ogm2_packet)
{
int next_buff_pos = 0;
+ u16 tvlv_len;
/* check if there is enough space for the header */
next_buff_pos += buff_pos + sizeof(*ogm2_packet);
if (next_buff_pos > packet_len)
return false;
+ tvlv_len = ntohs(ogm2_packet->tvlv_len);
+
+ /* the fields of an aggregated OGMv2 are accessed assuming (at least)
+ * 2-byte alignment, so a following OGMv2 must start at an even offset.
+ */
+ if (tvlv_len & 1)
+ return false;
+
/* check if there is enough space for the optional TVLV */
- next_buff_pos += ntohs(ogm2_packet->tvlv_len);
+ next_buff_pos += tvlv_len;
return next_buff_pos <= packet_len;
}
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 9db57fd36e7d4..c05fcc9241add 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -1366,6 +1366,12 @@ int batadv_recv_mcast_packet(struct sk_buff *skb,
if (tvlv_buff_len > skb->len - hdr_size)
goto free_skb;
+ /* the fields of an multicast payload are accessed assuming (at least)
+ * 2-byte alignment, so a following packet must start at an even offset.
+ */
+ if (tvlv_buff_len & 1)
+ goto free_skb;
+
ret = batadv_tvlv_containers_process(bat_priv, BATADV_MCAST, NULL, skb,
tvlv_buff, tvlv_buff_len);
if (ret >= 0) {
diff --git a/net/batman-adv/tvlv.c b/net/batman-adv/tvlv.c
index 403c854568704..a957555d8958d 100644
--- a/net/batman-adv/tvlv.c
+++ b/net/batman-adv/tvlv.c
@@ -477,6 +477,12 @@ int batadv_tvlv_containers_process(struct batadv_priv *bat_priv,
if (tvlv_value_cont_len > tvlv_value_len)
break;
+ /* the next tvlv header is accessed assuming (at least) 2-byte
+ * alignment, so it must start at an even offset.
+ */
+ if (tvlv_value_cont_len & 1)
+ break;
+
tvlv_handler = batadv_tvlv_handler_get(bat_priv,
tvlv_hdr->type,
tvlv_hdr->version);
--
2.47.3
^ permalink raw reply related
* [PATCH net 13/15] batman-adv: dat: prevent false sharing between VLANs
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 local hash of DAT entries is supposed to be VLAN (VID) aware. But
the adding to the hash and the search in the hash were not checking the VID
information of the hash entries. The entries would therefore only be
correctly separated when batadv_hash_dat() didn't select the same buckets
for different VIDs.
Cc: stable@kernel.org
Fixes: be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
---
net/batman-adv/distributed-arp-table.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c
index aaea155b94038..ae39ceaa2e29a 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -215,10 +215,13 @@ static void batadv_dat_purge(struct work_struct *work)
*/
static bool batadv_compare_dat(const struct hlist_node *node, const void *data2)
{
- const void *data1 = container_of(node, struct batadv_dat_entry,
- hash_entry);
+ const struct batadv_dat_entry *entry1;
+ const struct batadv_dat_entry *entry2;
- return memcmp(data1, data2, sizeof(__be32)) == 0;
+ entry1 = container_of(node, struct batadv_dat_entry, hash_entry);
+ entry2 = data2;
+
+ return entry1->ip == entry2->ip && entry1->vid == entry2->vid;
}
/**
@@ -345,6 +348,9 @@ batadv_dat_entry_hash_find(struct batadv_priv *bat_priv, __be32 ip,
if (dat_entry->ip != ip)
continue;
+ if (dat_entry->vid != vid)
+ continue;
+
if (!kref_get_unless_zero(&dat_entry->refcount))
continue;
--
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