Recently, 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 (based on next/akpm) 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 Changes since v1: * Rebased on next/akpm, since there are queued prink patches there * Re-added irqsave/restore per irc discussion w/ PeterZ 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> Cc: Steven Rostedt <rost...@goodmis.org> John Stultz (4): printk: Re-add irqsave/restore in printk_sched 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 | 5 ++++- 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(+), 27 deletions(-) -- 1.9.1 -- 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/