Re: [PATCH wireless-next] wifi: cfg80211: fix regulatory.db async firmware request blocking __usermodehelper_disable()

[Carlos Llamas <cmllamas@google.com>]

On Thu, Jun 25, 2026 at 02:59:04PM +0530, Kavita Kavita wrote:
> cfg80211 schedules an asynchronous request_firmware() work item for
> regulatory.db via request_firmware_work_func(). When the direct
> firmware load fails, _request_firmware() falls back to the sysfs
> fallback path via firmware_fallback_sysfs(), which blocks indefinitely
> in wait_for_completion_killable_timeout() waiting for userspace to
> supply the firmware through the sysfs interface.
> 
> While this work item is pending, any caller of
> __usermodehelper_disable() will deadlock attempting to acquire the
> usermodehelper rwsem for writing, since the sysfs firmware fallback
> path holds the rwsem for reading and is blocked waiting for userspace
> response that can never arrive while usermode helpers are being
> disabled.
> 
> Observed call traces where system suspend blocked due to regulatory.db
> async firmware request:
> 
>   kworker/6:3 (pid 194) holding usermodehelper rwsem read lock, blocked
>    waiting for userspace firmware response:
>      wait_for_completion_killable_timeout+0x48
>      firmware_fallback_sysfs+0x270
>      _request_firmware+0x790
>      request_firmware_work_func+0x44
>      process_one_work[jt]+0x59c
>      worker_thread+0x260
>      kthread+0x150
>      ret_from_fork+0x10
> 
>   Caller blocked in __usermodehelper_disable() during system suspend:
>      rwsem_down_write_slowpath+0x768
>      down_write+0x98
>      __usermodehelper_disable+0x3c
>      freeze_processes+0x18
>      pm_suspend+0x320
>      state_store+0x104
>      kernfs_fop_write_iter[jt]+0x168
>      vfs_write+0x270
>      ksys_write+0x78
> 
> Any service or kernel subsystem invoking __usermodehelper_disable() is
> susceptible to this hang as long as the regulatory.db sysfs fallback
> request remains outstanding.
> 
> Fix this by replacing the unconditional uevent-based load with a
> two-step approach. First, attempt a synchronous load via
> request_firmware_direct() at init time. This is fast and
> non-blocking, if the file is present in standard paths it is loaded
> immediately with no delay. If not found, the load is deferred to
> wiphy_regulatory_register() and triggered via
> firmware_request_nowait_nowarn() only when the first non-self-managed
> wiphy registers.
> 
> For self-managed drivers (REGULATORY_WIPHY_SELF_MANAGED), the hang is
> avoided because wiphy_regulatory_register() handles them separately
> and the deferred load path is never reached, so the file load is not
> attempted at all. For this case, regulatory information is obtained
> from driver/firmware during wiphy registration. For non-self-managed
> drivers, the file is required and is expected to be present. The
> deferred load via firmware_request_nowait_nowarn() is triggered only
> when the first such wiphy registers. This ensures the database is
> loaded only when it is actually needed, avoiding the sysfs fallback
> path on systems where the file is absent at init time.
> 
> Also refactor regdb_fw_cb() into two functions: regdb_load() which
> validates and stores the firmware image, and regdb_fw_cb_restore()
> which is the async callback that calls restore_regulatory_settings()
> to replay all pending regulatory requests (country hints from core,
> user, driver and country IE) that arrived while the database was not
> yet available.
> 
> NOTE:
> This issue was observed on Android platforms where regulatory.db is
> absent.
> Steps to reproduce on Android platforms:
>   1. Power off the device completely.
>   2. Connect the charger; the device enters off-mode charging.
>   3. While in off-mode charging, short press the power key.
> 
> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>

Are you missing a `Fixes:` tag for this?