timekeeping: use printk_deferred when holding timekeeping seqlock
authorJohn Stultz <john.stultz@linaro.org>
Wed, 4 Jun 2014 23:11:43 +0000 (16:11 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 4 Jun 2014 23:54:17 +0000 (16:54 -0700)
commit6d9bcb621b0b0a20604cbdb298c4487e44dd0da2
treee6bb8032b8662be3551d4abcc04499c39c9e85df
parentc224815dac9c739b79050d3cc67443ff500bc478
timekeeping: use printk_deferred when holding timekeeping seqlock

Jiri Bohac pointed out that there are rare but potential deadlock
possibilities when calling printk while holding the timekeeping
seqlock.

This is due to printk() triggering console sem wakeup, which can
cause scheduling code to trigger hrtimers which may try to read
the time.

Specifically, as Jiri pointed out, that path is:
  printk
    vprintk_emit
      console_unlock
        up(&console_sem)
          __up
    wake_up_process
      try_to_wake_up
        ttwu_do_activate
  ttwu_activate
    activate_task
      enqueue_task
        enqueue_task_fair
  hrtick_update
    hrtick_start_fair
      hrtick_start_fair
        get_time
  ktime_get
    --> endless loop on
    read_seqcount_retry(&timekeeper_seq, ...)

This patch tries to avoid this issue by using printk_deferred (previously
named printk_sched) which should defer printing via a irq_work_queue.

Signed-off-by: John Stultz <john.stultz@linaro.org>
Reported-by: Jiri Bohac <jbohac@suse.cz>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kernel/time/ntp.c
kernel/time/timekeeping.c