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

Message-ID: <87y0scpepu.ffs@tglx>
Date: Fri, 25 Jul 2025 15:44:29 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Waiman Long <llong@...hat.com>, John Ogness <jogness@...utronix.de>,
 Waiman Long <llong@...hat.com>, 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 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?

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?

Thanks,

        tglx