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 1ECE4CA0ED3 for ; Mon, 2 Sep 2024 08:53:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 914EA8D00A6; Mon, 2 Sep 2024 04:53:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C4C18D0065; Mon, 2 Sep 2024 04:53:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B3818D00A6; Mon, 2 Sep 2024 04:53:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 548818D0065 for ; Mon, 2 Sep 2024 04:53:00 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 83CEFAABB5 for ; Mon, 2 Sep 2024 08:52:59 +0000 (UTC) X-FDA: 82519183278.12.A5593DE Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) by imf06.hostedemail.com (Postfix) with ESMTP id 9DD47180025 for ; Mon, 2 Sep 2024 08:52:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hjuz4cMy; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725267053; 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=d/FrV6PursYjofC+mwM2z5mlo6l3AN755IMJVDkbYFA=; b=yikKpVkYZoLj+fubDnv/8NA9hPGJ8VH+AdhYIl/8Hnpc52VggCnj+0iUpHydqv5/lZf73x ODaCGV+AQooRBSPwgJuq2/gbBQM2flSIOOb3E3CAv+6raAD3ajFV7u1rPLzXSvQWfGxX7T zD8h7zQkSpHm5tN8VM10LKDjJjrMYaw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hjuz4cMy; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725267053; a=rsa-sha256; cv=none; b=DO5qW0zGayJr66YAS/ZjuZv8aQ4uUSBdTy2l0/2rodmh65C/WyKVargeiRXoB/UgVEtD5y Vox1DHrgapBP4tLbc/jRtoehB6sAtgKM8zaV0Myu2dnooEOiIi1GkKAKGNgzK8DKgjJ2/P u9UZ6l0QTzIZaKi30Qs1ktYSLGuzB9Y= Date: Mon, 2 Sep 2024 04:52:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725267175; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=d/FrV6PursYjofC+mwM2z5mlo6l3AN755IMJVDkbYFA=; b=hjuz4cMyIyyjAYdtheod8ofxwcBo9WxTFhWMfgcs2kqFegQQ+xz/8VwQ9bAYgTopPnIuwx yrD2CsSuUehbY5mpOe4cqCx+7IHIH95VxkXtjlwWzc2rqVta46V68CYe/3or7Xz4IsToG3 1kiqUMmEomibDJqL0MhByGz12PbfyqI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Dave Chinner , Andrew Morton , Christoph Hellwig , Yafang Shao , 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 Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-2-mhocko@kernel.org> <20240827061543.1235703-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9DD47180025 X-Stat-Signature: qno8k8qzzn55nccpqx66u9j4b18yaqns X-Rspam-User: X-HE-Tag: 1725267177-53345 X-HE-Meta: U2FsdGVkX18U9SVItGkd9Nap+egrmmPR1bb2S2dlW0VdbkIy07ksQxIeXknodbApmixqiv7B2aP54Z7/kWu9Ivej/nDSNNhLXsLV4LL9YmHXuO893vTu57dFCMR48YM7xk/kUCSjkBQLQsNaor4pt9OFoHmX35mk2ClwkIoBOft5giVL8t6d41ZexwLX2HdE/Ng1p71EeCst3kutatcYt0znn3z7V0AplFVaiRyrAIhucQsY2+pk59SQivSS2P9qcoaWaqdPon6pUOlptDP4o5IYppZd/iazHDgQQpkpipgk5FLhWO7RTpAcM/P8RxWTKLA9JJN082pMTMxvnRTI8mU4m6D9/kZZA8n5osC7izwnXt+jmzWgXEHwLN/wwKk0aM6R837WCbdJRxIEhe34O8QXo5270bJ2NO2NPq/AwfbU8dSaNFfo2GcYW77sU4Q1y9RgnXO3eTAvbjFjtCMqKnYFHArMTE0zwH5MFCX8ffAR7ZKONGVloiBPy5FmXUJ1IC3tNT1YYHNtspo/LakV5oNMWgWwYUec8EVao8Mf7/IUEd+gdJybrSTfUG14OcFX0sv8Ab7N0bglJ4S6C+n6mUnXHkH1uHQRGDO+Zqmzf1jS5fMSxbHIBjMXE2NOjT92RLxS8KI0575cAPSHuzrJbMWsQ6UJo1ogJl7mlRw3TgrXS3r8Lw1J/N1Dwd5sOqcbCcttQyn4I9fZf1lI2Q1i2yv7oLgdifU0gxS03vdRyvnbXv0KfetVVUEGM1BwerFsdafhnyzL2nS8e9jAJlbR1UgCH0vQbeIq7XAWXdk+iq7l0o5tEeaYg0NY++qv+8Br88fyyNluL24NwNCkJYnr5zd1GHjPzsMI56Y4l0UUs+L6Zp7Na3jwfMqIbhDONSb1xES8R64tpX09qjSn/U2QvAVs/fxkiekyUsgZZAfV8RA0DXdLJ2GJSYuVVddEbaN8NkaYzpz0BZWYRtBLkZT 0b0HKYry iWwdnBV4hlfP+fP4Tbsm5yXnZQmOkq2eKClCV8ilaPNN80itnEPx1ASZX/hWXwzF+b4RPrXUyqIzf+mBCRCpKsXShcM5jb9Q9rbKB8N3E6AmuQtfYL1e6qe1bAx4TWopNRq6ngMOnhm1miKcvew/zvXvlYxnAeCxOr9L6mungqaN69sIIbNNERIec0232Y8CfIDWC3PLK8mzvLoMc+GO/IoYFMrxcEqIt0OwljOzoItEx9f+7p8KxhLFdCr9cIH6QNQNWpIhgOWO0Qoc= 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 02, 2024 at 10:41:31AM GMT, Michal Hocko wrote: > On Sun 01-09-24 21:35:30, Kent Overstreet wrote: > [...] > > But I am saying that kmalloc(__GFP_NOFAIL) _should_ fail and return NULL > > in the case of bugs, because that's going to be an improvement w.r.t. > > system robustness, in exactly the same way we don't use BUG_ON() if it's > > something that we can't guarantee won't happen in the wild - we WARN() > > and try to handle the error as best we can. > > We have discussed that in a different email thread. And I have to say > that I am not convinced that returning NULL makes a broken code much > better. Why? Because we can expect that broken NOFAIL users will not have a > error checking path. Even valid NOFAIL users will not have one because > they _know_ they do not have a different than retry for ever recovery > path. You mean where I asked you for a link to the discussion and rationale you claimed had happened? Still waiting on that > That means that an unexpected NULL return either means OOPS or a subtle > silent error - e.g. memory corruption. The former is a actually a saner > recovery model because the execution is stopped before more harm can be > done. I suspect most of those buggy users will simply OOPS but > systematically checking for latter is a lot of work and needs to be > constantly because code evolves... > > I have tried to argue that if allocator cannot or refuse to satisfy > GFP_NOFAIL request because it is trying to use unsupported allocation > mode or size then we should terminate the allocation context. That would > make the API more predictable and therefore safer to use. You're arguing that we treat it like an oops? Yeah, enough of this insanity.