Re: Random panic in load_balance() with 3.16-rc

From: Michel Dänzer
Date: Wed Jul 23 2014 - 10:38:16 EST


On 23.07.2014 23:24, Peter Zijlstra wrote:
> On Wed, Jul 23, 2014 at 01:30:21PM +0200, Peter Zijlstra wrote:
>> On Wed, Jul 23, 2014 at 01:11:10PM +0200, Peter Zijlstra wrote:
>>> On Wed, Jul 23, 2014 at 10:45:46AM +0100, Dietmar Eggemann wrote:
>>>> Doesn't the picture showing the captured panic reveal more information.
>>>> Haven't seen it myself, I just saw Peter's reply to your email
>>>
>>> Its a general protection fault from somewhere in load_balance(), I send
>>> you the picture.
>>>
>>> It would help to get addr2line of the RIP I suppose.
>>>
>>> Michel provided a config, so lemme go try and build that, maybe my gcc
>>> will generate similar code to his and the function offset is enough
>>> clue.
>>
>> So the code section says the faulting instruction is:
>>
>> f3 a5
>>
>> followed by:
>>
>> 48 89 c7 85 50 ff ff
>>
>> or so.
>>
>> My compiled code is 'different', the function is shorter, but there's a
>> f3 a5 somewhere not too far short of +d7 at +a8. I have (objdump -SD):
>>
>> 35a8: f3 a5 rep movsl %ds:(%rsi),%es:(%rdi)
>>
>> for_each_cpu_and(i, sched_group_cpus(group), env->cpus) {
>> unsigned long capacity, capacity_factor, wl;
>> enum fbq_type rt;
>>
>> rq = cpu_rq(i);
>> 35aa: 48 c7 c1 00 00 00 00 mov $0x0,%rcx
>>
>> And that's the only part that could possibly match.
>>
>> That looks like the start of find_busiest_queue(). I'm not entirely sure
>> what the rep movsl is operating on, lemme try and figure that out.
>
> Ah, this appears to be load_balance()'s:
>
> cpumask_copy(cpus, cpu_active_mask);

Right, according to addr2line it's the memcpy in bitmap_copy().


> Which totally doesn't make sense, both src and dst are static storage.
> Dst is the most interesting since its per-cpu storage, but still.
>
> No way either of those should generate a #GP. Puzzled.

Could it be the memcpy length being off or something like that?


--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/