Re: sched: odd values for effective load calculations

[Ingo Molnar <mingo@kernel.org>]

* Sasha Levin <levinsasha928@gmail.com> wrote:

> Hi all,
> 
> I was fuzzing with trinity inside a KVM tools guest, running the latest -next
> kernel along with the undefined behaviour sanitizer patch, and hit the following:
> 
> [  787.894288] ================================================================================
> [  787.897074] UBSan: Undefined behaviour in kernel/sched/fair.c:4541:17
> [  787.898981] signed integer overflow:
> [  787.900066] 361516561629678 * 101500 cannot be represented in type 'long long int'
> [  787.900066] CPU: 18 PID: 12958 Comm: trinity-c103 Not tainted 3.18.0-rc6-next-20141201-sasha-00070-g028060a-dirty #1528
> [  787.900066]  0000000000000000 0000000000000000 ffffffff93b0f890 ffff8806e3eff918
> [  787.900066]  ffffffff91f1cf26 1ffffffff3c2de73 ffffffff93b0f8a8 ffff8806e3eff938
> [  787.900066]  ffffffff91f1fb90 1ffffffff3c2de73 ffffffff93b0f8a8 ffff8806e3eff9f8
> [  787.900066] Call Trace:
> [  787.900066] dump_stack (lib/dump_stack.c:52)
> [  787.900066] ubsan_epilogue (lib/ubsan.c:159)
> [  787.900066] handle_overflow (lib/ubsan.c:191)
> [  787.900066] ? __do_page_fault (arch/x86/mm/fault.c:1220)
> [  787.900066] ? local_clock (kernel/sched/clock.c:392)
> [  787.900066] __ubsan_handle_mul_overflow (lib/ubsan.c:218)
> [  787.900066] select_task_rq_fair (kernel/sched/fair.c:4541 kernel/sched/fair.c:4755)
> [  787.900066] try_to_wake_up (kernel/sched/core.c:1415 kernel/sched/core.c:1724)
> [  787.900066] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:33)
> [  787.900066] default_wake_function (kernel/sched/core.c:2979)
> [  787.900066] ? get_parent_ip (kernel/sched/core.c:2559)
> [  787.900066] autoremove_wake_function (kernel/sched/wait.c:295)
> [  787.900066] ? get_parent_ip (kernel/sched/core.c:2559)
> [  787.900066] __wake_up_common (kernel/sched/wait.c:73)
> [  787.900066] __wake_up_sync_key (include/linux/spinlock.h:364 kernel/sched/wait.c:146)
> [  787.900066] pipe_write (fs/pipe.c:466)
> [  787.900066] ? kasan_poison_shadow (mm/kasan/kasan.c:48)
> [  787.900066] ? new_sync_read (fs/read_write.c:480)
> [  787.900066] do_iter_readv_writev (fs/read_write.c:681)
> [  787.900066] compat_do_readv_writev (fs/read_write.c:1029)
> [  787.900066] ? wait_for_partner (fs/pipe.c:340)
> [  787.900066] ? _raw_spin_unlock (./arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> [  787.900066] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [  787.900066] ? syscall_trace_enter_phase1 (include/linux/context_tracking.h:27 arch/x86/kernel/ptrace.c:1486)
> [  787.900066] compat_writev (fs/read_write.c:1145)
> [  787.900066] compat_SyS_writev (fs/read_write.c:1163 fs/read_write.c:1151)
> [  787.900066] ia32_do_call (arch/x86/ia32/ia32entry.S:446)
> [  787.900066] ================================================================================
> 
> The values for effective load seem a bit off (and are overflowing!).

It definitely looks like a bug in SMP load balancing!

> One change I did recently was to disable lock debugging, could it be related?

Should be unrelated to lock debugging, other than certain races 
will occur in different patterns with lock debugging on or off.

Thanks,

	Ingo