On Wed, 30 Jan 2019 09:18:20 -0800 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Jan 29, 2019 at 6:54 PM Tetsuo Handa
> <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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.
