linux-kernel - Re: Random panic in load

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140723113021.GP12054@laptop.lan>
Date:	Wed, 23 Jul 2014 13:30:21 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Dietmar Eggemann <dietmar.eggemann@....com>
Cc:	Michel Dänzer <michel@...nzer.net>,
	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 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.

--
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/