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: <157c703381624d331c7de4aeb2b2802789239456.camel@sipsolutions.net>
Date: Tue, 09 Apr 2024 10:59:42 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Linux regressions mailing list <regressions@...ts.linux.dev>, Ben Greear
	 <greearb@...delatech.com>, LKML <linux-kernel@...r.kernel.org>, 
	linux-leds@...r.kernel.org
Subject: Re: 6.9.0-rc2+ kernel hangs on boot (bisected, maybe LED related)

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

Don't think so, that was related to devm and module unload, neither
seems to be the case here.

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ