On 2019/01/30 4:13, Andrew Morton wrote: > 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! > If I recall correctly, there was an attempt to allow vfree() to sleep but that attempt failed, and the change to allow vfree() to sleep was reverted. Thus, vfree() had been "Context: Any context except NMI.". If we want to allow vfree() to sleep, at least we need to test with kvmalloc() == vmalloc() (i.e. force kvmalloc()/kvfree() users to use vmalloc()/vfree() path). For now, reverting the "Context: Either preemptible task context or not-NMI interrupt." change will be needed for stable kernels.
