[lkml]   [2017]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context
On Thu 30-03-17 15:22:29, Andrew Morton wrote:
> On Thu, 30 Mar 2017 13:27:16 +0300 Andrey Ryabinin <> 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

 \ /
  Last update: 2017-04-04 11:38    [W:0.205 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site