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 6F099C4829B for ; Mon, 12 Feb 2024 02:06:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C41006B006E; Sun, 11 Feb 2024 21:06:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF1406B0072; Sun, 11 Feb 2024 21:06:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB9D06B0074; Sun, 11 Feb 2024 21:06:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9CB3B6B006E for ; Sun, 11 Feb 2024 21:06:43 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6EE0AA08BD for ; Mon, 12 Feb 2024 02:06:43 +0000 (UTC) X-FDA: 81781513086.01.D125DD8 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) by imf19.hostedemail.com (Postfix) with ESMTP id 7C4B91A0005 for ; Mon, 12 Feb 2024 02:06:40 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=GxbPFSd2; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.177 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=1707703601; 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=ODlaXhkp4vNT3K0AelVxp1/w7y1kMZExEnw/9cBEPxU=; b=341aO9F+zz2LLLwYL9DzatqItCJJaOMApjhCekcg3WzNwxXnmyX+yRwM2eN8I6m9d4EBsN P9E3QzwDP5Z5PN1mXjJ+r1zA56rbD29NEVTLKQ80xuuHrPFH1PpfDsntD0HO0mPOLn8Okf +otYPWob0W2mz65Pu+fshSQVyAcsZoE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=GxbPFSd2; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.177 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=1707703601; a=rsa-sha256; cv=none; b=vyRgeK4momUJa4ctUzsbZsOEG1LdBpH8+Z7aP4aX+kzo+rNjJO9AJumvrGO5OwMmIuW2vA c9s5LLIedjOvyiYGnVqRAhIE6At58z0kxUxXkT6sN5rM6zTIj4V8+6dpTZoblM+E1WtJLd //4nD5HT+xkltt28KBBWLqMG1BSm0ag= Date: Sun, 11 Feb 2024 21:06:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707703598; 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=ODlaXhkp4vNT3K0AelVxp1/w7y1kMZExEnw/9cBEPxU=; b=GxbPFSd26AFaNHCeMPJ02uyrdsbSMtgY+mZM1EFMOAauPC7HPf+I9ClVXfiBaoYx0XD23/ u0MT8umyB5uGwJ6JBSJH23EzW85RaPUn2PCFDyi07wGWg8RFh4aatF/e8vO2nCaAXTh6Kz OCc6I8tCD9HbuCTq3aRTDGozxbRosrs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Dave Chinner Cc: "Vlastimil Babka (SUSE)" , Michal Hocko , Matthew Wilcox , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org, Kent Overstreet Subject: Re: [LSF/MM/BPF TOPIC] Removing GFP_NOFS Message-ID: <5p4zwxtfqwm3wgvzwqfg6uwy5m3lgpfypij4fzea63gu67ve4t@77to5kukmiic> References: <3ba0dffa-beea-478f-bb6e-777b6304fb69@kernel.org> <3aa399bb-5007-4d12-88ae-ed244e9a653f@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-Queue-Id: 7C4B91A0005 X-Rspam-User: X-Stat-Signature: fa6rqfw3x1th4cir8m5rg8hwqskej9ih X-Rspamd-Server: rspam01 X-HE-Tag: 1707703600-514465 X-HE-Meta: U2FsdGVkX1+phJaKuURTZhwPcGGlB6qKraDqiTT8lo9mIjg8z1DmSf7D6ZOZCROya8lg5fx3XNWnB3VHCW8ZyArVPNT8joxH8wQSdAZu2s3HMf/xPWX/W/XtKOpCZYfq/wjFCYGLxFvJgyCdJ3faA/2JvITBmvpvyjcbHQcdJgYJ5L+bEMkoBnJKZuQ/GZrHIVirTczMURamHFBBQHDpXxpcfX/zjOzVIjnpkun3y6gZOWWUVcP7pwDq6KKoLFqN/yir4tyU07n9txLzLQeRGuW+J3LxhCPiZuK5nyzLXFcSCSBjXDLBojcx/6RwE5EGEKgkqbd+F+Efv5g2BtALDy/MmgjRdvYzmDRh4AfidDPa9U43PEXOxMKYlaDuEfzrVzBC7pMhH7Uup2FTv3LHUQxomn7zkQCqODSTQaYG+rXFm6ZIAEToPHE2nNNlFmumoqHl9WjIJOO4kpXGNQbILRUfUAwCVDmCj2kJ5IVXw0xl+M+Inkqs5FyCwqUfqHI+YKJlmP0vL+5OyhwUTyOL0trSc5dwFWwjho/jwhLGYth3tO2/DAAqMTsp8WE6cEcRPJmMsGNewPAlblm8L+F4tn5c2KUBWPdkJ9TCniD/2DRC2oQc3EnXajddmBT+v8KqVpBvjxauuQQdDsLZGiQzsR5wkVkB4nS1pfQQZVrbb0VkZCZqKrjCGO/5brOYymKfIuW2PaDXeCwsULS3euHj1isQO57iSbxD1JdS/ge0vvLMs/vAA2rgUUS3pbqmIQQWrES3xLbmBGwpa4rBHoAdAB6wfE8ydsQoRShbgpCwuknFXh7qZaseCPi11x0VgYburkE3yTsl34gWSAn9FN4WjmKDqiS6XkEtEy0AEUNuDAsPs50vBmEfUcohqxIe6AvrN8uRmD12AishdZUezm4fyBSLotQsofUQj75Nk4UMAKFiRzknDHOfEy7JE8Aa3/cX4pdf6wdwEwn9S6FvSYI Mo4LAtEE vBbryrsc//kvyvB7pMWCnutflpr41PK+Q6LOp36Vec2ZY72veeVK4KSkUHQB0h6vUDfdCgikNjIRcP8OO88Ujch1VxM1U5DpaUQNgC4olWISkZKpXxfrOeb1mb11vGTLuvflEGE8UzA4c2qjA1O94IR7QWBKOia3Gvrt24aYgk1D714IESI9M5RYzPX7JpLHwP94Cz8jf+/9kppo= 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, Feb 12, 2024 at 12:20:32PM +1100, Dave Chinner wrote: > On Thu, Feb 08, 2024 at 08:55:05PM +0100, Vlastimil Babka (SUSE) wrote: > > On 2/8/24 18:33, Michal Hocko wrote: > > > On Thu 08-02-24 17:02:07, Vlastimil Babka (SUSE) wrote: > > >> On 1/9/24 05:47, Dave Chinner wrote: > > >> > On Thu, Jan 04, 2024 at 09:17:16PM +0000, Matthew Wilcox wrote: > > >> > > >> Your points and Kent's proposal of scoped GFP_NOWAIT [1] suggests to me this > > >> is no longer FS-only topic as this isn't just about converting to the scoped > > >> apis, but also how they should be improved. > > > > > > Scoped GFP_NOFAIL context is slightly easier from the semantic POV than > > > scoped GFP_NOWAIT as it doesn't add a potentially unexpected failure > > > mode. It is still tricky to deal with GFP_NOWAIT requests inside the > > > NOFAIL scope because that makes it a non failing busy wait for an > > > allocation if we need to insist on scope NOFAIL semantic. > > > > > > On the other hand we can define the behavior similar to what you > > > propose with RETRY_MAYFAIL resp. NORETRY. Existing NOWAIT users should > > > better handle allocation failures regardless of the external allocation > > > scope. > > > > > > Overriding that scoped NOFAIL semantic with RETRY_MAYFAIL or NORETRY > > > resembles the existing PF_MEMALLOC and GFP_NOMEMALLOC semantic and I do > > > not see an immediate problem with that. > > > > > > Having more NOFAIL allocations is not great but if you need to > > > emulate those by implementing the nofail semantic outside of the > > > allocator then it is better to have those retries inside the allocator > > > IMO. > > > > I see potential issues in scoping both the NOWAIT and NOFAIL > > > > - NOFAIL - I'm assuming Dave is adding __GFP_NOFAIL to xfs allocations or > > adjacent layers where he knows they must not fail for his transaction. But > > could the scope affect also something else underneath that could fail > > without the failure propagating in a way that it affects xfs? > > Memory allocaiton failures below the filesystem (i.e. in the IO > path) will fail the IO, and if that happens for a read IO within > a transaction then it will have the same effect as XFS failing a > memory allocation. i.e. it will shut down the filesystem. > > The key point here is the moment we go below the filesystem we enter > into a new scoped allocation context with a guaranteed method of > returning errors: NOIO and bio errors. Hang on, you're conflating NOIO to mean something completely different - NOIO means "don't recurse in reclaim", it does _not_ mean anything about what happens when the allocation fails, and in particular it definitely does _not_ mean that failing the allocation is going to result in an IO error. That's because in general most code in the IO path knows how to make effective use of biosets and mempools (which may take some work! you have to ensure that you're always able to make forward progress when memory is limited, and in particular that you don't double allocate from the same mempool if you're blocking the first allocation from completing/freeing). > i.e NOFAIL scopes are not relevant outside the subsystem that sets > it. Hence we likely need helpers to clear and restore NOFAIL when > we cross an allocation context boundaries. e.g. as we cross from > filesystem to block layer in the IO stack via submit_bio(). Maybe > they should be doing something like: > > nofail_flags = memalloc_nofail_clear(); NOFAIL is not a scoped thing at all, period; it is very much a _callsite_ specific thing, and it depends on whether that callsite has a fallback. The most obvious example being, as mentioned previously, mempools. > > - NOWAIT - as said already, we need to make sure we're not turning an > > allocation that relied on too-small-to-fail into a null pointer exception or > > BUG_ON(!page). > > Agreed. NOWAIT is removing allocation failure constraints and I > don't think that can be made to work reliably. Error injection > cannot prove the absence of errors and so we can never be certain > the code will always operate correctly and not crash when an > unexepected allocation failure occurs. You saying we don't know how to test code? Come on, that's just throwing your hands up and giving up. We can write error injection tests that cycle through each injection point and test them individuall and then verify that they've been tested with coverage analysis. Anyways, NOWAIT is no different here from NORETRY/RETRY_MAYFAIL. We need to be able to handle allocation failures, period...