On Tue, Dec 16, 2014 at 12:29:28AM -0500, Sasha Levin wrote: > On 12/15/2014 08:14 AM, Peter Zijlstra wrote: > >>>> [ 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' > >> > > >> > So that's: > >> > > >> > this_eff_load *= this_load + > >> > effective_load(tg, this_cpu, weight, weight); > >> > > >> > Going by the numbers the 101500 must be 'this_eff_load', 100 * ~1024 > >> > makes that. Which makes the rhs 'large'. Do you have > >> > CONFIG_FAIR_GROUP_SCHED enabled? If so, what kind of cgroup hierarchy > >> > are you using? > >> > > >> > In any case, bit sad this doesn't have a register dump included :/ > > Hmm, I was hoping to be able to see if it was this_load or the > > effective_load() result being silly large, but going by the ASM output > > of my compiler this isn't going to be available in registers, its all > > stack spills. > > > > Pinning my hopes on that reproducability thing :/ > > Okay, yeah, it's very reproducible. I've added: >
Hi Sasha, I tried to reproduce this overflow, but got not luck (the trinity has been running in a KVM VM for an hour)... The trinity used is v1.4, and simply launched as ./trinity. Could you detail your setup and procedure? Thanks, Yuyang -- 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/
