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 0F3E4C3DA61 for ; Thu, 25 Jul 2024 01:48:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53A236B0099; Wed, 24 Jul 2024 21:48:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E8D26B009A; Wed, 24 Jul 2024 21:48:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 389A46B009B; Wed, 24 Jul 2024 21:48:09 -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 136A46B0099 for ; Wed, 24 Jul 2024 21:48:09 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8A361A03F2 for ; Thu, 25 Jul 2024 01:48:08 +0000 (UTC) X-FDA: 82376589456.24.B6BE6DF Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf08.hostedemail.com (Postfix) with ESMTP id BB258160006 for ; Thu, 25 Jul 2024 01:48:06 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="YRlwa/1s"; spf=pass (imf08.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 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=1721872062; a=rsa-sha256; cv=none; b=KJY95sv9XJ2pOneraANvsJPAG39pjOGY2/hoCj7ePFMxPXcAnee8vC5vl00cfBv4dWpBqt ylgKvHmN9Zq2oTv330VQ9VvYPIwRvB9ZX8dZxoJFwvpgDQ/CLRCJPE5FJQk7Os2UPYzaJF 4sRvXbjvZgloi0eus9s4bOoRShLFcTI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="YRlwa/1s"; spf=pass (imf08.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 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=1721872062; 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=TISFjCqvandFb9l351oDaL6jIFz+5C7OojJnJeVMoXE=; b=QA49bkdFIz13vsyQgZFr7vBxbcSyof/TGLHr0Qtg3CirTQO/fHtkE5oYQ25ky8sr0jCcdD XX/sdkQdSb7NFFINQosmKzfSLIW412Dw0Vg1zFG6d/4IduQtMyZVyTuUfwuCSIxIUkKVTV 75SKg1Uzw5wLYIT8K2v7Ehab45MEEms= Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-821b8d887b8so109919241.2 for ; Wed, 24 Jul 2024 18:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721872086; x=1722476886; 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=TISFjCqvandFb9l351oDaL6jIFz+5C7OojJnJeVMoXE=; b=YRlwa/1sk244YVCRnKn58QedZSjPo9ASHFoybJAw0+Z8+JMv7ZOfnx/u+8+mGUAuL4 A5NF2H/QwYBPc8VqWBkUrpvftU50Gbz/S5Yc83h63017JauW47nkKEYijeDhrDSvgbM6 B5cvmen1ibJVP2bvNcn0VjgJbyA51W2WnJ6+With2/1OCfEIiQng7Ptu4lQ/mTfSY+ae GzYm7lypIO6+GRCQUzHjxod6Bw1SR3yE5X5AwS1BYY/n4ohxH4KMjODYLLhfpQGvSOuY crdDDXBYXb0PLzWAa4uDYw6la5eOQOTNNrD5DWGU5gYtes60gNEjAmumIgCCnmddUnKZ s37g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721872086; x=1722476886; 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=TISFjCqvandFb9l351oDaL6jIFz+5C7OojJnJeVMoXE=; b=sROKbYxdWPZ6bmFDRVqm0gIsDvy4qjCFmhCz43AnqRz+3JFJ1GpunkrGatN63+jCcA FS+pFX/F9mcCdQJ4UiZnHvl+SW+VdqyU4xAzhU/NhFoT3o4YHV05blc6Rob0KIVHPC7s B4LZ46JX3sVH5PkaFfVO0YDeGCEvV3hrf6QwOoC+VN9wzylcRxLgxx4+M2nkwqe2kX25 T1/ZWHNKRFD+ilx2EuXnLKcawStWEKj32aWjxLSCBTNm6YkymWjrJvU4hbcKCWjZGLYm Gmxs7hqZ/zK/u2/RYlevMLvjvhlGgMcZ1L0ZPaOwWkY5x0+TG6d9lhHZx55f8dKotsyt aG8Q== X-Forwarded-Encrypted: i=1; AJvYcCUVnk+uthY1vkesn/hVxMz44BZrFZDaC6GfKNN218aLmG/7omndgwbcJL1MQaHH47yDXfICinfOYjIjqflxYEXcozU= X-Gm-Message-State: AOJu0Yw8VYXh7p5j8+TpVXoDazSAfYp1VMd9qlxVj2+fheWVlETHPA6X jSwBQ9hiQZgmGE9KiQKORbvIMVhppNLJEo7s/UIQ1ghB2x9jo0JF3nNx3N1SdE2Ns5njwIct8Bn 6pTUyoFmjCApaky3Y0pl2N0UOpS0= X-Google-Smtp-Source: AGHT+IGnt0v7dMKqRjnb6iJ80FuPWryyNCKzTEWXwsAqV0zENb8OwCcXTOgpXmDrXJOFxglPQy21A45C0sscYDe+Qck= X-Received: by 2002:a05:6102:160f:b0:48f:96a8:fa33 with SMTP id ada2fe7eead31-493d63d3448mr1688152137.11.1721872085752; Wed, 24 Jul 2024 18:48:05 -0700 (PDT) MIME-Version: 1.0 References: <68ee812b-3b96-4c8b-9a54-70d4742488bb@suse.cz> <400b2f6f-f7f0-4888-99ee-7327faad7e5c@suse.cz> <5b9fa06a-bcef-447c-899b-fe3fb10315bf@suse.cz> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 25 Jul 2024 13:47:54 +1200 Message-ID: Subject: Re: [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL To: Christoph Hellwig Cc: Vlastimil Babka , Michal Hocko , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, iamjoonsoo.kim@lge.com, lstoakes@gmail.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, virtualization@lists.linux.dev, hailong.liu@oppo.com, torvalds@linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: b49kf7mgkpqg5br4res9ggmj8t6k4ttp X-Rspamd-Queue-Id: BB258160006 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1721872086-918733 X-HE-Meta: U2FsdGVkX1/j0KvTxpejXzaX5bJUe9Yoa4jf9veG6kE0IY1L8NEPAUbfvvOL5ekDVzN68m4wnCIJi9KV+Iv21C2JCbQJ0j196sv7LExKqExJj/bxQIezZSt32ZITBOYgOJScXLlDRK905a8onJ66A5XVy4QdxfGtARohCSoxVR3tQvlFCPfPjmipkDdTJVX0mvQ0GAxpgnyBaWpaJkno6KcqF/qDkDlJyQGCNeTOCijemcGn941+58+O0r4MaIgC7Hz6XlPYdrJ9E/9R3yYt6nWtrdT1TJAHPwDB13PEBKrrXi7rfYYIexvBOXnoW5nwk3NhXE9s0UY/BprMHf5xkbmZYjwnn6m8ZnF7QYHwWO/ifwukBZ3fn9RoQ527X/6pNLygM7cV790T2rniOgW4UObLX0CMUpXC38gLTwFAr389bfwfp1P+WgoAz9BItYnS4pRkYddf1IFwZnBc9z4Y5BP3BN4EQ40u2g+QPvhSxqUi0csrGgkjV9Ro7tu6FKdmIfQPRObozHBSp66DSTQssSWo0z3YhGZyVa9swGDh/cpjg9cZwRF0W78rPEg2A5WEW/cUHaycuNiXLGJoUSUJIdgm7Qc0o4Ncl/yYVdZw7zA+m16HThGXTdPCbF4Qn7DQGsnfE1F5hXoScMJybeeCbjjpWLAWnD73IQMpayxpMYlvr2TIt/n5uWewqn3CdqNuIFuO20XikTLZSKjvRBds+C1Lwk+pmmgtgVaLIqzK9c2PDNJIDjLTtOdBaBlcmxkabdXueKIYDmZ+YivOAb6sB9/jepoX7fD4uN4YJSDpkkcqMB/kYFBPLYBdZJ0EV7JX7x2NIRiyP/KQnQCnYHg2GG7ZUd0kgZn04EwXk0bVsYYw+GZEDrCO3Y92nbJFCjDBffVa8OIfNW74AsGD+uThDQK1f5KIWiaogvp59WqM1XVLu0VoAglH8QTwz0k/XKeYGmUIzUxA3ihTGAq9aSp GxlwP+ZO sCc/uHS1+VBJJFcO4UABDA6cThT1P4v1h2jT99ZYU0iyfrrWE4KHybD7UHDBwqNciTOv6pcCgOQQMoq6jiL6E30+YD/9h29elbo6d6x9kiL5qpjP0GjoA3EvOG0dzSiLGNgbrK1L1Ymt5sao3a7sIlDux87SxbRQ61BhO2xxrQO2fBPB6g0IDdpbwjDaWS9C5+TKFS2i/b/Q2vHZ6s8vYgKI93wSzVAyPSOQekFwUNDbLOtFAwZ60ua00gUzhK1UY0QLSf4hCu97ZCCO0rlM+FIGzp93Z2bnG/JdZDbrBoSAA+WGgnY1V+cTRR9QoyHvilmbCtGsenLmwFkyr+3GL9EllV9rNjBQ/xFi6q+T80nTe66ZzZqiQ+K8IwCxhh9SnoQxZVP2iZVKq956+qaFjds0g2Prj62BuL63T53SOh/oKf+dcTGxxhoNzixZhK0lytnekIEB56/xLJxfKtbV3loMraWQOsYwmC/pJ 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 Thu, Jul 25, 2024 at 2:41=E2=80=AFAM Christoph Hellwig wrote: > > On Wed, Jul 24, 2024 at 04:39:11PM +0200, Vlastimil Babka wrote: > > On 7/24/24 3:55 PM, Christoph Hellwig wrote: > > > On Wed, Jul 24, 2024 at 03:47:46PM +0200, Michal Hocko wrote: > > >> OK, now it makes more sense ;) I have absolutely no objections to > > >> prefering scoped NO{FS,IO} interfaces of course. And that would inde= ed > > >> eliminate a need for defining GFP_NO{FS,IO}_NOFAIL alternatives. > > > > > > Yes. My proposal would be: > > > > > > GFP_NOFAIL without any modifiers it the only valid nofail API. > > > > Where GFP_NOFAIL is GFP_KERNEL | __GFP_NOFAIL (and not the more limited= one > > as defined in patch 4/5). > > Yes. > > > > File systems / drivers can combine =D1=96t with the scoped nofs/noio = if > > > needed. > > > > Sounds good, how quickly we can convert existing __GFP_NOFAIL users rem= ains > > to be seen... > > I took a quick look at the file system ones and they look pretty easy. I > think it would be good to a quick scriped run for everything that does > GFP_KERNEL | __GFP_NOFAIL right now, and then spend a little time on > the rest. I am not quite sure I have understood you, could you please provide a concrete example, for example, for the below case? drivers/md/dm-region-hash.c: nreg =3D kmalloc(sizeof(*nreg), GFP_NOIO | __GFP_NOFAIL); how are you going to drop the __GFP_IO | __GFP_FS bits while GFP_NOFAIL =3D GFP_KERNEL | __GFP_NOFAIL? And for those cases in which we don't even know GFP_NOIO/GFP_NOFS is there since gfp is a variable? gfp |=3D __GFP_NOFAIL ?