From patchwork Fri Jan 14 22:07:11 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12714103 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BFD5FC433EF for ; Fri, 14 Jan 2022 22:07:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5348F6B011B; Fri, 14 Jan 2022 17:07:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E54E6B011D; Fri, 14 Jan 2022 17:07:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AB976B011E; Fri, 14 Jan 2022 17:07:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 2733A6B011B for ; Fri, 14 Jan 2022 17:07:14 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E130B98C03 for ; Fri, 14 Jan 2022 22:07:13 +0000 (UTC) X-FDA: 79030279146.17.BDEF02F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id 50422160004 for ; Fri, 14 Jan 2022 22:07:13 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9F54662011; Fri, 14 Jan 2022 22:07:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FBD8C36AED; Fri, 14 Jan 2022 22:07:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1642198032; bh=GQEP01sTsyUivJvV23Ywfkcnu0Wj9586sffJkfCEypg=; h=Date:From:To:Subject:In-Reply-To:From; b=suHldoq+aVi67LkoPuPNMGgo+CsjKGB1bjP3Y2BytubngNtVwrJA4nylCPdGeZuAO EVNRTEmv7bSEodCIXArl/0fD8iCQzt8wtE5/oI+MMK3Kh/COSD11fDAYg9iEOXmqxj hBC/PePUcjIriTnQAJgXag9Z8pC1iWJsPs9daPnE= Date: Fri, 14 Jan 2022 14:07:11 -0800 From: Andrew Morton To: akpm@linux-foundation.org, bigeasy@linutronix.de, david@fromorbit.com, dchinner@redhat.com, hch@lst.de, idryomov@gmail.com, jlayton@kernel.org, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, neilb@suse.de, torvalds@linux-foundation.org, urezki@gmail.com, vbabka@suse.cz Subject: [patch 077/146] mm: make slab and vmalloc allocators __GFP_NOLOCKDEP aware Message-ID: <20220114220711.IJjDTpdMu%akpm@linux-foundation.org> In-Reply-To: <20220114140222.6b14f0061194d3200000c52d@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Queue-Id: 50422160004 X-Stat-Signature: xyomc81sa65rrfyfnzgbxjaeddkx4ay8 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=suHldoq+; spf=pass (imf08.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam07 X-HE-Tag: 1642198033-371349 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Michal Hocko Subject: mm: make slab and vmalloc allocators __GFP_NOLOCKDEP aware sl?b and vmalloc allocators reduce the given gfp mask for their internal needs. For that they use GFP_RECLAIM_MASK to preserve the reclaim behavior and constrains. __GFP_NOLOCKDEP is not a part of that mask because it doesn't really control the reclaim behavior strictly speaking. On the other hand it tells the underlying page allocator to disable reclaim recursion detection so arguably it should be part of the mask. Having __GFP_NOLOCKDEP in the mask will not alter the behavior in any form so this change is safe pretty much by definition. It also adds a support for this flag to SL?B and vmalloc allocators which will in turn allow its use to kvmalloc as well. A lack of the support has been noticed recently in http://lkml.kernel.org/r/20211119225435.GZ449541@dread.disaster.area Link: https://lkml.kernel.org/r/YZ9XtLY4AEjVuiEI@dhcp22.suse.cz Signed-off-by: Michal Hocko Reported-by: Sebastian Andrzej Siewior Acked-by: Dave Chinner Acked-by: Vlastimil Babka Cc: Christoph Hellwig Cc: Dave Chinner Cc: Ilya Dryomov Cc: Jeff Layton Cc: Neil Brown Cc: Uladzislau Rezki (Sony) Signed-off-by: Andrew Morton --- mm/internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/internal.h~mm-make-slab-and-vmalloc-allocators-__gfp_nolockdep-aware +++ a/mm/internal.h @@ -21,7 +21,7 @@ #define GFP_RECLAIM_MASK (__GFP_RECLAIM|__GFP_HIGH|__GFP_IO|__GFP_FS|\ __GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_NOFAIL|\ __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC|\ - __GFP_ATOMIC) + __GFP_ATOMIC|__GFP_NOLOCKDEP) /* The GFP flags allowed during early boot */ #define GFP_BOOT_MASK (__GFP_BITS_MASK & ~(__GFP_RECLAIM|__GFP_IO|__GFP_FS))