On Tue, 29 Jan 2019 20:43:20 +0900 Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > On 2019/01/29 16:21, Jiufei Xue wrote: > > Trinity reports BUG: > > > > sleeping function called from invalid context at mm/vmalloc.c:1477 > > in_atomic(): 1, irqs_disabled(): 0, pid: 12269, name: trinity-c1 > > > > [ 2748.573460] Call Trace: > > [ 2748.575935] dump_stack+0x91/0xeb > > [ 2748.578512] ___might_sleep+0x21c/0x250 > > [ 2748.581090] remove_vm_area+0x1d/0x90 > > [ 2748.583637] __vunmap+0x76/0x100 > > [ 2748.586120] __se_sys_swapon+0xb9a/0x1220 > > [ 2748.598973] do_syscall_64+0x60/0x210 > > [ 2748.601439] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > This is triggered by calling kvfree() inside spinlock() section in > > function alloc_swap_info(). > > Fix this by moving the kvfree() after spin_unlock(). > > > > Excuse me? But isn't kvfree() safe to be called with spinlock held? Yes, I'm having trouble spotting where kvfree() can sleep. Perhaps it *used* to sleep on mutex_lock(vmap_purge_lock), but try_purge_vmap_area_lazy() is using mutex_trylock(). Confused. kvfree() darn well *shouldn't* sleep!
