linux-kernel - Re: locking problems in iwlwifi? was Re: 6.16-rcX: crashing way too often on thinkpad X220

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] [day] [month] [year] [list]

Message-ID: <c13616d1-b11e-460a-8eda-5aa72c9123d8@redhat.com>
Date: Fri, 25 Jul 2025 15:38:38 -0400
From: Waiman Long <llong@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>, Waiman Long <llong@...hat.com>,
 John Ogness <jogness@...utronix.de>, Pavel Machek <pavel@....cz>
Cc: kernel list <linux-kernel@...r.kernel.org>, mingo@...hat.com,
 bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 peterz@...radead.org, will@...nel.org, miriam.rachel.korenblit@...el.com,
 linux-wireless@...r.kernel.org, Petr Mladek <pmladek@...e.com>
Subject: Re: locking problems in iwlwifi? was Re: 6.16-rcX: crashing way too
 often on thinkpad X220

On 7/25/25 9:44 AM, Thomas Gleixner wrote:
> On Thu, Jul 24 2025 at 20:16, Waiman Long wrote:
>> On 7/24/25 3:45 PM, John Ogness wrote:
>> I am sorry for confusing conole_owner_lock with the console_owner
>> lockdep map. Yes, this lockdep splat should be a false positive. You do
>> need to put the mutex_acquire before printk_safe_exit_irqrestore() to
>> avoid this splat.
> No. The printk code is absolutely correct as it is.
>
> Did you actually read my analysis?
I have read your analysis and I believe in your conclusion.
>
> The lockdep splat is triggered by the raw_spin_unlock_irq() in
> __flush_work() as it makes console_owner unsafe.
>
> Again:
>
>    printk()
>      local_irq_save()
>        acquire(console_owner);
>        con->write()
>          vt_console_print()
>            hide_cursor()
>              vc->vc_sw->con_cursor()
>                fbcon_cursor()
>                  fbcon_del_cursor_work()
>                    cancel_delayed_work_sync()
>                      __flush_work()
>                        raw_spin_unlock_irq()          <- FAIL
>
> The initial report from
>
> cancel_delayed_work_sync() _CANNOT_ be invoked from atomic contexts,
> unless the work is marked as BH work. And for BH work it cannot be
> called from hard interrupt context for obvious reasons.
>
> Marking that cursor work BH is not helping either, as printk() can be
> invoked from everywhere.
>
> There is no way to legitimately invoke cancel_delayed_work_sync() from
> the legacy console write() callback ever.
>
> No?

I am not disputing this.

Thanks,
Longman