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

[Waiman Long <llong@redhat.com>]

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