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 0D39CCD5BC7 for ; Thu, 5 Sep 2024 13:54:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 564A96B00FC; Thu, 5 Sep 2024 09:54:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 513E66B00FD; Thu, 5 Sep 2024 09:54:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DC726B00FF; Thu, 5 Sep 2024 09:54:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1E1596B00FC for ; Thu, 5 Sep 2024 09:54:00 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B1638403E0 for ; Thu, 5 Sep 2024 13:53:59 +0000 (UTC) X-FDA: 82530828198.27.25FDAB8 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf26.hostedemail.com (Postfix) with ESMTP id 0039E14000B for ; Thu, 5 Sep 2024 13:53:56 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=mit.edu header.s=outgoing header.b=h1S+UO08; spf=pass (imf26.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725544339; 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=XBNj3KHe7DuZpKVxVCA9zURNDJAF8QFjg3YArsA6zRA=; b=xAwuP36iq5QfydAa1jUHlsUW58Xn3egVG++l6F2wxh/+sh0YGrt+68+c2yUP+C/kJ4zsC/ E6iCY5wFk+2ZOTgZvUDMI/nD6At/I2l2MLYSNiZtF1d17OihOGLl3hZXHPphEdkYP8sxIv waw49VxxTcxwzaXd8z7Tftom39E2W2Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725544339; a=rsa-sha256; cv=none; b=NFi3V3ontxizEQ5+Trebhf2dzpDNPLfEV1Av10zlYAkBqs3Kr4OW3llceoWx+UJvPHZg3i YEBjlz0sgJbY7OkBAn9gpEUuilN7GCexPxdY/edbYlimJbUf/IBMP3IvWrhsIA7y64qt45 tZadRfz5wQYIDlpF+iDpJX73kTeP7HI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=mit.edu header.s=outgoing header.b=h1S+UO08; spf=pass (imf26.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from cwcc.thunk.org (pool-173-48-102-194.bstnma.fios.verizon.net [173.48.102.194]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 485DrQUd030840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Sep 2024 09:53:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1725544412; bh=XBNj3KHe7DuZpKVxVCA9zURNDJAF8QFjg3YArsA6zRA=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=h1S+UO08dOUuPvbuUYg4xCtN3hwTpd8U8iHTnZ57kQtu3ngdZyMQCrpxb0cVl1hnO kAnh0KhRN6gOt/MKk2OzgdPPZ6JcXoVdichJUmxDnCgZ9L9Dzi7YxTUZcKKCxDp+go TNSKBU696FyLxDtUULiBYhT7JSyEaHO9FBP1mQOb9aRmdGbh25Qt9ISUgVS48X2nk0 mJ6bowqneHcB9SZu+dxoYfOYPOrf7cGeCKq9YjTkAgkoBxYW7jBMjacelHLhkBu4QH sxLy0OBwi7QsAUdbWSLkct+8+Xls9RBw/tcEjLCNt/OYnbL6t3na9M4BU7jQsIc6PA pTfxwI1xAeGyQ== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 7501415C02C6; Thu, 05 Sep 2024 09:53:26 -0400 (EDT) Date: Thu, 5 Sep 2024 09:53:26 -0400 From: "Theodore Ts'o" To: Michal Hocko Cc: Kent Overstreet , Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, Vlastimil Babka , Dave Chinner , 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 0/2 v2] remove PF_MEMALLOC_NORECLAIM Message-ID: <20240905135326.GU9627@mit.edu> References: <20240902095203.1559361-1-mhocko@kernel.org> <20240902145252.1d2590dbed417d223b896a00@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: edoqn8miuf3ixgxydxqbo7hysmo9uu45 X-Rspamd-Queue-Id: 0039E14000B X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1725544436-647386 X-HE-Meta: U2FsdGVkX19DoxAe1C67GSuCjc3+suSTbsDpYED+iNczqQHsEncLqpCgf+Uadisir59llE65vtysTHd2kvDqh/VLpZ2yDZbGjx34CkHKI31CjsPAQxkrpze6Ziloh6u6bYxc5He1MbM3VYCWOsvfBRELoFmOFFG2AshnpwF21I6VycxeOJ8T8sRb1sELr7AAtWD++CoJL8SZ/h2XzWGDYHkgd6GA3svkcv4yFAgJ6ElIvFioLSA5YJehtx0y6T6+ZTdctcnqNZs5tLW47fK5p+JqzKoQAcYu5OxxFM7azD/GyXaPl6aSygfU5mGQpVBXzKuCkSRdwZMtLfclasqxI4XqUTkMDRnWgZ7rhfQhga0x+dhoUppF5vEHb+48eINeFbdHCYnFYGKyEibH/KK0mn81FKpy6tWOxAWO/pqqF8OaWDODAttDYcCyAMc8zuI0YzNYYKZec6INz8/ariUJCSxkF5m7ci8fjYDbyHofP/WWf2VJTeyUCS0ey9Tv/07Zk2b9L5KrTItD/0JSevbojQZEEkalDWrYilmcMf5IE/9qcZFIUFkR/mVs2b2Q4XoHoqSiAeaz/3j7NbPciXqlASmm8xhtN8NFocRI5oyP5645yKUffxQUJ/X3GTS0Z1d7RT/FA8hRPvBSpfuqWjy8lA4zJgUExY31Du3ZB9/mUv4nn7qW0ESrSZhjIlUzYaX/zLjzTikWF3SLie3EAz7aYn4IjB9Ra3aBb5gHuJQ7MJrsV04VFf9x6/HmpdvCtsQrBLHmRSGSuud40YyVrissGbsagFnp/VWIiSpxRKEPz9dERUVkax7epmUqNSAK7T1wFwphkMsFppRaIvkQpv61i5ocSD9jqnm5r7DlObS+XSXZ3G0/thE1ivDe2ymQVCTxFZ/ZsybJNe3abxnl3Qhiq9Xy4EA79pymFWLwvr1IT5VhTvkbY95D+R6WoQHVzkHJcFhitSEw1NhrcptzbD7 2pkR0lQ4 nyKAIlC1/hksJ/xAfjWBMdjKJ9icMBvZrgHuE8OYcIXSQjFNVtK4/GJBf8O5m6hTAcuk2U2Mx3puVrRU3fpP591vstmgSG0nrYMUC1a01W6ZHYNB9LNwefL0Gmz2T6rjtzZQlkyXXso4JlxfLa4rV+csUHT2rr6q6u/Ifgiki/i7RamCnU8zsG6HAj+ydsPsiRWSuaGeS/nUEAqEnTAfCrtUkic040XZ4dj/HOWVZnFCXIkpftRSWiH9GgPs+JLbkYVC2FPYEuCft0a9rYwXHsqo+c2jzVePPnqePZ6JQJBjVuK1FQv03juRESVQOB3WU00bz9m2s12LtnB3/sJfbGzRRL7Ha0wX6A1V2CSEBUC81Jgxv9Z9WDaNKPVhqZRwggV4fhdcm6PJWCx1cNdxctMZ1papTNEvBCggYo4xN26MLZZhUnKx0Xwv3SiCBZmHOu7n5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000052, 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, Sep 05, 2024 at 01:26:50PM +0200, Michal Hocko wrote: > > > > > This is exactly GFP_KERNEL semantic for low order allocations or > > > > > kvmalloc for that matter. They simply never fail unless couple of corner > > > > > cases - e.g. the allocating task is an oom victim and all of the oom > > > > > memory reserves have been consumed. This is where we call "not possible > > > > > to allocate". > > > > > > > > Which does beg the question of why GFP_NOFAIL exists. > > > > > > Exactly for the reason that even rare failure is not acceptable and > > > there is no way to handle it other than keep retrying. Typical code was > > > while (!(ptr = kmalloc())) > > > ; > > > > But is it _rare_ failure, or _no_ failure? > > > > You seem to be saying (and I just reviewed the code, it looks like > > you're right) that there is essentially no difference in behaviour > > between GFP_KERNEL and GFP_NOFAIL. That may be the currrent state of affiars; but is it ****guaranteed**** forever and ever, amen, that GFP_KERNEL will never fail if the amount of memory allocated was lower than a particular multiple of the page size? If so, what is that size? I've checked, and this is not documented in the formal interface. > The fundamental difference is that (appart from unsupported allocation > mode/size) the latter never returns NULL and you can rely on that fact. > Our docummentation says: > * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller > * cannot handle allocation failures. The allocation could block > * indefinitely but will never return with failure. Testing for > * failure is pointless. So if the documentation is going to give similar guarantees, as opposed to it being an accident of the current implementation that is subject to change at any time, then sure, we can probably get away with all or most of ext4's uses of __GFP_NOFAIL. But I don't want to do that and then have a "Lucy and Charlie Brown" moment from the Peanuts comics strip where the football suddenly gets snatched away from us[1] (and many file sytem users will be very, very sad and/or angry). [1] https://www.cracked.com/article_37831_good-grief-how-lucy-pulling-the-football-away-from-charlie-brown-became-a-signature-peanuts-gag.html It might be that other file systems have requirements which isblarger than the not-formally-defined GFP_KMALLOC guarantee, but it's true we can probably reduce the usage of GFP_NOFAIL if this guarantee is formalized. - Ted