Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755427AbdDEMPI (ORCPT ); Wed, 5 Apr 2017 08:15:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:56354 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754002AbdDEMOz (ORCPT ); Wed, 5 Apr 2017 08:14:55 -0400 Date: Wed, 5 Apr 2017 14:14:49 +0200 From: Michal Hocko To: Vlastimil Babka Cc: Andrey Ryabinin , Thomas Hellstrom , akpm@linux-foundation.org, penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com, chris@chris-wilson.co.uk, hch@lst.de, mingo@elte.hu, jszhang@marvell.com, joelaf@google.com, joaodias@google.com, willy@infradead.org, tglx@linutronix.de, stable@vger.kernel.org Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context Message-ID: <20170405121449.GO6035@dhcp22.suse.cz> References: <20170330102719.13119-1-aryabinin@virtuozzo.com> <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> <8d313f6c-9ea8-7be0-38cd-15370e5a1d6c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d313f6c-9ea8-7be0-38cd-15370e5a1d6c@suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 903 Lines: 23 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