On Wed 05-04-17 13:42:19, Vlastimil Babka wrote: > On 03/30/2017 04:48 PM, Andrey Ryabinin wrote: [...] > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -737,7 +737,8 @@ static void free_vmap_area_noflush(struct vmap_area *va) > > /* After this point, we may free va at any time */ > > llist_add(&va->purge_list, &vmap_purge_list); > > > > - if (unlikely(nr_lazy > lazy_max_pages())) > > + if (unlikely(nr_lazy > lazy_max_pages()) && > > + !mutex_is_locked(&vmap_purge_lock)) > > So, isn't this racy? (and do we care?) yes, it is racy and no we do not care AFAICS. If the lock is held then somebody is already doing the work on our behalf. If we are unlucky and that work has been already consumed (read another lazy_max_pages have been freed) then we would still try to lazy free it during the allocation. This would be something for the changelog of course. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
