Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755786AbcJUAcZ (ORCPT ); Thu, 20 Oct 2016 20:32:25 -0400 Received: from mail-lf0-f53.google.com ([209.85.215.53]:33341 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbcJUAcW (ORCPT ); Thu, 20 Oct 2016 20:32:22 -0400 MIME-Version: 1.0 In-Reply-To: <20161019163112.GA31091@lst.de> References: <1476773771-11470-1-git-send-email-hch@lst.de> <1476773771-11470-3-git-send-email-hch@lst.de> <20161019111541.GQ29358@nuc-i3427.alporthouse.com> <20161019130552.GB5876@lst.de> <20161019163112.GA31091@lst.de> From: Joel Fernandes Date: Thu, 20 Oct 2016 17:32:19 -0700 Message-ID: Subject: Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping To: Christoph Hellwig Cc: Andy Lutomirski , Chris Wilson , Andrew Morton , Jisheng Zhang , John Dias , "linux-mm@kvack.org" , linux-rt-users@vger.kernel.org, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1070 Lines: 33 Hi Christoph, On Wed, Oct 19, 2016 at 9:31 AM, Christoph Hellwig wrote: > On Wed, Oct 19, 2016 at 08:34:40AM -0700, Andy Lutomirski wrote: >> >> It would be quite awkward for a task stack to get freed from a >> sleepable context, because the obvious sleepable context is the task >> itself, and it still needs its stack. This was true even in the old >> regime when task stacks were freed from RCU context. >> >> But vfree has a magic automatic deferral mechanism. Couldn't you make >> the non-deferred case might_sleep()? > > But it's only magic from interrupt context.. > > Chris, does this patch make virtually mapped stack work for you again? > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index f2481cb..942e02d 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1533,7 +1533,7 @@ void vfree(const void *addr) > > if (!addr) > return; > - if (unlikely(in_interrupt())) { > + if (in_interrupt() || in_atomic()) { in_atomic() also checks in_interrupt() cases so only in_atomic() should suffice. Thanks, Joel