* Waiman Long <long...@redhat.com> 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 > > https://lkml.kernel.org/r/20181211091154.GL23332@shao2-debian This makes me sad - whatever happened to the principle of keeping printk simple? We should rename printk() to syslog() or so, and rename early_printk() to printk(), and be done with this. Thanks, Ingo
