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.