Re: [PATCH v2] debugobjects: Move printk out of db lock critical sections

From: Ingo Molnar
Date: Mon Dec 17 2018 - 13:17:20 EST

* Waiman Long <longman@xxxxxxxxxx> wrote:

> The db->lock is a raw spinlock and so the lock hold time is supposed to
> be short. This will not be the case when printk() is being involved in
> some of the critical sections.
> In order to avoid the long hold time, in case some messages need to be
> printed, all the debug_object_is_on_stack() and debug_print_object()
> calls are now moved out of those critical sections in the following
> functions.
> - __debug_object_init()
> - debug_object_activate()
> - debug_object_deactivate()
> - debug_object_destroy()
> - debug_object_free()
> - debug_object_active_state()
> - __debug_check_no_obj_freed()
> - check_results()
> Holding the db->lock while calling printk() may lead to deadlock if
> printk() somehow requires the allocation/freeing of debug object that
> happens to be in the same hash bucket or a circular lock dependency
> warning from lockdep as reported in

This makes me sad - whatever happened to the principle of keeping printk

We should rename printk() to syslog() or so, and rename early_printk() to
printk(), and be done with this.