Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933983AbdC3RSz (ORCPT ); Thu, 30 Mar 2017 13:18:55 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:52493 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932582AbdC3RSy (ORCPT ); Thu, 30 Mar 2017 13:18:54 -0400 Date: Thu, 30 Mar 2017 10:18:46 -0700 From: Matthew Wilcox To: Andrey Ryabinin Cc: akpm@linux-foundation.org, penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org, mhocko@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, tglx@linutronix.de Subject: Re: [PATCH 4/4] mm/vmalloc: remove vfree_atomic() Message-ID: <20170330171845.GA19841@bombadil.infradead.org> References: <20170330102719.13119-1-aryabinin@virtuozzo.com> <20170330102719.13119-4-aryabinin@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170330102719.13119-4-aryabinin@virtuozzo.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 898 Lines: 27 On Thu, Mar 30, 2017 at 01:27:19PM +0300, Andrey Ryabinin wrote: > vfree() can be used in any atomic context and there is no > vfree_atomic() callers left, so let's remove it. We might still get warnings though. > @@ -1588,9 +1556,11 @@ void vfree(const void *addr) > > if (!addr) > return; > - if (unlikely(in_interrupt())) > - __vfree_deferred(addr); > - else > + if (unlikely(in_interrupt())) { > + struct vfree_deferred *p = this_cpu_ptr(&vfree_deferred); > + if (llist_add((struct llist_node *)addr, &p->list)) > + schedule_work(&p->wq); > + } else > __vunmap(addr, 1); > } > EXPORT_SYMBOL(vfree); If I disable preemption, then call vfree(), in_interrupt() will not be true (I've only incremented preempt_count()), then __vunmap() calls remove_vm_area() which calls might_sleep(), which will warn. So I think this check needs to change from in_interrupt() to in_atomic().