rockchip64: fix USB gadget NULL pointer crash in eth_get_drvinfo (6.18 + 7.0)#9608
rockchip64: fix USB gadget NULL pointer crash in eth_get_drvinfo (6.18 + 7.0)#9608rubycomm wants to merge 1 commit into
Conversation
…8 + 7.0) Port Ondrej Jirman's (megi) dangling pointer fix from sunxi to rockchip64. Without this patch, udev querying ethtool on the USB gadget ethernet interface during DWC3 bind/unbind cycles can hit a NULL pointer dereference in eth_get_drvinfo(), causing intermittent kernel panics at boot. The f_ncm.c hunks from the original patch are excluded because mainline already handles NCM gadget lifecycle properly via the gether_attach_gadget()/gether_detach_gadget() API. Tested on NanoPi Zero2 (RK3528) with 8 consecutive reboot cycles and zero crashes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThese patches eliminate stale gadget pointers persisting in netdev private data across gadget destroy/recreate cycles. They synchronize gadget pointer updates during bind via Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
✅ This PR has been reviewed and approved — all set for merge! |
… + 7.1) The merged RK3528 USB2 PHY support patch (PR #9500) collapsed rphy->grf onto rphy->phy_base when the DT node had rockchip,usbgrf, making GRF/port-control register accesses hit the standalone PHY MMIO window instead of the syscon. On NanoPi Zero2 this prevents the USB-C gadget from completing high-speed NCM enumeration: the UDC stays at default/full-speed, Windows does not enumerate a usable UsbNcm adapter, and usb0 stays DOWN/NO-CARRIER. The patch description already documented the intended topology (phy_base for the standalone PHY window, grf via the rockchip,usbgrf phandle for port-control fields), but the implementation drifted. Restore the split: keep phy_base mapped to the PHY node, and resolve rphy->grf from the rockchip,usbgrf phandle. Fall back to the parent syscon for older SoC layouts without the phandle. Apply identically to rockchip64-6.18, rockchip64-7.0, and the rockchip64-7.1 archive (added in 9d967ec, inherited the bug). Tested on FriendlyElec NanoPi Zero2 (RK3528) with a configfs NCM gadget over /sys/kernel/config/usb_gadget: Before this patch: /sys/class/udc/fe500000.usb/state = default /sys/class/udc/fe500000.usb/current_speed = full-speed usb0: DOWN, NO-CARRIER Windows host: no UsbNcm Host Device After this patch: /sys/class/udc/fe500000.usb/state = configured /sys/class/udc/fe500000.usb/current_speed = high-speed usb0: UP, LOWER_UP, 10.10.10.1/24, fe80::12:34ff:fe56:789a/64 Windows host: UsbNcm Host Device #5, Up, 426.0 Mbps ping fe80::12:34ff:fe56:789a%122: 3 sent / 3 received / 0% loss Note: a separate u_ether NULL-deref on gadget teardown is tracked under PR #9608 and is not addressed here. Signed-off-by: Shlomi Marco <s.marco@rubycomm.com>
… + 7.1) The merged RK3528 USB2 PHY support patch (PR armbian#9500) collapsed rphy->grf onto rphy->phy_base when the DT node had rockchip,usbgrf, making GRF/port-control register accesses hit the standalone PHY MMIO window instead of the syscon. On NanoPi Zero2 this prevents the USB-C gadget from completing high-speed NCM enumeration: the UDC stays at default/full-speed, Windows does not enumerate a usable UsbNcm adapter, and usb0 stays DOWN/NO-CARRIER. The patch description already documented the intended topology (phy_base for the standalone PHY window, grf via the rockchip,usbgrf phandle for port-control fields), but the implementation drifted. Restore the split: keep phy_base mapped to the PHY node, and resolve rphy->grf from the rockchip,usbgrf phandle. Fall back to the parent syscon for older SoC layouts without the phandle. Apply identically to rockchip64-6.18, rockchip64-7.0, and the rockchip64-7.1 archive (added in 9d967ec, inherited the bug). Tested on FriendlyElec NanoPi Zero2 (RK3528) with a configfs NCM gadget over /sys/kernel/config/usb_gadget: Before this patch: /sys/class/udc/fe500000.usb/state = default /sys/class/udc/fe500000.usb/current_speed = full-speed usb0: DOWN, NO-CARRIER Windows host: no UsbNcm Host Device After this patch: /sys/class/udc/fe500000.usb/state = configured /sys/class/udc/fe500000.usb/current_speed = high-speed usb0: UP, LOWER_UP, 10.10.10.1/24, fe80::12:34ff:fe56:789a/64 Windows host: UsbNcm Host Device #5, Up, 426.0 Mbps ping fe80::12:34ff:fe56:789a%122: 3 sent / 3 received / 0% loss Note: a separate u_ether NULL-deref on gadget teardown is tracked under PR armbian#9608 and is not addressed here. Signed-off-by: Shlomi Marco <s.marco@rubycomm.com>
Summary
eth_get_drvinfo()when udev queries ethtool on a USB gadget ethernet interface during DWC3 bind/unbind cyclescurrent(6.18) andedge(7.0) kernel branchesProblem
When USB gadget ethernet (NCM/ECM/RNDIS) is configured, the DWC3 controller may destroy and re-create the gadget during role switching. If udev probes the network interface via ethtool during this window,
eth_get_drvinfo()dereferences a NULLdev->gadgetpointer, causing a kernel panic:This crash is intermittent — it depends on timing between udev and the gadget bind/unbind cycle.
Fix
The patch (originally by Ondrej Jirman / megi, already applied in sunxi):
dev->gadgetineth_get_drvinfo()SET_NETDEV_DEV()parenting that creates stale references after gadget destructionNote: The
f_ncm.chunks from the original patch are excluded because mainline already handles NCM gadget lifecycle viagether_attach_gadget()/gether_detach_gadget().Test plan
git apply --check)ethtool -i usb0returns without crash6.18.20-current-rockchip64Summary by CodeRabbit