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 4B456C83F26 for ; Thu, 29 Aug 2024 14:04:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C12D86B007B; Thu, 29 Aug 2024 10:04:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC3316B0083; Thu, 29 Aug 2024 10:04:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8A3A6B0085; Thu, 29 Aug 2024 10:04:22 -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 86E6C6B007B for ; Thu, 29 Aug 2024 10:04:22 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CDDBEA8486 for ; Thu, 29 Aug 2024 14:04:21 +0000 (UTC) X-FDA: 82505452722.30.36145D0 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf27.hostedemail.com (Postfix) with ESMTP id 137B94002A for ; Thu, 29 Aug 2024 14:03:53 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TE3W8aaP; spf=pass (imf27.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.172 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=1724940115; 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=8BgFf574JTx40WrMhFgMzoeXEI17RrKv5ZxttaGBHEE=; b=HS6EVKycOQJylrlN73dxNvzi2sih0lhvM/C6RMOFbcXfb6SBXm8uoqMx3Y4PMKWLdbYcu8 fQ0ndYGJNSPw6rtECQUmDiqVHIcjYd0Z/gywDtHdILYCzOQqUs70RZogtjehzMSG069eGm K62E/NwFL75BW4eAb2YMJCjuXKFMoHw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TE3W8aaP; spf=pass (imf27.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.172 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=1724940115; a=rsa-sha256; cv=none; b=sNdEgMO0VW2NxglUMjt721av/Gnsj4WA+vf0NOcwNuliNNeNGWUMplQ+QuuQEfQMQLri3W stfyue4/mEZ0OhR1Ws6GOeAWhqicr99dj04MIbcIvpOl32ahFUqe2kEZROR1GXUjJM3orC XkilaJAEIk+bk24Kf1jh98ap1Zg7bpo= Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-7a1e2ac1ee5so42056485a.2 for ; Thu, 29 Aug 2024 07:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724940233; x=1725545033; 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=8BgFf574JTx40WrMhFgMzoeXEI17RrKv5ZxttaGBHEE=; b=TE3W8aaPorxlJ6IoVOs6ENj0SrXgQVePuVYk4YjNPQMItRKB1+s5SKd6jv2WOzmIAf wJPF257KeYjm4Hjw6llAmct5CQIa6XDRS2wSLVrTW1mBox4KhseW95kMoCc1mloHUYGc DN+mP4wszf5hgFzdCvJCa31mK2n8QXqh+esiPvQFxOoWPx60HGbBgOCJx7nfKpZJKgkI V5NPrwCHNRI+OGTbRwE9ZO5bgSCgjm8O5Bt7D6CUfqPLHvTzcIahiM44uHvJY+y34nUB pPjNRdeF23PBq0pTDt4Ck5nOqzqQJ90Id8luQq5eS3UNnmDoHfQGoUPYavwBdkgTMpy9 E0jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724940233; x=1725545033; 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=8BgFf574JTx40WrMhFgMzoeXEI17RrKv5ZxttaGBHEE=; b=Jtf8IDPdvZsFMBly62UAHmiXzthrBm8wJEhfDmon2BkQ3iwPHpdNWPX8zMJ+HILfsC zAxvPGV8ucgAAhIJvFW70vkGS5E9Hf+Qe4wX8V8YXu2I24+MooqSQwFUPSG9zIgHrNM7 Oh24Qc7gSGK8fg13N3IFB9LeqmZJwFVjfx1q1TMjpQAD2h0hh/dbmFRLEKz0UwBO7MjQ lk3oCoz62izOWJQfE70VKeEuv0xRBrF7qdYfqbKzigkVuHw+LaffOLN+FDYZ1nJ8//EB cawfdW6lq9iulBMbUj5zzkr5i2UXBGc5pYBBdLqycM/qY/fY0fOVARJBflyG8dFUkT+l QicQ== X-Forwarded-Encrypted: i=1; AJvYcCX1cUVe6jOaR1Hg1oJd8+Cng9XwGQhjtpW+4RcxNRw6l9IjFAY0mPk6OaduExWt5GkNMhucC0ABdg==@kvack.org X-Gm-Message-State: AOJu0Yxua4CeQI4C4mp4l23TTiJ2eetNQxP1ENxphlFAZf+8tOc9WEnq IIN0/Z0Gchh0Mw3NBTV0qKj1E2tTx0JGQBdejyxCBcBOPPc1JMj6IPMNjJTZAJJnrczMVagOst0 mWPtX0yiRnqnaCrIavuAwKbPISKA= X-Google-Smtp-Source: AGHT+IE8ENS/FNKAiTfyy1wjMrk7L4JOC8ww92sKUqtOBl0i2cK69m+/WPO54rS8ejBMB/SRrpl1/sSCwlHSsoG43JA= X-Received: by 2002:a05:620a:2804:b0:79e:fbca:5ceb with SMTP id af79cd13be357-7a804263264mr296071485a.47.1724940232400; Thu, 29 Aug 2024 07:03:52 -0700 (PDT) MIME-Version: 1.0 References: <20240826085347.1152675-2-mhocko@kernel.org> <20240827061543.1235703-1-mhocko@kernel.org> In-Reply-To: From: Yafang Shao Date: Thu, 29 Aug 2024 22:03:13 +0800 Message-ID: Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM To: Kent Overstreet Cc: Dave Chinner , Michal Hocko , Andrew Morton , Christoph Hellwig , jack@suse.cz, Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 137B94002A X-Stat-Signature: 3u68kfhm89a97qfc4gztxhjar1mfeh38 X-Rspam-User: X-HE-Tag: 1724940233-265025 X-HE-Meta: U2FsdGVkX1/6HrsqV8sVAwx27QQz1XFskY+xE4X7dlAG/ejnOTltXCx5FsVhOnziR4S1IXQpA6sAKUj4x3BGOHAL8rOY/pee2huj8QqdiHpTXML9W7++BESeZwk6YRV/3pa9ftjObMURJBgn3SFwdE+Q/fUoY5Qd7cCuj8jct6MWhdeuCaDJM3LSsBRqbGelBFOT6affBvJlZ6Dc0TAFoIafBXllRwiESUDlJxuGEi8MXom5CGwEC6csgOQM7z0hyo79dF3iSo+C1E/nyktyvNoBoilp1IpJYVcbEOzdDV0ioavcufFhFZs3GK3b1sC9TyOUXxO13p2bhQUCok6UFpaExMyrm5X/6VevPybHq1dpk4STe2t+3nDgAPsW9IKy7qS/Ww3mQ6111GJCXsCI19GIis/TJ0atRXTHNVxdz411hRZ5r4NegEAbmftYAsNUcCb4j3j6OA5Hw3OP6LayvZnnnq4pXDVpuzYZBE5j0PHRiIkA6laGwARgZzjJywTnv+X6ffaknCIfcUtawQzIVNpwEmZ8xBuceBfMPwN7U4YS1M/zzjmfKFbWiLY6rTNMWpIW7JiRPmfGdLgRBSeu52SomHZkGdCVMu18eBeHDxZS/N0NrVVFa2JlMO4cx9LUpaaFlo7ZNWJ5c3lSxBTemSg3Tl/9XEZBLPL6zD5jAzgU6wvayNcFnUELwFSFsNTq7rVIlnm9VThI3506QU1hLMqev7+8+rX69SkKlz0BXdTLwGvWoXy26vaKvgypPaLnWu4XY/3+aJgkkMtALghtu/poZwxdzXYUK95p7pd5eCzzUPLb7HFrbVZP+m4OoAJHPgzXjyGl9p14XGEVDJnHnpLPe8X84AmBp5UFRMA+q9Bfvv745DaNLQIV1V0bYIHvHivbWKbYTryoNnpRUzgTVVNh+tX+wDg6Vgrvw/A35u2f78ZjbYwT7cVh3fZHcSaYJR+NiqQ2JcWnGlTiVnv kQtDvcO/ M2N5R3jbptv7/SgNv9YwnIk99IQuCDzMMk0zwVrDygVzptvxjnPWHlSBJ5VWJmDnYxcGRABgXZ8KjulWNpuou+IpXqlQDdmaw/SObfzrawA2jjr39J4BWGkr1h8hXn5YBuBFVDtnwen4XislIK2S2OQ0I3Nd3AQ98Z+bW0QmCGgCzv9cL1SxahwCRCMYq2vWUd+eSKdP4yJs/fLMqcOsdo30rMsmFpLmiWWF2liJUkIIeRLdwXGXsviyYQrlDPlpZ7I900hxpMuJ81MxbeR6AUZxvjAStbRHKE6nTTsDclNEhnTQWOsybaXN8BwczPQTfTpwC2K2RmV6YDrsAoCcpgBo9n/64R3WUZ1haY/Trnan8uuDAotlGg7LjQJ607oy4dn4M1yMBVsL3GIqz8aOQeQC3BfNvDwqUtuRYFmKx5dBXo9flID9N6UlH3F1MTbCTfkzelssPs9xcjdZcIv4zvSCu0zFPE34MXA8AWcqDhsBtEFM= 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, Aug 29, 2024 at 9:32=E2=80=AFPM Kent Overstreet wrote: > > On Thu, Aug 29, 2024 at 11:12:18PM GMT, Dave Chinner wrote: > > On Thu, Aug 29, 2024 at 06:02:32AM -0400, Kent Overstreet wrote: > > > On Wed, Aug 28, 2024 at 02:09:57PM GMT, Dave Chinner wrote: > > > > On Tue, Aug 27, 2024 at 08:15:43AM +0200, Michal Hocko wrote: > > > > > From: Michal Hocko > > > > > > > > > > bch2_new_inode relies on PF_MEMALLOC_NORECLAIM to try to allocate= a new > > > > > inode to achieve GFP_NOWAIT semantic while holding locks. If this > > > > > allocation fails it will drop locks and use GFP_NOFS allocation c= ontext. > > > > > > > > > > We would like to drop PF_MEMALLOC_NORECLAIM because it is really > > > > > dangerous to use if the caller doesn't control the full call chai= n with > > > > > this flag set. E.g. if any of the function down the chain needed > > > > > GFP_NOFAIL request the PF_MEMALLOC_NORECLAIM would override this = and > > > > > cause unexpected failure. > > > > > > > > > > While this is not the case in this particular case using the scop= ed gfp > > > > > semantic is not really needed bacause we can easily pus the alloc= ation > > > > > context down the chain without too much clutter. > > > > > > > > > > Acked-by: Christoph Hellwig > > > > > Signed-off-by: Michal Hocko > > > > > > > > Looks good to me. > > > > > > > > Reviewed-by: Dave Chinner > > > > > > Reposting what I wrote in the other thread: > > > > I've read the thread. I've heard what you have had to say. Like > > several other people, I think your position is just not practical or > > reasonable. > > > > I don't care about the purity or the safety of the API - the > > practical result of PF_MEMALLOC_NORECLAIM is that __GFP_NOFAIL > > allocation can now fail and that will cause unexpected kernel > > crashes. Keeping existing code and API semantics working correctly > > (i.e. regression free) takes precedence over new functionality or > > API features that people want to introduce. > > > > That's all there is to it. This is not a hill you need to die on. > > And more than that, this is coming from you saying "We didn't have to > handle memory allocation failures in IRIX, why can't we be like IRIX? > All those error paths are a pain to test, why can't we get rid of them?" > > Except that's bullshit; at the very least any dynamically sized > allocation _definitely_ has to have an error path that's tested, and if > there's questions about the context a code path might run in, that > that's another reason. > > GFP_NOFAIL is the problem here, and if it's encouraging this brain > damaged "why can't we just get rid of error paths?" thinking, then it > should be removed. > > Error paths have to exist, and they have to be tested. I completely agree. Adding a dead loop in the core of the page allocator just to bypass error handling is a reckless idea. --=20 Regards Yafang