Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

From	Michal Hocko <mhocko@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context
Date	2017-04-05 14:20 +0200
Message-ID	<tsS4O-2vv-7@gated-at.bofh.it> (permalink)
References	<tqLTQ-1a6-25@gated-at.bofh.it> <tstg6-33o-3@gated-at.bofh.it> <tstg6-33o-5@gated-at.bofh.it> <tsRBL-25z-13@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context Vlastimil Babka <vbabka@suse.cz> - 2017-04-05 13:50 +0200
  Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context Michal Hocko <mhocko@kernel.org> - 2017-04-05 14:20 +0200

csiph-web