On Tue, 2024-04-09 at 10:47 +0200, Linux regression tracking (Thorsten Leemhuis) wrote: > On 08.04.24 18:35, Johannes Berg wrote: > > On Wed, 2024-04-03 at 12:35 -0700, Ben Greear wrote: > > > > > > > > So, deadlock I guess.... > > > > > > > > INFO: task kworker/5:13:648 blocked for more than 180 seconds. > > > > Not tainted 6.9.0-rc2+ #23 > > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > > > task:kworker/5:13 state:D stack:0 pid:648 tgid:648 ppid:2 flags:0x00004000 > > > > Workqueue: events deferred_probe_timeout_work_func > > > > Call Trace: > > > > <TASK> > > > > __schedule+0x43d/0xe20 > > > > schedule+0x31/0x130 > > > > schedule_timeout+0x1b9/0x1d0 > > > > ? mark_held_locks+0x49/0x70 > > > > ? lockdep_hardirqs_on_prepare+0xd6/0x170 > > > > __wait_for_common+0xb9/0x1d0 > > > > ? usleep_range_state+0xb0/0xb0 > > > > ? __flush_work+0x1ff/0x460 > > > > __flush_work+0x287/0x460 > > > > ? flush_workqueue_prep_pwqs+0x120/0x120 > > > > deferred_probe_timeout_work_func+0x2b/0xa0 > > > > This seems ... complex. > > > > Does changing iwlwifi's request_module() to request_module_nowait() in > > iwl_req_fw_callback() (only) fix it? I think we can do that, we don't > > really care at that point, and the issue here seems to be waiting for it > > while also other modules are loading and due to the hashing in > > idempotent() (kernel/module/main.c) it can't make progress. > > Not my area of expertise, so listening to me my send you off-track. > > Might this be related to the issue discussed here: > https://lore.kernel.org/all/ZhRD3cOtz5i-61PB@mail-itl/ > > See also: > https://lore.kernel.org/all/2695e9db-a5a0-4564-9812-a50b91fb1b46@xxxxxxxxx/ Don't think so, that was related to devm and module unload, neither seems to be the case here. johannes
