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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170405121449.GO6035@dhcp22.suse.cz>
Date:   Wed, 5 Apr 2017 14:14:49 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        akpm@...ux-foundation.org, penguin-kernel@...ove.SAKURA.ne.jp,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, hpa@...or.com,
        chris@...is-wilson.co.uk, hch@....de, mingo@...e.hu,
        jszhang@...vell.com, joelaf@...gle.com, joaodias@...gle.com,
        willy@...radead.org, tglx@...utronix.de, stable@...r.kernel.org
Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context

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