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 EE8C5CA0ED3 for ; Mon, 2 Sep 2024 04:00:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FDB48D006C; Mon, 2 Sep 2024 00:00:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2ADED8D002D; Mon, 2 Sep 2024 00:00:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14F128D006C; Mon, 2 Sep 2024 00:00:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EA02A8D002D for ; Mon, 2 Sep 2024 00:00:50 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 93AAD1419A4 for ; Mon, 2 Sep 2024 04:00:50 +0000 (UTC) X-FDA: 82518447060.15.1DC2243 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf20.hostedemail.com (Postfix) with ESMTP id C9F701C0018 for ; Mon, 2 Sep 2024 04:00:48 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="U/Dyqx1p"; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725249601; a=rsa-sha256; cv=none; b=2kNsEjnlPivVMIZq0CsCVSwbcgDtJBJq+z7s0MvKOmsF+3mdK0IPVpyETULcHCF3InsG1y K1/OeJjdiMv3M0siyESNlCukBawyX12hMXlsUIw6c+ox8wpdasUxxfNnrD4eVq7TanLWG4 /9/NITJEqincIMKvbMBmHesX6+/Q8aU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="U/Dyqx1p"; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725249601; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jmDB7V2FAlLppJcv6qEB74wU6sInJM9aiR+Q1vjKiCc=; b=v8aZwPyfL20X9y4Hm9a9TspmDInUl8MXTQF+kx3FUxX+heRRb/UBhFXX6dV4Kwen4G8sRr AB7buPoCSQA4fF5WJllfX2ddFryAKZOPRMpoMItigqeqKW7XwPrOqNc/aydrxpUxhN6QHf KkkjBt7QrmTiIGuSbOIhlg5t4IkM5LY= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-498dbd7dc89so1023354137.1 for ; Sun, 01 Sep 2024 21:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725249648; x=1725854448; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jmDB7V2FAlLppJcv6qEB74wU6sInJM9aiR+Q1vjKiCc=; b=U/Dyqx1pPnO4z1cLUlPuPsB85r+lT5Dut3J7qUwsvKVmfGOM7yPlBVP36ES4ixS3RH NBlzG1hr+tut3jIYUiq217i6TEWwpy/rmMv8vV1r4gPqOTx6RBKRzFGL/f/pMCgSF9QQ 3xsB9Mf5Iryx4kJFvNaTHJJrf6oTtxQQ2k0RFx1Yel9A2fjRdOwtJUJ16/Z4PPDII6cM Su3WvbexWH6+GIg6CS/VFb07vsfXVef8AzVtnM4p/YkFuik/erKHNuHbuT1bAa+O5EvB Zt/tgKw4sGUyNnFaVldjKEMdJSyV83W+XSOaNRx8tt2uehHenZWd8yHwCbn6enZs7FGE BqZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725249648; x=1725854448; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jmDB7V2FAlLppJcv6qEB74wU6sInJM9aiR+Q1vjKiCc=; b=GytSKJIJKhx+jIYPtVlNA7dWDKwU0rE7QpHkOIinXFW8XaIHs4jxvuFYYOKgxsHuov QKgUVn6lc7KxIpWiU119EvyVmTdkboG1zJljm67cwTMZULY6yktLcAzjWzKyqGao6sGL aB/YPeJXDqVGGckD34SP2r2hgp1aicq2XW13EXn6vSHGY3YJGb16i8jjLpPfGiN65rJL O9EKbs2IVB7BhLSdvT+F3VbG1/5ThCO3EhCRqKrygOz0Bl+/HUtDOAbyT8jGFxbaEgJE N1WVOUHDGR+sO3AKpDZG4qsgfD2lmtPFK3/dDSKyAqVkj/8bXSl6GlAzgtJN2KDepvrE 0rWw== X-Forwarded-Encrypted: i=1; AJvYcCXhpKrEoO+qGcnRCiX/spMlFzJXzAzsKGOcXREbCyBtb2cGC0B7UCyzEc0ZFwG1PJEkdaKwLnYnuA==@kvack.org X-Gm-Message-State: AOJu0YwzrbqcZtCidwGx93oPTPpEoh39+gVrhrsJtJu2oG5M1BQ4tZnp dohs87VZRctaRVQVUHK+tFBPsl941ecZ8+cpq/8J2vUSCQy0M7XMwrCm27Gbb1DlBAPhNGaXAyq U8k2rPUpLC+uPT1VnpPi6NIQ63DI= X-Google-Smtp-Source: AGHT+IHcq8/uECWUpxFQ8vHMJBMh+xl0lDhReLp2jQiO2kwJXnwdTQuwwl+JZEev+2M1ZKM3xHuXJ1pGGPfwswIq7Uw= X-Received: by 2002:a05:6102:3909:b0:498:e7fc:d273 with SMTP id ada2fe7eead31-49a779b9db0mr3923783137.18.1725249647656; Sun, 01 Sep 2024 21:00:47 -0700 (PDT) MIME-Version: 1.0 References: <20240830202823.21478-1-21cnbao@gmail.com> <20240830202823.21478-4-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 2 Sep 2024 16:00:36 +1200 Message-ID: Subject: Re: [PATCH v4 3/3] mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner To: Yafang Shao Cc: akpm@linux-foundation.org, linux-mm@kvack.org, virtualization@lists.linux.dev, david@redhat.com, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, mhocko@suse.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, torvalds@linux-foundation.org, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 1ygmbf7smrjxsh94pp5cn4hg5jsjrugz X-Rspamd-Queue-Id: C9F701C0018 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725249648-192063 X-HE-Meta: U2FsdGVkX18PbfdQvq98wNjLzhFNueqR09nRYselJJSy6j7J2+Pb1vhwWv+P5kE2tIixdGHvcyPTWYBUf2OpXzFAUG67dGDqq9BroRWLFU13HGZtk+bLD2Yxk3q49g62gHYzpjUIE90YfJsBBSGMo7V/YmZ2cAoAZu6NVADTWHW8+OD71AlCLYl2oZzBHSE3SMaMCa8b9CpL3xxo+4pPbm/1hx3U6mDDiXNpyuGVRiosi5E9i5kj7O2tJr7beZE/T3gy6aUAaDzwSXiCsshpwAWsgacUFfEhFs7AzLKB6cob52PPwojKeMR0w3ARhZppIeGyZLjrmqJStLEGBe8h0jVvpViYzb0HhpR85DMi/ZDMlghsfrF6RB4g6sMlaLUWmdlmcfVWPnih3bgJYUrKqq9wkzJypJ3WTWQ8jfU13rCDMe6udwrxAVNX7Aa65oVzS5HiKd8uecTVJrEjXfXE5pjb9C6VAm9iIiPqvReyoJVCvxgXHqth4JfF/n1nffyTcfPxPXJn5tQKWqrGST7UWanvNE7OkEtEBI83jEMWSQak4X8vWKVPrA3XjiLg7LS2QP/IoQOMjyQmK1yUEseEwiSbH56jrV+45m+AH6wc3LkFdt9xH4+i0C8C7FlchmN0lFAyo8oPREW+1KBuffOnT+Wn0g6zbqGC0quvVtrtC9JJS/o6/Red79eZmcdJ2C4Vy/TmL07RBzAkasDRclvQtumVnnex+s5mY/KSTS8BCLSd1eUrBCreDG71yA777JklcoAh0EwgXEL1S7ppD/W7zC7mn2oU+p0ADJxO2Bm64IynnuPNaJycTIlzFzFNIeTUqawxrhXGDgndJM7M59f+JR3xUskkCVke+FOV6OASxFscrFgIPQe0zXp13iNWiFAbDY/hAgTiE6+7YGjBscUP1bzR5ZSU4u8+YqVfauoOf/TRpjaCsfPBB+QsLBfxzOYJ0HIZZrQZ/8duHXUC4hy /rviy9cF uKQz3QX79ZkK631mgRj2VUxx/NIzLpzfaTsti2CAkRgHxZEpp1HtNOScei+AqpQAm5D2A+DlRMTt1rQHyItwekhbfDXPZrb1eRmOstcF9lUs4ffZIJsJMKP0drLPvXo6JBzZUgmam3BwIxVfdFWJshisqpRLoVX+iu/U7h4jQv8jW1kaffybHJIPle6bPOvNegdbmmASo4SarKomiSngdcLZMzGZNH1me9qkX1ghTuW1XI44Ip+rpHxZgfmFrXaIvSXv8lgPKOdDddVGHAJgU8sLgb/plzVlOr6Z0rwWAt6XE4HK6p4QfodIepQFSAyQCTUEnhGRDUD3+/liKelWArCfIoB0AIBoe6aZUdFkT3tfrrxVFaWPcxjPc0FSc/IheG01ytk6drFAYK2xtFQpmEapqw2pBtKVLOPxMFRHF0T1VGNC21j5LksX9Cn+J0Q0xoZ1jDpjLAKnsfHF6qnMBsalsjj+OOpDT8cw6DEmkdmgqB8U= 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: List-Subscribe: List-Unsubscribe: On Mon, Sep 2, 2024 at 3:23=E2=80=AFPM Yafang Shao w= rote: > > On Sat, Aug 31, 2024 at 4:29=E2=80=AFAM Barry Song <21cnbao@gmail.com> wr= ote: > > > > From: Barry Song > > > > Three points for this change: > > > > 1. We should consolidate all warnings in one place. Currently, the > > order > 1 warning is in the hotpath, while others are in less > > likely scenarios. Moving all warnings to the slowpath will reduce > > the overhead for order > 1 and increase the visibility of other > > warnings. > > > > 2. We currently have two warnings for order: one for order > 1 in > > the hotpath and another for order > costly_order in the laziest > > path. I suggest standardizing on order > 1 since it=E2=80=99s been i= n > > use for a long time. > > > > 3. We don't need to check for __GFP_NOWARN in this case. __GFP_NOWARN > > is meant to suppress allocation failure reports, but here we're > > dealing with bug detection, not allocation failures. So replace > > WARN_ON_ONCE_GFP by WARN_ON_ONCE. > > > > Suggested-by: Vlastimil Babka > > Signed-off-by: Barry Song > > --- > > mm/page_alloc.c | 50 ++++++++++++++++++++++++------------------------- > > 1 file changed, 25 insertions(+), 25 deletions(-) > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index c81ee5662cc7..e790b4227322 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -3033,12 +3033,6 @@ struct page *rmqueue(struct zone *preferred_zone= , > > { > > struct page *page; > > > > - /* > > - * We most definitely don't want callers attempting to > > - * allocate greater than order-1 page units with __GFP_NOFAIL. > > - */ > > - WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); > > - > > if (likely(pcp_allowed_order(order))) { > > page =3D rmqueue_pcplist(preferred_zone, zone, order, > > migratetype, alloc_flags); > > @@ -4175,6 +4169,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned i= nt order, > > { > > bool can_direct_reclaim =3D gfp_mask & __GFP_DIRECT_RECLAIM; > > bool can_compact =3D gfp_compaction_allowed(gfp_mask); > > + bool nofail =3D gfp_mask & __GFP_NOFAIL; > > const bool costly_order =3D order > PAGE_ALLOC_COSTLY_ORDER; > > struct page *page =3D NULL; > > unsigned int alloc_flags; > > @@ -4187,6 +4182,25 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned = int order, > > unsigned int zonelist_iter_cookie; > > int reserve_flags; > > > > + if (unlikely(nofail)) { > > + /* > > + * We most definitely don't want callers attempting to > > + * allocate greater than order-1 page units with __GFP_= NOFAIL. > > + */ > > + WARN_ON_ONCE(order > 1); > > + /* > > + * Also we don't support __GFP_NOFAIL without __GFP_DIR= ECT_RECLAIM, > > + * otherwise, we may result in lockup. > > + */ > > + WARN_ON_ONCE(!can_direct_reclaim); > > + /* > > + * PF_MEMALLOC request from this context is rather biza= rre > > + * because we cannot reclaim anything and only can loop= waiting > > + * for somebody to do a work for us. > > + */ > > + WARN_ON_ONCE(current->flags & PF_MEMALLOC); > > I believe we should add below warning as well: > > WARN_ON_ONCE(gfp_mask & __GFP_NOMEMALLOC); > WARN_ON_ONCE(gfp_mask & __GFP_NORETRY); > WARN_ON_ONCE(gfp_mask & __GFP_RETRY_MAYFAIL); > ... > > I'm not sure if that is enough. > __GFP_NOFAIL is a really horrible thing. Thanks! I'd prefer to keep this patchset focused on the existing warnings and bugs. Any new warnings about size limits or checks for new flags can be addressed separately. > > -- > Regards > Yafang Thanks Barry