On Thu 30-03-17 15:22:29, Andrew Morton wrote: > On Thu, 30 Mar 2017 13:27:16 +0300 Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> wrote: [...] > > This can be fixed in vmgfx, but it would be better to make vfree() > > non-sleeping again because we may have other bugs like this one. > > I tend to disagree: adding yet another schedule_work() introduces > additional overhead and adds some risk of ENOMEM errors which wouldn't > occur with a synchronous free. I do not think ENOMEM would be a problem. We are talking about lazy handling already. Besides that the allocation path also does this lazy free AFAICS. > > __purge_vmap_area_lazy() is the only function in the vfree() path that > > wants to be able to sleep. So it make sense to schedule > > __purge_vmap_area_lazy() via schedule_work() so it runs only in sleepable > > context. > > vfree() already does > > if (unlikely(in_interrupt())) > __vfree_deferred(addr); > > so it seems silly to introduce another defer-to-kernel-thread thing > when we already have one. But this only cares about the IRQ context and this patch aims at atomic context in general. I agree it would have been better to reduce this deferred behavior to only _atomic_ context but we not have a reliable way to detect that on non-preemptive kernels AFAIR. -- Michal Hocko SUSE Labs