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 0E07BCD13CF for ; Mon, 2 Sep 2024 05:47:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 291FB8D0079; Mon, 2 Sep 2024 01:47:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 241DD8D002D; Mon, 2 Sep 2024 01:47:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10B668D0079; Mon, 2 Sep 2024 01:47:53 -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 DEC618D002D for ; Mon, 2 Sep 2024 01:47:52 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7218241965 for ; Mon, 2 Sep 2024 05:47:52 +0000 (UTC) X-FDA: 82518716784.24.FE97482 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by imf07.hostedemail.com (Postfix) with ESMTP id B454540005 for ; Mon, 2 Sep 2024 05:47:50 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IHkAYNDJ; spf=pass (imf07.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=laoar.shao@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=1725255997; 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=L/WIGvVQ42vNYGJNdFf3Oc9aHSeA4jiKtJQlg8xSf3w=; b=OPbK8yOXR8fF6YEI4nkLoVYOu+ik94vNkYaUfK8cqyVoPWF/2psKJVMoe0XwyaxN0SrzJM 9c3Pk/ibtExBNNDpIX+KtwXm3vrwAY3qkjlGAai9OOYMGOXDX37tM7pH4HOQbJIJYOqyGQ 55GhqU5AXO5L7glGRnE2n+EwJFiKyXc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IHkAYNDJ; spf=pass (imf07.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725255997; a=rsa-sha256; cv=none; b=XCtDmLfTeVQb4AQM0JmG56L3LrSj4x2C6/ON6K/1E6t5l/Zad4z4NnT4opLM0AliDbXpMl UuBjQzqOXgmRlcehr8b/m4A7OFaTJqRLcduThQjqZvelRPtFiPUDemrgFr29ui0+jAMsfw 2w3aNJa2pBxojHtb7M+lUJxlyMwCtB0= Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6c3567a143eso10161656d6.2 for ; Sun, 01 Sep 2024 22:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725256070; x=1725860870; 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=L/WIGvVQ42vNYGJNdFf3Oc9aHSeA4jiKtJQlg8xSf3w=; b=IHkAYNDJ7tOLqYKF30jvuQ6e1sfJVvzq5hxfP8peIfNNGYcHIpBZCIZzqoEfrSaN7q /z53aI4QXzZpksbNBjPjqT6Mlzr6vBANC8RYKai8lMWrhllLs59kZWrle6Y3AFM44U4j jpRVtzLhnX7M8m2zKoy/1z2TEFfu3VTqpaGPGcAUCN3Oe7tsbFJSZ7HQ21X5HGwEaQOj mDhnwTEaPp1NRYkn8lJTE+dmKCeeObCmDRqEikC1nMoQ3NSzQed4D4sxL2gegVfVuNuv nlSlWpMqW/lNBicInPsfKIM9PUXR9jTc08maQKXhdaIhDUqCIzwMGHiqIx/nm1Ondtik gzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725256070; x=1725860870; 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=L/WIGvVQ42vNYGJNdFf3Oc9aHSeA4jiKtJQlg8xSf3w=; b=eQqEUSkY1m08Y7D5HpoQNY5951pzKIf/spO+f+/+FoR0Yl1N2i0xvtdzdk3p5SaJ4/ 3WPk8Zx7l1u+Yht7Zwd+/UT8ioXIYOzs0QIEIeOrGBxjdbJGEPSXN5SnFiciv//meP8u ANzISuDUbOH3BYkw5LhpKulCNJc7lGmjgSjim1maiNHq5dG5ls3Cu1xkKH8R31qXtK9e rQV7Yot2q3cxc4Bf8l1CGlDiaf0HW0tV54OfzOR+XFHgTxI2yLyPwwVAt7f7wUK7Oahn e1nhyXnYonr7XDwDSQFDmbNPNZwx+4cyCZwjQRZDegZYAb6iB0SJ0uFVfW8UDw4Fjx7H iv2g== X-Forwarded-Encrypted: i=1; AJvYcCU9sQgYhy2ivHMIbksYRb1la5Fl9qUjsIyw6zlDd39YUhpn4DTnrls/x/jymu7jXImXTLFJaZ3H8w==@kvack.org X-Gm-Message-State: AOJu0YxegX6UUHl1Aqup85KY3FvpwYggGyYrFoHEK52kbB5xDEQWOqZt 1XqoOkwBilqG7Xa2C0NG6RR2WIz35yEPqB6movp9KWiU0KlyBwVdr1oU6rLrb301wngkDzh3MWk 4w72H/4MKRqBLczCm8bhr9kuc318= X-Google-Smtp-Source: AGHT+IH8h/peDYpdP4NKFa5wZZUVkjANuvU8ugP9rHzKGMtxZfDV+MPy1Hc1uEWSoB2fp58ia8x6fGds1P0k6PCU5Ik= X-Received: by 2002:a05:6214:2dc1:b0:6c3:657a:cbb9 with SMTP id 6a1803df08f44-6c3657acd86mr38481226d6.34.1725256069695; Sun, 01 Sep 2024 22:47:49 -0700 (PDT) MIME-Version: 1.0 References: <20240830202823.21478-1-21cnbao@gmail.com> <20240830202823.21478-4-21cnbao@gmail.com> In-Reply-To: From: Yafang Shao Date: Mon, 2 Sep 2024 13:47:13 +0800 Message-ID: Subject: Re: [PATCH v4 3/3] mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner To: Barry Song <21cnbao@gmail.com> 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: u8wsjaxh3iw9uqjxmragitdsktm8mebq X-Rspam-User: X-Rspamd-Queue-Id: B454540005 X-Rspamd-Server: rspam02 X-HE-Tag: 1725256070-25964 X-HE-Meta: U2FsdGVkX1/rDSV10j/aqvR41y/OWnH5xHaqQufVlo8mK3BsyN+RIzJAen+Wz8Ghv2kPCinuY0WQq+mlXy/hnb+rg1W/OtnqQTpmTuTiYNhNeyEOA9tSGpbVyN7N2MkbcfNI8kvs2SgVz7pvGJlwq/sJP68Cg5RFQ0iX2nqFDAVFdAPN4Z3WQUbKhyhsokGQ2fQFkAVNeWTvitCqoy76NmQpwdR2CsMNSGBjVk9+e9T9mrWLLt2tQ/WNJBzCuyhc0kTWHXrSlptkxvT1+/iMqkoztujX5yk+u0f8jq2fUbeigKRuFYA9WuJwjUZCsuYLixJbivv9JxI9gyhpR+EQH3Il8CxpG7cxWhSa6yE3pdYF1YgieVnTpjK28C8tEeba+VuJhinM499Qs9/FLfwbWDyKdbN4bDHqnAgwrU6pe8Zcqexo7xNSWHwVkfAJEYsxTaoUZY/Z4VWRPzw2S2YF4K6eXRpO7SWQOx+fo4mH54tK8fhLntgL4RePgkRmOigNXBWRp3X4pGhnXn3nGgYP5S4ortGsTMaWcz4Oq3uCgPxm3oS5ce4HSTNfzVH4AVO6CxizzeqfZkDOgjP92NqXXVx+yNj50x58q8z18JQu+4PK30Dli4/LwhqzZmCZOiUrFnumXCx0sP/78zCoQ15PbPSW+Rq+JHkbiAlHPW2nP0UJ4Z2Po9fZtHzuv+oPNTCCT8KFnl1g6rDH5mxa1s3B5HVjqy73HRK2TUXxx+KIZ/VTqWurh0HQ61if55CJBeJGP33/Vo/ZKMDrBmtgj6tcjTxH/q87HNBfn1cXTSlWeAB+hnvRSn/LFqpBk2Qxv9VeK+G+IItkfXnEHV32QnuM7Jle+6m8NHU/rtdW12UN5yVpYDVv3D3Efn4YDpvLEslmZNTrmNA7z86+3/lajEcRiEa6Hio9IDcdyomZdSm8nBxBCiZFE7DKzuCXZ4isjfpebdyRUYrWotBweniu8Z2 PZhWGnrt IHJ8cZGvWTOA10XK372czRTU9v47nB3OPmHpZoGuQU5Al8BNR/vDtTzytMKo4k46SO6/6g7dOOaIPKJk8BkJIVl3uCnl0lpIIhSS0S0XmmnCjUOrVmp21yPfko44fDoKIxYT02q8MuTnUPj8OYNaF0eUekFMubaekvoCgl10PLuRE8fJ541dawsw+MKyWFuiQw/4aDU5/LnhVUZALZOHIZnY9A6IryibdHcScEww+21TT/fuXCYBWLDtq7oA723dq8jZHaVeJ3vfaLs1GBkfAmbf5u/7gWVyNiIl1A/xYk2G0YMaZ2HulAVQt4MdpULazKfCQq7b6M905F8lhg5kSftPDcI4qAaGn6lDD8fzRdgauXae6Sl5IEeA1G/kpH+wjCIaML1CASFyCiRBxrutvWxRFa+d0EVnA/2XBwAVEXCtIzVDwBjhOjxoxzy2Sc/0Uh5x8lGRTBMGhN3p49hdeWSXegCplr4UwFFLEWaQ1iKj3w4pZvhWvFsf+rJ78RfwxBn2UU8n4+K4Pw1A= 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 12:00=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > On Mon, Sep 2, 2024 at 3:23=E2=80=AFPM Yafang Shao = wrote: > > > > On Sat, Aug 31, 2024 at 4:29=E2=80=AFAM Barry Song <21cnbao@gmail.com> = wrote: > > > > > > 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= in > > > 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_zo= ne, > > > { > > > 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= int 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, unsigne= d int order, > > > unsigned int zonelist_iter_cookie; > > > int reserve_flags; > > > > > > + if (unlikely(nofail)) { > > > + /* > > > + * We most definitely don't want callers attempting t= o > > > + * allocate greater than order-1 page units with __GF= P_NOFAIL. > > > + */ > > > + WARN_ON_ONCE(order > 1); > > > + /* > > > + * Also we don't support __GFP_NOFAIL without __GFP_D= IRECT_RECLAIM, > > > + * otherwise, we may result in lockup. > > > + */ > > > + WARN_ON_ONCE(!can_direct_reclaim); > > > + /* > > > + * PF_MEMALLOC request from this context is rather bi= zarre > > > + * because we cannot reclaim anything and only can lo= op 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. OK Thanks for your work. --=20 Regards Yafang