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 94480C433EF for ; Wed, 24 Nov 2021 03:17:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AC126B0078; Tue, 23 Nov 2021 22:17:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 833AA6B007B; Tue, 23 Nov 2021 22:17:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 638FF6B007D; Tue, 23 Nov 2021 22:17:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 537556B0078 for ; Tue, 23 Nov 2021 22:17:16 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 20419853F8 for ; Wed, 24 Nov 2021 03:17:06 +0000 (UTC) X-FDA: 78842362452.14.3C42626 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf16.hostedemail.com (Postfix) with ESMTP id F352CF00008E for ; Wed, 24 Nov 2021 03:17:01 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3E32F2195A; Wed, 24 Nov 2021 03:17:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1637723824; h=from:from:reply-to: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; bh=vDPWm0p/mlhakN1e7xXVNW/moviPVK82GwF6kdGOEy0=; b=cZhmrdPKXdn+H/oudJqT/Oq1j2f75Hf43o5wUhZQpWL7W33LNbBHnGZbHFBb+ylJ35Ph4O mmln8qZQF1JySsR/L6TDKHGmwbOzU5szZ2iBYO/A+szLLJw7pVH8sEPMrAMklTRcjUJdFz WKQ0lxuSx/XGHpVIMVW4dwX1XtZzLRI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1637723824; h=from:from:reply-to: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; bh=vDPWm0p/mlhakN1e7xXVNW/moviPVK82GwF6kdGOEy0=; b=YALzMeWScEmPJ5lOZdpgGHSa67p/G3HP9wdC2hxeW/q5VhiCJtnvkRSCDqv4PEBo6O+4qh lKCnrt1wMtZXy1DQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id DC5D913EB8; Wed, 24 Nov 2021 03:17:00 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id z1hAJayunWGNRQAAMHmgww (envelope-from ); Wed, 24 Nov 2021 03:17:00 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Andrew Morton" Cc: "Uladzislau Rezki" , "Michal Hocko" , "Dave Chinner" , "Christoph Hellwig" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, "LKML" , "Ilya Dryomov" , "Jeff Layton" , "Michal Hocko" Subject: Re: [PATCH v2 2/4] mm/vmalloc: add support for __GFP_NOFAIL In-reply-to: <20211123170238.f0f780ddb800f1316397f97c@linux-foundation.org> References: <20211122153233.9924-1-mhocko@kernel.org>, <20211122153233.9924-3-mhocko@kernel.org>, , <20211123170238.f0f780ddb800f1316397f97c@linux-foundation.org> Date: Wed, 24 Nov 2021 14:16:56 +1100 Message-id: <163772381628.1891.9102201563412921921@noble.neil.brown.name> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: F352CF00008E Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=cZhmrdPK; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=YALzMeWS; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf16.hostedemail.com: domain of neilb@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=neilb@suse.de X-Stat-Signature: x18nswkq63jji6xy46ztxbz5rcedwa69 X-HE-Tag: 1637723821-117867 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: On Wed, 24 Nov 2021, Andrew Morton wrote: > > I added GFP_NOFAIL back in the mesozoic era because quite a lot of > sites were doing open-coded try-forever loops. I thought "hey, they > shouldn't be doing that in the first place, but let's at least > centralize the concept to reduce code size, code duplication and so > it's something we can now grep for". But longer term, all GFP_NOFAIL > sites should be reworked to no longer need to do the retry-forever > thing. In retrospect, this bright idea of mine seems to have added > license for more sites to use retry-forever. Sigh. One of the costs of not having GFP_NOFAIL (or similar) is lots of untested failure-path code. When does an allocation that is allowed to retry and reclaim ever fail anyway? I think the answer is "only when it has been killed by the oom killer". That of course cannot happen to kernel threads, so maybe kernel threads should never need GFP_NOFAIL?? I'm not sure the above is 100%, but I do think that is the sort of semantic that we want. We want to know what kmalloc failure *means*. We also need well defined and documented strategies to handle it. mempools are one such strategy, but not always suitable. preallocating can also be useful but can be clumsy to implement. Maybe we should support a process preallocating a bunch of pages which can only be used by the process - and are auto-freed when the process returns to user-space. That might allow the "error paths" to be simple and early, and subsequent allocations that were GFP_USEPREALLOC would be safe. i.e. we need a plan for how to rework all those no-fail call-sites. NeilBrown