On Fri, 05 May 2023 12:16:48 +0200 Bjørn Mork wrote:

"Linux regression tracking (Thorsten Leemhuis)"
[off-list ref] writes:

quoted

quoted

Kernel OOPS on boot

Hello,

on my laptop with kernel 6.3.0 and 6.3.1 fails to correctly boot if the usb-c device "RTL8153 Gigabit Ethernet Adapter" is connected.

If I unplug it, boot and the plug it in, everything works fine.

This used to work fine with 6.2.10.

HW:
- Dell Inc. Latitude 7410/0M5G57, BIOS 1.22.0 03/20/2023
- Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter


Call Trace (manually typed from the image, typos maybe be included)
- bpf_dev_bound_netdev_unregister
- unregister_netdevice_many_notify
- unregister_netdevice_gueue
- unregister_netdev
- usbnet_disconnect
- usb_unbind_interface
- device_release_driver_internal
- bus_remove_device
- device_del
- ? kobject_put
- usb_disable_device
- usb_set_configuration
- rt18152_cfgselector_probe
- usb_probe_device
- really_probe
- ? driver_probe_device
- ...  

Ouch. This is obviously related to the change I made to the RTL8153
driver, which you can see is in effect by the call to
rtl8152_cfgselector_probe above (compensating for the typo).

But to me it doesn't look like the bug is in that driver. It seems we
are triggering some latent bug in the unregister_netdev code?

The trace looks precise enogh to me.  The image also shows

 RIP: 0010: __rhastable_lookup.constprop.0+0x18/0x120

which I believe comes from bpf_dev_bound_netdev_unregister() calling the
bpf_offload_find_netdev(), which does:


bpf_offload_find_netdev(struct net_device *netdev)
{
        lockdep_assert_held(&bpf_devs_lock);

        return rhashtable_lookup_fast(&offdevs, &netdev, offdevs_params);
}


Maybe someone familiar with that code can explain why this fails if called
at boot instead of later?

AFAICS, we don't do anything out of the ordinary in that driver, with
respect to netdev registration at least.  A similar device disconnet and
netdev unregister would also happen if you decided to pull the USB
device from the port during boot.  In fact, most USB network devices
behave similar when disconnected and there is nothing preventing it
from happening while the system is booting..

Yeah, I think it's because late_initcall is too conservative. 
The device gets removed before late_initcall(). 

It's just a hashtable init, I think that we can do:

diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c
index d9c9f45e3529..8a26cd8814c1 100644
--- a/kernel/bpf/offload.c
+++ b/kernel/bpf/offload.c

@@ -859,4 +859,4 @@ static int __init bpf_offload_init(void)
 	return rhashtable_init(&offdevs, &offdevs_params);
 }
 
-late_initcall(bpf_offload_init);
+core_initcall(bpf_offload_init);

Thorsten, how is the communication supposed to work in this case?
Can you ask the reporter to test this? I don't see them on CC...