linux-kernel - Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 17 Oct 2016 14:13:12 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        jiangshanlai@...il.com, akpm@...ux-foundation.org,
        kernel-team@...com,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue
 available early during boot)

Hello,

On Sat, Oct 15, 2016 at 08:48:01PM +1100, Michael Ellerman wrote:
> > Hmm... it doesn't reproduce it here and can't see how the commit would
> > affect this given that it doesn't really change when the kworker
> > kthreads are being created.
> 
> Try turning on CONFIG_DEBUG_PER_CPU_MAPS=y ?
> 
> That will warn if you're indexing off the end of a cpu mask and just
> getting lucky with the result.

That's not happening on x86.  That could mean that powerpc is
initializing cpu_possible_mask after workqueue_init_early().  Looking
into it.

> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at ../kernel/sched/core.c:1602 try_to_wake_up+0x3f4/0x5c0
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-compiler_gcc-6.2.0-next-20161014-dirty #116
> task: c000000ff9200000 task.stack: c000001ffc084000
> NIP: c0000000000f1ba4 LR: c0000000000f180c CTR: 0000000000000000
> REGS: c000001ffc0878f0 TRAP: 0700   Not tainted  (4.8.0-compiler_gcc-6.2.0-next-20161014-dirty)
> MSR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 28000422  XER: 00000000
> CFAR: c0000000000f18bc SOFTE: 0 
> GPR00: c0000000000f180c c000001ffc087b70 c000000000e83400 0000000000000000 
> GPR04: 0000000000000002 0000000000000000 0000000000000000 0000000000000000 
> GPR08: c000000000dc3400 0000000000000001 0000000000000002 0000000000000000 
> GPR12: 0000000000000000 c00000000fb80000 c00000000000e0c8 0000000000000000 
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 
> GPR20: 0000000000000000 0000000000000000 0000000000000000 c000000000eb8960 
> GPR24: 0000000000000000 c000000000d8ce00 0000000000000000 0000000000000000 
> GPR28: c0000007f54050f4 0000000000000000 0000000000000000 c0000007f5404900 
> NIP [c0000000000f1ba4] try_to_wake_up+0x3f4/0x5c0
> LR [c0000000000f180c] try_to_wake_up+0x5c/0x5c0
> Call Trace:
> [c000001ffc087b70] [c0000000000f180c] try_to_wake_up+0x5c/0x5c0 (unreliable)
> [c000001ffc087bf0] [c0000000000d53e4] create_worker+0x144/0x250
> [c000001ffc087c90] [c000000000cf7930] workqueue_init+0x170/0x19c
> [c000001ffc087d00] [c000000000ce0e74] kernel_init_freeable+0x158/0x360
> [c000001ffc087dc0] [c00000000000e0e4] kernel_init+0x24/0x160
> [c000001ffc087e30] [c00000000000bfa0] ret_from_kernel_thread+0x5c/0xbc
> Instruction dump:
> e8790890 4bff6ed9 2fa30000 419e00dc 60000000 4bfffe54 3d02fff4 8928d7f9 
> 2f890000 409e0018 39200001 9928d7f9 <0fe00000> 60000000 60420000 3b5f0368 
> ---[ end trace 0000000000000000 ]---
> 
> But I'm not sure that tells us anything new?

Yeah, I should have asked to print out information of the target task
but it looks like we have enough information now.

Thanks.

-- 
tejun