From mboxrd@z Thu Jan 1 00:00:00 1970 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 D8844C433F5 for ; Wed, 11 May 2022 02:32:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 686DC6B0071; Tue, 10 May 2022 22:32:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 636276B0072; Tue, 10 May 2022 22:32:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FE266B0073; Tue, 10 May 2022 22:32:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3E79F6B0071 for ; Tue, 10 May 2022 22:32:18 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 1660781CD4 for ; Wed, 11 May 2022 02:32:18 +0000 (UTC) X-FDA: 79451887956.13.E1DD6A9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 01136100092 for ; Wed, 11 May 2022 02:31:59 +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 094B061652; Wed, 11 May 2022 02:32:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26FACC385D8; Wed, 11 May 2022 02:32:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1652236336; bh=/Hp6dU5hclTkoExV1aXWnjWD+RcFFs7kpZHwfwv6wEk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=o8RU/4GYhn7UPYgYuI1ACj0GMtmWe15Z9yy8qhGLuCOojJ817oL44x7KTrsCqd15i HBSah0TyT99EjnD+fwvU5YclqKzLpJ7u4tiz6S2/R8DMA1Wckeo4YKmpbsJ/Ox/Vlv Shy2mseOIgOs9IHx+HO0yWs9B+eo7WkAod8q9qs0= Date: Tue, 10 May 2022 19:32:15 -0700 From: Andrew Morton To: Qi Zheng Cc: akinobu.mita@gmail.com, vbabka@suse.cz, gregkh@linuxfoundation.org, jirislaby@kernel.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/2] mm: fix missing handler for __GFP_NOWARN Message-Id: <20220510193215.14ed7e3fb70857738e10c0a2@linux-foundation.org> In-Reply-To: References: <20220510113809.80626-1-zhengqi.arch@bytedance.com> <20220510115922.350a496ca8b91686c1758282@linux-foundation.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: fcia7aqs9jz3fy578ujwocsxji7z4bi4 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 01136100092 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="o8RU/4GY"; spf=pass (imf05.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-Rspam-User: X-HE-Tag: 1652236319-267495 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: On Wed, 11 May 2022 10:19:48 +0800 Qi Zheng wrote: > > ,,, > >> --- a/mm/internal.h > >> +++ b/mm/internal.h > >> @@ -35,6 +35,17 @@ struct folio_batch; > >> /* Do not use these with a slab allocator */ > >> #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK) > >> > >> +#define WARN_ON_ONCE_GFP(cond, gfp) ({ \ > >> + static bool __section(".data.once") __warned; \ > >> + int __ret_warn_once = !!(cond); \ > >> + \ > >> + if (unlikely(!(gfp & __GFP_NOWARN) && __ret_warn_once && !__warned)) { \ > >> + __warned = true; \ > >> + WARN_ON(1); \ > >> + } \ > >> + unlikely(__ret_warn_once); \ > >> +}) > > > > I don't think WARN_ON_ONCE_GFP is a good name for this. But > > WARN_ON_ONCE_IF_NOT_GFP_NOWARN is too long :( > > > > WARN_ON_ONCE_NOWARN might be better. No strong opinion here, really. > > I've thought about WARN_ON_ONCE_NOWARN, but I feel a little weird > putting 'WARN' and 'NOWARN' together, how about WARN_ON_ONCE_IF_ALLOWED? I dunno. WARN_ON_ONCE_GFP isn't too bad I suppose. Add a comment over the definition explaining it? > > > >> @@ -4902,8 +4906,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > >> * We also sanity check to catch abuse of atomic reserves being used by > >> * callers that are not in atomic context. > >> */ > >> - if (WARN_ON_ONCE((gfp_mask & (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)) == > >> - (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM))) > >> + if (WARN_ON_ONCE_GFP((gfp_mask & (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)) == > >> + (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM), gfp_mask)) > >> gfp_mask &= ~__GFP_ATOMIC; > >> > >> retry_cpuset: > > > > I dropped this hunk - Neil's "mm: discard __GFP_ATOMIC" > > (https://lkml.kernel.org/r/163712397076.13692.4727608274002939094@noble.neil.brown.name) > > deleted this code. > > > > This series is based on v5.18-rc5, I will rebase it to the latest next > branch and check if there are any missing WARN_ON_ONCEs that are not > being handled. Against git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm branch mm-unstable, please. That ends up in linux-next, with a delay.