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
