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 0269CC3DA61 for ; Wed, 24 Jul 2024 11:58:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 670626B008A; Wed, 24 Jul 2024 07:58:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61FEC6B008C; Wed, 24 Jul 2024 07:58:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E77A6B0093; Wed, 24 Jul 2024 07:58:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 30F446B008A for ; Wed, 24 Jul 2024 07:58:16 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A30561A08CE for ; Wed, 24 Jul 2024 11:58:15 +0000 (UTC) X-FDA: 82374498150.12.B2F78D9 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf25.hostedemail.com (Postfix) with ESMTP id AE701A000A for ; Wed, 24 Jul 2024 11:58:12 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="A/si64+F"; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721822270; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=96LiP4EJKTbJ9zW7jWWaw9Mt26G4l1eFWQe0YZezUgo=; b=FYqTon/rUijLCYrZm7DNGqdb8nqOHWCb3HLuij6aKCaayNJf/o5mLlRj6R9XcCN8YuKZmJ P675k2T/t+ZSiWcTFyiWlgD/Hggl+NoEw28btzUqPi6EiqaN0ckzTGPFhDS+fyx6NgBQxZ NOI+gZ14zKcpnVO0TgpCTwnaaYzln6s= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="A/si64+F"; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721822270; a=rsa-sha256; cv=none; b=hABauHwRcEUVRYs80A1Hm+QxFVbSVoQS1zzGJsw59ihLCw1klCyKFxguTaRgZT+OK0NtcP Kw9K6pMvs+3d4F7639xX4mRIW9LBx2esku/WE35r9yGJhICuGTQRLepgvB19RdDaLin/m4 sLO521QTvnGEOuTsfb5xRqv8jWtyP4o= Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a7a83a968ddso202290566b.0 for ; Wed, 24 Jul 2024 04:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721822291; x=1722427091; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=96LiP4EJKTbJ9zW7jWWaw9Mt26G4l1eFWQe0YZezUgo=; b=A/si64+FlmjoVU054HKcoErdbO8mEq62M3h2aeEisynshz9YLifAOQ2DmLZY50OE1S v4xUHtCaYf3efIdMZz/BsBHqJ2FXpkYVywiPbyrPWDUGh+i1KmN+3xd/WTsgvuOtRqua nNG4EhePeOfIGmAoXruK8H1H8CzLvcqOizttRH8VpFD29/wnXHHFmV/bu/CKN7mXoT2n oUFe7D9GbA6gK+HosGsh5iElZAwH2P1qBRsB5YjXpkcFOgpK7W4FI0G6RmVYP59dS/i8 FgckhXk8FyZiREqpX0BiOv0EBeZIhPqPux+fBDdKpgmDYXeZljJuRnYfzpWA9IvzBSWu UEUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721822291; x=1722427091; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=96LiP4EJKTbJ9zW7jWWaw9Mt26G4l1eFWQe0YZezUgo=; b=bznXdYncVTFm09YEtBV/TkRckC4XQn/RoS+/fGOli7FHy2tJ3SG4+Kq4NwxOc3OV0b t/Xj1YbNnQ6D85WQtQ60nzaHJN74/P2fZz9IcA/8sVhnCFfX3QEXU53PRY7CAXTsPEQ8 KTW+d7Ouq79fFRo0ITpQ0dwJ9ymy9ciCFfI2f0BdlADpk5ACngnwhzjAGQ0iuC2wQ8gr 3fxM6btjnn+pMJaAqRMIHMzCqeXRh3NvBpplgJ0WbQ9amQPzeRJuKn1MmMSybrHxhg7A figJhQg4by0KvovEJfgCoGp+spnCrXhdFJIOgthvKMnJGMKcGN2efkoI1Buq+iNK0j6P TBug== X-Forwarded-Encrypted: i=1; AJvYcCWsMPE6D5GnpCz6nrDGOTR0EyGOoUrwXZDM/iLgpvXihu7IUbgvMj3nE3CqEO7uk7lkbXJD80MJQ4+xdH2JFLUkXxM= X-Gm-Message-State: AOJu0YwCehhLxsUf53hwzV8JNYkqECPDpZYiyteJ9pjnpbcGCJM4jM2F 7EOJGK3mLKcZI1jq37SwVb75qzw/nxNOXHKLWsRdtmTRN87ig2/Iq/Hl0RulV1g= X-Google-Smtp-Source: AGHT+IHvmNN4dfiaiUDQcItBMdEPOzv0avhX3W76e+XHKZ1xVDZEPV+rLot70dQKgkRZ3N8l9bDrvw== X-Received: by 2002:a17:907:980a:b0:a7a:bd5a:1eb7 with SMTP id a640c23a62f3a-a7abd5a1fbcmr40793666b.59.1721822290912; Wed, 24 Jul 2024 04:58:10 -0700 (PDT) Received: from localhost (109-81-94-157.rct.o2.cz. [109.81.94.157]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7ab999db8esm33348766b.184.2024.07.24.04.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jul 2024 04:58:10 -0700 (PDT) Date: Wed, 24 Jul 2024 13:58:09 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org, iamjoonsoo.kim@lge.com, lstoakes@gmail.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, hailong.liu@oppo.com, torvalds@linux-foundation.org Subject: Re: [PATCH 2/5] mm: Document __GFP_NOFAIL must be blockable Message-ID: References: <20240724085544.299090-1-21cnbao@gmail.com> <20240724085544.299090-3-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240724085544.299090-3-21cnbao@gmail.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: AE701A000A X-Stat-Signature: 1hamcue9nfjoigq4armam3tzg49nfyty X-HE-Tag: 1721822292-736984 X-HE-Meta: U2FsdGVkX195hd6OlcaZHE2WgxtoyrPQDh/Ic26GHGEL+Zbygkr+HbUJubjKcpGL8VxfQWg+qHSy4LLdmtfy0wsWSEzt08i7I3JtiX3U4nn/l+/3AHbf3Ih3rIBvxxhqzxI+jri9nfS6AKRKNO0xMjnCm8O7eQAKNB2KEd/jHmxUwJeWQDh8x/ILXcyY8VEA0NL97yOxBUoVSX3YJRJDvqcYwA0LBgIYucAA/d7qxKyF3UIhv5Rjl/bdWAPo8AKyN/YQy8H9fzpWS4GLll2YeE8S6UFBSSL4P+IpB50+V9Pwr+ZmQUAGlrMqK2QWgxXTgMIa1fqvPh8aT8yBr8qilhUL8vi9/KF+CUvR5x6A/4zwo4cr3OijPilMavDwmDNt+48+cKjV66RiVewgnjmFUf7agb4JaOVVEpZVNGoqxb/7EHzrNzE/UGO7tGoWSjwv+hbV0+dTWhOlXPNnQ3BohjQZprrBT/l6Pm8blMIrZOpx0ehPiL417eJjJdOS38aarhm27TZ/FyCDyC8vbERxT9JRlXoMFJ6XzmF86KPYdRyx5YkNYnU8PFsYnOY9su8zd/F1ePz0JNwVADr/cvi4dJm4GaO1vWTdL4Z3diAM/qOd6zp0Hcgbv5xAf2krRleU71LWiQ+oZ2z/DzoxPG6HT8fq251hKXEonKriPcyYhkh96Za6cOOvlwG4lpEAw8lc9ZPDSrHqPL/5dKREL8rzRkdYnQumZkHTSJ6ucPP6qnv/dFw2acVo49EfHn+tLe2Y+JB82V2ZbGAIut5x8I4tBh7NohMzPtG/0CIbsY3bSp1F5EeLfoi9zo1pQ1PJHru4Ns9HIai21Mp6cBB3x+HFLpxr8i5Yn9PjcHdG/sVa6z73Rzi0boBbIrCxPGWO9lY9U/Yo4Q25iYz7XiUxhGThDbKvNY7QdJS5qx522x0S+i9E3BshMptikO7tjj76DbQyAh8Z3nz8qNlZ1aePvyE 1dHPgvwD K5+dEao04N6GHzm7/3gQBoPo0QwKAEIYhkNQA9HA9htGeUzkKeQHqDi0vrwka1DaJwWAMtd5EkuRDYLSEwPFz/sopOCUWQBxqsjaGHrDtWwEnnuGUqAbkB8n5eQJjySZ9CUtMWjCu01GVFznnsoBbVggJp+1t03cGvoIf2aqS1pd+qCvQK13R0hkb/S45+qFyATTCr+nAPJcrU2nRj71k8Kbf1KTKFQBifavyreUNYIoozkroO1kDH6tRdBA0nNfG8DjISRP3jxPuoJHs2ACzhQYWWzw4ERTkgaO31k5aShceHfFmDCGtDG6l6LYbbbo7IhpW2YTWPAgz6joxZcBgjasYBjxt/7mOW9usOyD4DCiELO1vooYHwhAkliOkQP+uFxYvfFp/d33CLUl/OEYd+j7fAgWVnWi1VQclZi3v37EaIY3vAjdyPa9gEAAzBVckRSMT8Ibeqk6onTxCsyfKK+nAcfaB0LRj2yv34Jv8AaZVpm6dF4GrHqoXSJXky+OKrTHV04Mwv0+DVBY= 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 Wed 24-07-24 20:55:41, Barry Song wrote: > From: Barry Song > > Non-blocking allocation with __GFP_NOFAIL is not supported and may > still result in NULL pointers (if we don't return NULL, we result > in busy-loop within non-sleepable contexts): > > static inline struct page * > __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > struct alloc_context *ac) > { > ... > /* > * Make sure that __GFP_NOFAIL request doesn't leak out and make sure > * we always retry > */ > if (gfp_mask & __GFP_NOFAIL) { > /* > * All existing users of the __GFP_NOFAIL are blockable, so warn > * of any new users that actually require GFP_NOWAIT > */ > if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask)) > goto fail; > ... > } > ... > fail: > warn_alloc(gfp_mask, ac->nodemask, > "page allocation failure: order:%u", order); > got_pg: > return page; > } > > Highlight this in the documentation of __GFP_NOFAIL so that non-mm > subsystems can reject any illegal usage of __GFP_NOFAIL with > GFP_ATOMIC, GFP_NOWAIT, etc. > > Signed-off-by: Barry Song Acked-by: Michal Hocko > --- > include/linux/gfp_types.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h > index 313be4ad79fd..0dad2c7914be 100644 > --- a/include/linux/gfp_types.h > +++ b/include/linux/gfp_types.h > @@ -246,6 +246,8 @@ enum { > * cannot handle allocation failures. The allocation could block > * indefinitely but will never return with failure. Testing for > * failure is pointless. > + * It _must_ be blockable and used together with __GFP_DIRECT_RECLAIM. > + * It should _never_ be used in non-sleepable contexts. > * New users should be evaluated carefully (and the flag should be > * used only when there is no reasonable failure policy) but it is > * definitely preferable to use the flag rather than opencode endless > -- > 2.34.1 Do you think the following addendum should be folded in just for completness? diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h index 313be4ad79fd..d024cfd1af8e 100644 --- a/include/linux/gfp_types.h +++ b/include/linux/gfp_types.h @@ -215,7 +215,8 @@ enum { * the caller still has to check for failures) while costly requests try to be * not disruptive and back off even without invoking the OOM killer. * The following three modifiers might be used to override some of these - * implicit rules. + * implicit rules. Please note that all of them must be used along with + * %__GFP_DIRECT_RECLAIM flag. * * %__GFP_NORETRY: The VM implementation will try only very lightweight * memory direct reclaim to get some memory under memory pressure (thus -- Michal Hocko SUSE Labs