On Mon, Nov 6, 2017 at 2:01 PM, Ido Schimmel <[email protected]> wrote:
> On Mon, Nov 06, 2017 at 03:56:54PM -0500, [email protected] 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 <[email protected]>
>> 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.
From 1583358476770134845@xxx Mon Nov 06 22:45:12 +0000 2017
X-GM-THRID: 1583358272438904088
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Mon, Nov 6, 2017 at 2:04 PM, Eric Dumazet <[email protected]> wrote:
> I have a patch, will send in a couple of minutes. Thanks.
https://patchwork.ozlabs.org/patch/834983/ ipv6: addrconf: fix a lockdep splat
From 1583358300276551104@xxx Mon Nov 06 22:42:24 +0000 2017
X-GM-THRID: 1583358272438904088
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread