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

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 30 Jan 2019 09:18:20 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, Jan 29, 2019 at 6:54 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >
> > Then, do we automatically defer vfree() to mm_percpu_wq context?
> 
> We might do that, and say "if you call vfree with interrupts disabled,
> it gets deferred".
> 
> That said, the deferred case should generally not be a common case
> either. It has real issues, one of which is simply that particularly
> on 32-bit architectures we can run out of vmalloc space even normally,
> and if there are loads that do a lot of allocation and then deferred
> frees, that problem could become really bad.
> 
> So I'd almost be happier having a warning if we end up doing the TLB
> flush and defer. At least to find *what* people do.
> 
> And I do wonder if we should just always warn, and have that
> "might_sleep()", and simply say "if you do vfree from interrupts or
> with interrupts disabled, you really should be aware of these kinds of
> issues, and you really should *show* that you are aware by using
> vfree_atomic()".
> 

Agree.  if (irqs_disabled()) {warn_once; punt_to_workqueue} is the way
to go here.  vfree() should be callable from spinlocked code and
might_sleep() is an inappropriate check.