On Wed, Jul 23, 2014 at 12:02 PM, Peter Zijlstra <pet...@infradead.org> wrote:
>
> Here goes..
Oh. So this doesn't have CPUMASK_OFFSTACK set at all, so the pointer
has never been loaded from memory in the first place. The calculation
has been (for me) something like
movq $load_balance_mask, %rax
add %gs:this_cpu_off, %rax
and then gcc is being stupid and saving it to the frame and reloading
it for no good reason (at least for me it *also* saved the value in
%rbx in order to save it into "env.cpus", and the stack spill seems to
be just moronic).
In Michel's oops, %rbx doesn't contain the pointer any more, though,
so he clearly does have a different compiler. His frame offsets are
rather different too ("-136(%rbp)" vs "-168(%rbp)") so looking at
whether possibly some stack frame got overwritten is clearly very
compiler-specific.
Michel, mind doing
make kernel/sched/fair.s
and sending us the resulting file?
Linus
--
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/
