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 DFA7ACA0ED3 for ; Mon, 2 Sep 2024 08:41:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 623C18D00A5; Mon, 2 Sep 2024 04:41:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D5C78D0065; Mon, 2 Sep 2024 04:41:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44D018D00A5; Mon, 2 Sep 2024 04:41:38 -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 22EA28D0065 for ; Mon, 2 Sep 2024 04:41:38 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F1FB5A1A6C for ; Mon, 2 Sep 2024 08:41:36 +0000 (UTC) X-FDA: 82519154592.17.7D6AEA3 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf28.hostedemail.com (Postfix) with ESMTP id 112A7C001B for ; Mon, 2 Sep 2024 08:41:34 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=KM+0EsR2; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 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=1725266448; 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=Utp1RoWfhaGakPbnKMVk3xSbFrGMSY4DPD6Mxcnr7vM=; b=BzhvUniOMTDke5jVF3U6cOGeqOeyPG/q8ksnmSbaFS0VIgfKWfHFjiQ49myHqbVSCyvtRc vErPjXOWjOMm75zl7Ny0tj374/XJPG7xchQMWxhj5fXftTRykoqJTOHmTdMKHYOdsfrfAi IKG7LVXNXuT/7+og2Gp+vsXj0xh6vdg= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=KM+0EsR2; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 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=1725266448; a=rsa-sha256; cv=none; b=fvRcI7pdNcPkm3eO6YdouKO8Sb0clHfMzfD08Nse7x8NQphcaszop/x6bR+2+2FFKoXxTB KXrsRmRK8LM8JdNYL0uJLMNiMokL9hLZ9VGINymHAEMg4WWcsao3ik9HHy0YKGOB20nqp/ ObQRJxD4AMy1rvZSMAOVH676skdmAzI= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a86e9db75b9so419117666b.1 for ; Mon, 02 Sep 2024 01:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725266493; x=1725871293; 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=Utp1RoWfhaGakPbnKMVk3xSbFrGMSY4DPD6Mxcnr7vM=; b=KM+0EsR28AU8Z6E31cb05NAmm5HaROZSpYSdkCGS/yBW6DpmwKFhxd4tc5PoIR3ZCj fXqFsKvK1jrLx7CL3dUdrQqPZUrqTOt9JAEh5tgSGz71dJgMlB81QfzAzC1JHT6OFCL0 UJvQPrpS02Ka4NNmpwdPYKcfdBMS9YgAWszqAQVOZKPg154EKkb2RaJ/AD7guh15IX6H uq3sDsUbLWqt+IInRlguPPirm/g7FmMoa14wJ4UudwJsdd7zv8VEZ31BWG0E0CL8++Zm 3HqsfjahlI/C0CfCPfRv6OrwL650WtPAMNJvbSZwbkvezVhpi7oDFfkzTS6t1YtHpsIB meHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725266493; x=1725871293; 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=Utp1RoWfhaGakPbnKMVk3xSbFrGMSY4DPD6Mxcnr7vM=; b=JO4aXdDKzCAcOrLdvIRV6uVv3g+PPaoyYM+Ngjxw1u1GRTnPRMSiPtMWvsUNiITNU/ Vik3OkcqdkAamIO/58IY7hn6QETZAFvx3gAmMg6FrV0K+yZ4JNAT1WuIgMZXuIKC24fZ xNKwEHCljrfmbojw+gFZeFZ6oQt8yHU4hHytMJtyFKY5is+WwbJ5PNnhzyZ1mpLfTRdU c/EHm1kl4AOg4Q22KKUEo86Y8kIPxAcpZD1tAoepGZJ4peKa+RyEanhBJkpyNpcw/kdd /DxX/uCrS2Devv7AbmbFY1JxuuPdRTH7+dN6UHAG32CvLarPlteSD3JBMpS2vgj6XdIJ VXmA== X-Forwarded-Encrypted: i=1; AJvYcCW9G9KCKUOq2LPmAu+78xh8bDEl+Z3ylAADVOO661yG2frJzxw7xnKDZF5FB7sT+6UaijihRLH/Mw==@kvack.org X-Gm-Message-State: AOJu0YzlebX/QSdD2Ileec4rS0gUUVau9MJjCMHzgwxVoc44KdXJcM/B 3AshOqGi0RgiTj3zsnR7HkwKQOmKBaV6eXqUL4j+r03pwKQo4T0q1+lFZFgEETU= X-Google-Smtp-Source: AGHT+IH0oa4HGDBaWmEW2YFqYs/c/VIYcD3KLgtz3Ns27MTTgp0m3AKBLw/5R/bF6mlCHND1zKa/NA== X-Received: by 2002:a17:907:60cb:b0:a86:8169:f3d6 with SMTP id a640c23a62f3a-a897fa6bb2fmr1161343566b.49.1725266493202; Mon, 02 Sep 2024 01:41:33 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a89891d6d36sm535496866b.149.2024.09.02.01.41.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Sep 2024 01:41:32 -0700 (PDT) Date: Mon, 2 Sep 2024 10:41:31 +0200 From: Michal Hocko To: Kent Overstreet 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-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 112A7C001B X-Stat-Signature: 6jgpxmeia41swfgwwd4yc6e5zs6siex5 X-HE-Tag: 1725266494-828947 X-HE-Meta: U2FsdGVkX1/r5gtj/ZKINaZzKFij/roDMTOINS446fNbnQmc74BXy9fcOi73Xl8DkUQ4NWB5ylVc5VklRwVy+EQUKQVc2xzVxHML7HCymbLbB1b8z2o147Tt/CwKQeECpUZFI3q15CPKD+vpMFU5nkvszOfc5AmZP5n3zvJahWZK3rphTxN9dUwETMfznCozzX9MdazOWq+s04v6nwGptuf4CJnkqLO0G4KJHRLeJVsjGtLFudbdgbLboAxI/ySArhHQeyM2w0iUeQinfMrAM0EU0/kl1l8mfliT4+8ZlweHUKk+JWb8Bqvls0P5A/1TyTcgQtRMFVMbbJkamWYdevrf9IGoJZitzdnUmVBG4JR+JFoKhg6CRe0x0EKOZV679dd9rm80Gaa9e+XGG9yBXt1O0m/INEzr+GmvzNbsIKh/RmDCclUd8CKyFumi7YSjBwiDOkcjDAWeaNLRlMuEF4y+XMN68cSKL/nO2zZpfvF3+/kiVxvZQlf4RpF5PN+JqEd/Z9p54NyUX65fPYkZeUCX+thqT3NRKiTkJsXUp5LB0lYTPTaiS5XudbS36VjnCrkRhz88ArNXKiaMIsTbtAaBUaNB1ePkpwA7J381lIDlfDT/osPMaeZ+FszI4jAZR0HN24a2JXC7EDqA3wVZOWreSamMQSuRBysy8PHbO4Atp8h3eyhX0/uGl4gpemiwWwXr7xYeD+nFVLiD9U+pKdozS2pHNGWEt9tCqnyB0cKzAMyGsWSaZHZni1/pHsWnIsDVrocuAB/1HUZ07SnWPCNjQlXS4NaY13bN/+B7wOGRexUpyXM7Moa8TImkPz+wNlcQA2sDQPBaYxW008q4SvujwH36gYsVcXtmyNglWJ4U73M8SJ7b3pOMQchWXSQUFrzQs0e8e9qj8veHmO9IvC9ee9KS0h2c2LsI73V+cUyHc1Z+hjRvcIgUAjesQ6lKiiuOBz68rU5J8d0102a wHjWwHGi 8qtSLpay2Yzepu0LagGbpObTXH8uvBQZv9FHu067ZuNyqQYdb9EdOGjizsSwKvCudkqh78k57WsLDq8MGSEO0Tn1+1seqaie/eAy4nSM7sgToQa7UXv1ErpVh9NpTRQFkfk/qm0BZvsYRIx9mbC7r2dr03ng3xYYbBligb4RQjhh3ZRrO2VDonEMPIwjZPAGQILiqIhCLqFa2p7+B58Q/Wi6UdJTBepI+eWwHLV2e8WxKSqXACMUCv90YodtH1iSCd2rG+d30Rti5Kb2rvpEkakfvqygcWg56S6+KF63SRCW02/RoHrmPrumTXzDNZvRiPA9/Z86BjK2p2cXLxSiO9dMH0iwXAdLpzdaXO26HSz0DzG6BNXku1ZE4Vt/+NKLAxkeKxcWlOq8LubIBMQYaCkRO/1sedMlkBFab75Hv/DD9iRw= 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 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. 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. This is not what the allocator does today though. Atomic NOFAIL allocations fail same as kvmalloc requests which are clearly overflows. Especially the later could become a risk if they are reachable from the userspace with controlable allocation size. -- Michal Hocko SUSE Labs