Felipe Moura d656cfa930 xtensa/espressif: fix lock-order deadlock in esp_wifi_event_handler() ... 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. Signed-off-by: Felipe Moura <moura.fmo@gmail.com> Assisted-by: Claude:claude-sonnet-5		2026-09-18 15:57:44 +08:00
..
include	xtensa: Support BUILD_KERNEL.	2026-09-10 23:28:43 +08:00
src	xtensa/espressif: fix lock-order deadlock in esp_wifi_event_handler()	2026-09-18 15:57:44 +08:00
CMakeLists.txt	cmake:implement CMake build of xtensa arch	2024-11-02 18:08:38 +08:00
Kconfig	arch/atomic: remove up_testset in spinlock	2026-09-08 08:58:54 +08:00