On Tue, Jan 29, 2019 at 5:11 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Again, this is not about sleeping. But the end result is almost the
> same: we really should strive to not do vfree() in interrupt context.
Note that we currently test the wrong thing for this: we actually
check "in_interrupt()" for the deferred case, which certainly works in
practice, and protects from deadlocks (we need vmap_area_lock for the
free-area handling)
But it doesn't actually end up testing the "oops, interrupts are
disabled in process context" issue. The "might_sleep()" check _does_
check that, iirc.
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...
Linus
