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?
