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 46A8CCD13CF for ; Mon, 2 Sep 2024 09:51:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B86318D00B1; Mon, 2 Sep 2024 05:51:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B363D8D0098; Mon, 2 Sep 2024 05:51:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FE018D00B1; Mon, 2 Sep 2024 05:51:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7E9DD8D0098 for ; Mon, 2 Sep 2024 05:51:09 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EDE7E81AC7 for ; Mon, 2 Sep 2024 09:51:08 +0000 (UTC) X-FDA: 82519329816.08.A5B7580 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) by imf18.hostedemail.com (Postfix) with ESMTP id E38511C001C for ; Mon, 2 Sep 2024 09:51:06 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=t4kJaVlk; spf=pass (imf18.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.182 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=1725270644; 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=DvuMnP7w3vffI0/vSAapeokE9ygqz+HaF9Aaksx9bG0=; b=ncj7xeVGXa+vwfOq892LzWD7GDHzyUmk7+0AufUvw1yv/TTDzHMFNszMlwqF8AtTGm9zUV A7ijXjU+0eiIExQ3EwckPPFg704o714Au8asugNaLh82m3DKYcX3XtAzJxbKKhyBb7LlIR 2eiARMi7v+J9QFbsve1iplZ6r/MjSAE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=t4kJaVlk; spf=pass (imf18.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.182 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=1725270644; a=rsa-sha256; cv=none; b=EJKHPnsQbn1J3LXBN2Tyzs51ikddoD7V7GX9S2RYcFa+2mGUJjOduF5NtXpAXaOvoyoRPY Kep5n4SUo3AA5AENiplFBK8CnM75zsNgJBO3cTfjbfjCXAa3jG+sCkrIurg9A7tZmbV4V9 oyzoKeaTBgPfwcoKu36MvPOFsguErrc= Date: Mon, 2 Sep 2024 05:51:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725270664; 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=DvuMnP7w3vffI0/vSAapeokE9ygqz+HaF9Aaksx9bG0=; b=t4kJaVlksiM0tu/pUBiVqQp9VLGLKhZPpdN7t2/SB/xvRgFXnXRsI+xDpSUxzy5vNaUjwB bEtiuKt04EZCy8z1mcA0Ur4IRUnUToZF2dHRiVEaI1uOxk5vOv8bdGPkTJc5R4bzFgYA8p E7OmBCq/V5DXQYOdk9eM0B/H2vlv3zo= 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: <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-Rspam-User: X-Stat-Signature: ukmnpzhybxtzkxdu6ueostgrfoiw9zay X-Rspamd-Queue-Id: E38511C001C X-Rspamd-Server: rspam11 X-HE-Tag: 1725270666-767647 X-HE-Meta: U2FsdGVkX19/Ei6H7a2lXa++TEYp7LdpS45CPUmo8YpmcAa6+QBNsARtdjOabEzWSIBXjBgT9Lk943bAvisQuf9V0Pu5mVAYrtPhXw/zEhHa4DEVd7iI7xfV3bO5J0AqYVIaZ+brsZIgADSrX5cMMBAiJBvgXQprNb52V7oXKlZrxB3y9sH3GAW+nJ8Kaga5V1cuJR6mr3soK+NyQ7Fkk8lOkbjKowRVCiW19J304VaxBsMPQCZiExfzaYu5//RnpDf7mDWwR1ViwbhReAWC3CURK/s21a9b77Pb0c3Hqccj0qp8F/VR99WE5DSbAbZCy9ZpXgmkrLzSHDboAsQxAmhUZo0V4ZTLWc95LXHejN31kCr0L0NPOqTtAfeOBDTcBdeUX7thJ+aatkxc/RIiqJuW7tuHi/VR14DsrDtBxYkWuOkyS6HkHT0a8Ke3ieRYhYtdArp95Js5viw00xmbNhbzlo+fIB7ZxVS872/aDgtkQl4+QNN1NC4foW07H8BsPbSccjh+b4SrlwGyFhZMBTsCBztl0ChJT/2z7svGlzonov/s3Zd58IzS+7OPqnW73aWDyg+XHxNdUFf+rwPCto+FQ7p9bDqQbcT+EK+NFiUIcYsOtys4CAHavLpu5TGNFqsyYiMdO3/ieoE5AutgS9exrPYoleyzXMPYmpwyWlyTX+K6Afreya5XdRsfvNOJ6zRKjHfRKVtfcLuF96g+wDJNVdpXOSR0aqWQCd3NPDDNUPyrhNGvSksbhQftY3Chs2TYcDrYu6aYsNnzjuBUHiH2B6pHkGk8vfpBJMbV+p87btjPpsMdASxm6LL/JBe2X7b9tN0pvUb4d7gxfEixMcWrawRyhR1I6GHRfFa6/XWyf5bQa8GqKu73tfIz4WzlAnqPl5w7UaLU8Xrl6igaD3wbW6gKJMjTfP2kcJeXANfqK3Ysinu3loKaOodzw0I19IThnch+cSucjyZOmgA qPDS3EMz cLJY/r2V3EQf4SDsergyrXuqEUAu4QfteF89rwrDV6hrgw/dmm1T2dgBDcnX53B3+uIn3SVHOo9QwEDxpAhwxAgsrc7/TBrA5lE9IK8kR/P8r96ntGx2ujd1HDWYAnR2FTFdkC/G5cc45nOFyZQrfDX8uFIBM1jpsd/Ex3I7/3r/Hg4aKRNVYe3o2ytqzX2XkiFHZBPLWvCag6MLZfgyKNmLRIgUQKAhH2M+ciejLzHrumWp8dTALPtsP/WPJkxsMfPAgEtD1Mlxv1bo= 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 11:39:41AM GMT, Michal Hocko wrote: > On Mon 02-09-24 04:52:49, Kent Overstreet wrote: > > 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 > > I am not your assistent to be tasked and search through lore archives. > Find one if you need that. > > Anyway, if you read the email and even tried to understand what is > written there rather than immediately started shouting a response then > you would have noticed I have put actual arguments here. You are free to > disagree with them and lay down your arguments. You have decided to > > [...] > > > Yeah, enough of this insanity. > > so I do not think you are able to do that. Again... Michal, if you think crashing processes is an acceptable alternative to error handling _you have no business writing kernel code_. You have been stridently arguing for one bad idea after another, and it's an insult to those of us who do give a shit about writing reliable software. You're arguing against basic precepts of kernel programming. Get your head examined. And get the fuck out of here with this shit.