On Fri, Jul 14, 2017 at 02:10:14AM -0700, tip-bot for Wanpeng Li wrote: > Commit-ID: 0e4097c3354e2f5a5ad8affd9dc7f7f7d00bb6b9 > Gitweb: http://git.kernel.org/tip/0e4097c3354e2f5a5ad8affd9dc7f7f7d00bb6b9 > Author: Wanpeng Li <wanpeng.li@xxxxxxxxxxx> > AuthorDate: Sun, 9 Jul 2017 00:40:28 -0700 > Committer: Ingo Molnar <mingo@xxxxxxxxxx> > CommitDate: Fri, 14 Jul 2017 10:27:15 +0200 > > sched/cputime: Don't use smp_processor_id() in preemptible context > > Recent kernels trigger this warning: > > BUG: using smp_processor_id() in preemptible [00000000] code: 99-trinity/181 > caller is debug_smp_processor_id+0x17/0x19 > CPU: 0 PID: 181 Comm: 99-trinity Not tainted 4.12.0-01059-g2a42eb9 #1 > Call Trace: > dump_stack+0x82/0xb8 > check_preemption_disabled() > debug_smp_processor_id() > vtime_delta() > task_cputime() > thread_group_cputime() > thread_group_cputime_adjusted() > wait_consider_task() > do_wait() > SYSC_wait4() > do_syscall_64() > entry_SYSCALL64_slow_path() > > As Frederic pointed out: > > | Although those sched_clock_cpu() things seem to only matter when the > | sched_clock() is unstable. And that stability is a condition for nohz_full > | to work anyway. So probably sched_clock() alone would be enough. > > This patch fixes it by replacing sched_clock_cpu() with sched_clock() to > avoid calling smp_processor_id() in a preemptible context. > > Reported-by: Xiaolong Ye <xiaolong.ye@xxxxxxxxx> > Signed-off-by: Wanpeng Li <wanpeng.li@xxxxxxxxxxx> > Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx> > Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > Cc: Luiz Capitulino <lcapitulino@xxxxxxxxxx> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Cc: Rik van Riel <riel@xxxxxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Link: http://lkml.kernel.org/r/1499586028-7402-1-git-send-email-wanpeng.li@xxxxxxxxxxx > [ Prettified the changelog. ] > Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx> Thanks! The patch looks good! -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|