On Mon, Nov 6, 2017 at 2:01 PM, Ido Schimmel <ido...@idosch.org> wrote: > On Mon, Nov 06, 2017 at 03:56:54PM -0500, valdis.kletni...@vt.edu wrote: >> I've hit this 6 times now, across 3 boots: >> >> Nov 3 11:04:54 turing-police kernel: [ 547.814748] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> >> Nov 3 20:24:11 turing-police kernel: [ 60.093793] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> Nov 4 20:20:54 turing-police kernel: [86264.366955] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> Nov 5 19:17:40 turing-police kernel: [172469.769179] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> Nov 6 06:07:37 turing-police kernel: [211467.239460] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> >> Nov 6 14:12:43 turing-police kernel: [ 54.891848] BUG: sleeping function >> called from invalid context at mm/slab.h:422 >> >> Something seems to be going astray while handling a RA packet. >> >> Kernel dirty due to hand-patching >> https://patchwork.kernel.org/patch/10003555/ >> (signed int:1 bitfield in sched.h causing tons of warnings) >> >> Unfortunately, the previous next- kernel I built was -20170927 (which worked >> OK). >> >> Googling for things in the traceback in the last month comes up empty, and >> only >> thing in the git log for net/ipv6 that looks vaguely related: >> >> commit f3d9832e56c48e4ca50bab0457e21bcaade4536d >> Author: David Ahern <dsah...@gmail.com> >> Date: Wed Oct 18 09:56:52 2017 -0700 >> >> ipv6: addrconf: cleanup locking in ipv6_add_addr > > Probably right... > > [...] > >> [ 54.891848] BUG: sleeping function called from invalid context at >> mm/slab.h:422 >> [ 54.891855] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0 >> [ 54.891859] INFO: lockdep is turned off. >> [ 54.891867] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W OE >> 4.14.0-rc7-next-20171102-dirty #537 >> [ 54.891872] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A20 >> 05/08/2017 >> [ 54.891877] Call Trace: >> [ 54.891882] <IRQ> >> [ 54.891894] dump_stack+0x7b/0xe4 >> [ 54.891907] ___might_sleep+0x1b0/0x300 >> [ 54.891921] kmem_cache_alloc_trace+0x2c7/0x500 >> [ 54.891931] ? cyc2ns_read_end+0x1e/0x30 >> [ 54.891944] ipv6_add_addr+0x15a/0xc30 >> [ 54.891977] ? ipv6_create_tempaddr+0x2ea/0x5d0 >> [ 54.891986] ipv6_create_tempaddr+0x2ea/0x5d0 > > This function is called from softirq so we should call ipv6_add_addr() > with 'can_block' set to 'false'. > > DavidA, it's already late here so you can probably fix this before I > take a closer look tomorrow morning. :)
I have a patch, will send in a couple of minutes. Thanks.
