jerpelea opened a new pull request, #20305: URL: https://github.com/apache/nuttx/pull/20305
## Summary esp_wifi_event_handler() held esp_wifi_lock() across the whole event switch, including the esp_wlan_*_hook() calls (WIFI_EVENT_STA_CONNECTED/_DISCONNECTED, WIFI_EVENT_AP_START/_STOP). Those hooks reach netdev_lower_carrier_on()/_off(), which take the per-device netdev_lock(). Every other path into esp_wifi_lock() acquires the two locks in the opposite order -- the netdev ifdown path holds netdev_lock() around its own call into esp_wifi_api_stop(), which calls esp_wifi_lock(). An application that disconnects Wi-Fi (wpa_driver_wext_disconnect() immediately followed by wapi_set_ifdown()) races the resulting WIFI_EVENT_STA_DISCONNECTED callback against its own ifdown call, and the two lock orders wedge each other permanently. Confirmed on real ESP32-S3 hardware (XIAO ESP32-S3, CONFIG_ESPRESSIF_WIFI + CONFIG_PM + CONFIG_SCHED_TICKLESS): the disconnecting task and the low-priority work-queue thread each waited on a mutex held by the other (checked live via JTAG/GDB, not inferred from code reading alone). Reproduced 4/4 times before this fix, 0/2 after. Fix: esp_wifi_lock() is now taken only around the specific calls that reach into the Wi-Fi driver API (esp_wifi_scan_event_parse(), esp_wifi_set_ps()), never spanning a esp_wlan_*_hook() call -- netdev_lock() first (or absent), esp_wifi_lock() last, on every path. ## Impact RELEASE ## Testing CI -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
