BUG: sleeping function called from invalid context - seen with UML

[John Stultz]

I'm trying to run UML with recent upstream kernels, and I've been
seeing the following BUG trigger over and over:

BUG: sleeping function called from invalid context at mm/slab.h:393
in_atomic(): 0, irqs_disabled(): 1, pid: 0, name: swapper
CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.7.0-09120-ge48af7a #794
Stack:
 603e1d20 60069689 600976ea 6002fb08
 00000000 00000000 603e1d30 601c6336
 603e1d80 60058225 603e1d60 603e4e50
Call Trace:
 [<600976ea>] ? printk+0x0/0x94
 [<6001d345>] show_stack+0xfe/0x158
 [<60069689>] ? dump_stack_print_info+0xe1/0xea
 [<600976ea>] ? printk+0x0/0x94
 [<6002fb08>] ? get_signals+0x0/0xf
 [<601c6336>] dump_stack+0x2a/0x2c
 [<60058225>] ___might_sleep+0x181/0x18c
 [<60058307>] __might_sleep+0xd7/0xe2
 [<60069fa1>] ? handle_irq_event+0x56/0x6a
 [<600cf35f>] __kmalloc+0x5a/0x121
 [<6001bc10>] uml_kmalloc+0x13/0x15
 [<6002e19d>] __wrap_malloc+0x3f/0x71
 [<6002fa46>] sig_handler_common+0x3e/0x100
 [<6002fa08>] ? sig_handler_common+0x0/0x100
 [<6002f944>] ? block_signals+0x0/0x16
 [<600976ea>] ? printk+0x0/0x94
 [<6002f9c5>] unblock_signals+0x6b/0xae
 [<601cc073>] ? strlen+0x0/0x16
 [<6001c35b>] arch_cpu_idle+0x53/0x5a
 [<601cc073>] ? strlen+0x0/0x16
 [<6006029d>] default_idle_call+0x32/0x34
 [<6007db99>] ? tick_nohz_idle_enter+0x75/0x77
 [<60060353>] cpu_startup_entry+0xb4/0x11d
 [<6006009e>] ? complete+0x0/0x5a
 [<600382ec>] ? kernel_thread+0x0/0x2d
 [<600382ec>] ? kernel_thread+0x0/0x2d
 [<602fe646>] rest_init+0xa7/0xae
 [<6002fb08>] ? get_signals+0x0/0xf
 [<6002fb08>] ? get_signals+0x0/0xf
 [<60001bc0>] start_kernel+0x529/0x538
 [<60003626>] start_kernel_proc+0x49/0x4d
 [<600660b8>] ? kmsg_dump_register+0x84/0x93
 [<6001bf03>] new_thread_handler+0x81/0xa3
 [<600035db>] ? kmsg_dumper_stdout_init+0x1a/0x1c
 [<6001ee17>] uml_finishsetup+0x54/0x59



I tried to bisect it down, and it apparently popped up in the v4.7
merge window, with the following commit:

b6024b21fec8 ("um: extend fpstate to _xstate to support YMM
registers") which adds a malloc call to the sig_handler


Unfortunately just reverting that patch against v4.7 doesn't work, as
I then hit:

This architecture does not have kernel memory protection.
Registers -
        0       0x2
        1       0x0
        2       0x0
        3       0x0
        4       0x0
        5       0x0
        6       0x0
        7       0x0
        8       0x0
        9       0x0
        10      0x0
        11      0x0
        12      0x0
        13      0x0
        14      0x0
        15      0x0
        16      0x10007b
        17      0x0
        18      0x0
        19      0x0
        20      0x0
        21      0x0
        22      0x0
        23      0x0
        24      0x0
        25      0x0
        26      0x0
Kernel panic - not syncing: do_syscall_stub : PTRACE_SETREGS failed, errno = 5

CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-00001-g0a9f717 #795
Stack:
 80455be0 60068d01 601ce033 60373c73
 807928f0 60096cdf 80455bf0 601c4109
 80455d10 600960cd 00002458 807928f0
Call Trace:
 [<60096cdf>] ? printk+0x0/0x94
 [<6001d345>] show_stack+0xfe/0x158
 [<60068d01>] ? dump_stack_print_info+0xe1/0xea
 [<601ce033>] ? bust_spinlocks+0x0/0x4f
 [<60096cdf>] ? printk+0x0/0x94
 [<601c4109>] dump_stack+0x2a/0x2c
 [<600960cd>] panic+0x163/0x2f0
 [<60095f6a>] ? panic+0x0/0x2f0
 [<60096cdf>] ? printk+0x0/0x94
 [<60096cdf>] ? printk+0x0/0x94
 [<60057bb9>] ? __might_sleep+0xd7/0xe2
 [<6003191a>] run_syscall_stub+0x145/0x2d4
 [<60096cdf>] ? printk+0x0/0x94
 [<600cda05>] ? kmem_cache_alloc+0x0/0xff
 [<6003302e>] write_ldt_entry+0x84/0x8f
 [<60033298>] init_new_ldt+0x25f/0x350
 [<600cda05>] ? kmem_cache_alloc+0x0/0xff
 [<6001f165>] init_new_context+0x102/0x14e
 [<6009fa4a>] ? __get_free_pages+0x1c/0x5a
 [<60063cc9>] ? __raw_spin_lock_init+0x0/0x1e
 [<600359bf>] mm_init+0x1cc/0x211
 [<600cdad3>] ? kmem_cache_alloc+0xce/0xff
 [<60035e73>] mm_alloc+0x62/0x6d
 [<600da275>] do_execveat_common+0x2b3/0x65e
 [<600da641>] do_execve+0x21/0x23
 [<6001a6d8>] run_init_process+0x3b/0x3f
 [<6001a69d>] ? run_init_process+0x0/0x3f
 [<60096cdf>] ? printk+0x0/0x94
 [<602f9b5c>] kernel_init+0xbf/0x156
 [<6001bf03>] new_thread_handler+0x81/0xa3


Any thoughts on how to get around this?

thanks
-john