lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <53CFC8C8.3070304@daenzer.net> Date: Wed, 23 Jul 2014 23:38:00 +0900 From: Michel Dänzer <michel@...nzer.net> To: Peter Zijlstra <peterz@...radead.org>, Dietmar Eggemann <dietmar.eggemann@....com> CC: Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...hat.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: Random panic in load_balance() with 3.16-rc 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists