linux-kernel - Re: 6.9.0-rc2+ kernel hangs on boot (bisected, maybe LED related)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93494f0b-ad05-4566-b454-fa36a7dac248@leemhuis.info>
Date: Tue, 9 Apr 2024 10:47:34 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Johannes Berg <johannes@...solutions.net>,
 Ben Greear <greearb@...delatech.com>, LKML <linux-kernel@...r.kernel.org>,
 linux-leds@...r.kernel.org,
 Linux kernel regressions list <regressions@...ts.linux.dev>
Subject: Re: 6.9.0-rc2+ kernel hangs on boot (bisected, maybe LED related)

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@gmail.com/

Ciao, Thorsten