Jiri pointed out a potential deadlock when calling printk while holding the timekeeping seqlock.
Annoyingly, the seqlock lockdep enablement doesn't catch this, as printk disables lockdep. When looking for possible solutions, one idea was to use a local buffer and defer the printk to later. Ends up there is already similar functionality in printk_sched() to avoid similar style deadlocks w/ the scheduler. Thus this patchset renames printk_sched to printk_deferred and then moves the affected timekeeping printks to make use of it. There were some points in the discussion between Jan and Peter that made it seem that there may still be problems lurking in the console layer, and I'm not sure I fully understand their point, so this solution may be incomplete. Additionally, the same issue likely affects any WARN_ONs as well, but I wanted to get some thoughts on this approach before trying to remove or convert affected WARN_ONS. Your thoughts and feedback are greatly appreciated! thanks -john Cc: Jan Kara <j...@suse.cz> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Jiri Bohac <jbo...@suse.cz> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: Andrew Morton <a...@linux-foundation.org> John Stultz (3): printk: Rename printk_sched to printk_deferred printk: Add printk_once_deferred timekeeping: Use printk_deferred when holding timekeeping seqlock include/linux/printk.h | 17 ++++++++++++++--- kernel/printk/printk.c | 8 ++++---- kernel/sched/core.c | 2 +- kernel/sched/deadline.c | 7 +------ kernel/sched/rt.c | 8 +------- kernel/time/ntp.c | 15 +++++++++------ kernel/time/timekeeping.c | 7 ++++--- 7 files changed, 34 insertions(+), 30 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/