Received: by 10.192.165.148 with SMTP id m20csp5034823imm; Tue, 24 Apr 2018 12:31:06 -0700 (PDT) X-Google-Smtp-Source: AIpwx49XAzBeftUkdW2AHCTle4X8roTOc9eRlHH/91mXF6MYJ9d3p3GeF9BNyiCQU/l5GhS9MhMH X-Received: by 2002:a17:902:8505:: with SMTP id bj5-v6mr12426872plb.211.1524598266762; Tue, 24 Apr 2018 12:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524598266; cv=none; d=google.com; s=arc-20160816; b=sH9eXwRYdWx+hGA3VFCkb7mMGzISE3RFGW51/1X5b2fiaQg3+1autUwP2TJtbIpUQ+ bxkupRqEwR3Uy1q0SqKHJM3yOvnoSr5Y4UwDUGJfe8NJNSwnRqry4qVSBVWfkX3+DlDa mbiaIGQQeZwMlcT0mK8VOKBkYVlaMlikO/mvRjZk83FcK5f5wV3uCrJQ+1wse3jmpMtG 0mm23jfJiphQN8/TYU/qPBcI5MvlaGZnU6haTiQubvvbIa/NXIKJAb76RRuieAlKk0by AVu8odnibXbvBHMGUopUAQgVbAR73mnnu/rRTtOIBJevnubqkLOQkw8R22q/YXT1tgWb vBFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=rFNJMvalPp5IZgRHZk8/60ZH7b21KYFAIfH68u8OdXo=; b=MEl49YtlQ5j0isAuZHeo2XeyCNlSVovRPf/DgQ9PLZXALJuUW0EXgNeCxDVlZcRVJy AxTg2PxmE0hv9dZ3KraaebyvtXr0XejaeZZ4DP5Gc423e6zK6debLQC4WZc9rMt+PHAV q36fJdCU8Dk/FUUZiu1mCz1cVJw8k5CPKYwzIYiVAFUgJ7CbPilVOKy6dm6mCAVNSDDr eQH/PgfR4eF4qWai39QajeBlXp7rvtNmYEBS2+KrNTGhVXK57Dg6iLiCvK9EE5Zd0xyG hcAuUkFbDJKmjQ3AuHuL+IpjP7ZwWQL5ZTmSgi9n0ReKSeh/5wNz+dyhO4oHH8KnC9n8 g/gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m2si8940553pgm.360.2018.04.24.12.30.52; Tue, 24 Apr 2018 12:31:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642AbeDXT2L (ORCPT + 99 others); Tue, 24 Apr 2018 15:28:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:53983 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751483AbeDXT2I (ORCPT ); Tue, 24 Apr 2018 15:28:08 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 52B57AD45; Tue, 24 Apr 2018 19:28:06 +0000 (UTC) Date: Tue, 24 Apr 2018 13:28:03 -0600 From: Michal Hocko To: Richard Weinberger Cc: LKML , Artem Bityutskiy , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Cyrille Pitchen , Theodore Ts'o , Andreas Dilger , Steven Whitehouse , Bob Peterson , Trond Myklebust , Anna Schumaker , Adrian Hunter , Philippe Ombredanne , Kate Stewart , Mikulas Patocka , linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: vmalloc with GFP_NOFS Message-ID: <20180424192803.GT17484@dhcp22.suse.cz> References: <20180424162712.GL17484@dhcp22.suse.cz> <3732370.1623zxSvNg@blindfold> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3732370.1623zxSvNg@blindfold> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 24-04-18 21:03:43, Richard Weinberger wrote: > Am Dienstag, 24. April 2018, 18:27:12 CEST schrieb Michal Hocko: > > fs/ubifs/debug.c > > This one is just for debugging. > So, preallocating + locking would not hurt much. > > > fs/ubifs/lprops.c > > Ditto. > > > fs/ubifs/lpt_commit.c > > Here we use it also only in debugging mode and in one case for > fatal error reporting. > No hot paths. > > > fs/ubifs/orphan.c > > Also only for debugging. > Getting rid of vmalloc with GFP_NOFS in UBIFS is no big problem. > I can prepare a patch. Cool! Anyway, if UBIFS has some reclaim recursion critical sections in general it would be really great to have them documented and that is where the scope api is really handy. Just add the scope and document what is the recursion issue. This will help people reading the code as well. Ideally there shouldn't be any explicit GFP_NOFS in the code. Thanks for a quick turnaround. -- Michal Hocko SUSE Labs