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

[Kavita Kavita <kavita.kavita@oss.qualcomm.com>]

On 6/26/2026 8:16 PM, Carlos Llamas wrote:
> 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?
> 


I have included Fixes Tag in v2 version. Thanks.