Re: [PATCH] mm: fix sleeping function warning in alloc_swap_info

[Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>]

Andrew Morton wrote:
> > change. But I think that we converted kmalloc() to kvmalloc() without checking
> > context of kvfree() callers. Therefore, I think that kvfree() needs to use
> > vfree_atomic() rather than just saying "vfree() might sleep if called not in
> > interrupt context."...
> 
> Whereabouts in the vfree() path can the kernel sleep?

Indeed. Although __vunmap() must not be called from interrupt context because
mutex_trylock()/mutex_unlock() from try_purge_vmap_area_lazy() from
free_vmap_area_noflush() from free_unmap_vmap_area() from remove_vm_area() from
__vunmap() cannot be called from interrupt context, it seems that there is no
location that does sleeping operation.

Linus Torvalds wrote:
> Which - as mentioned - is fine because we currently don't actually do
> the TLB flush synchronously, but it's worth noting again. "vfree()"
> really is a *lot* different from "kfree()". It's unsafe in all kinds
> of special ways, and the locking difference is just part of it.
> 
> So whatever might_sleep() has found might be a potential real issue at
> some point...

Then, do we automatically defer vfree() to mm_percpu_wq context?