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 92F74C83F09 for ; Thu, 29 Aug 2024 11:55:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2361E6B007B; Thu, 29 Aug 2024 07:55:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E5E16B0083; Thu, 29 Aug 2024 07:55:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0861D6B0089; Thu, 29 Aug 2024 07:55:22 -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 DD80C6B007B for ; Thu, 29 Aug 2024 07:55:21 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9156340CA1 for ; Thu, 29 Aug 2024 11:55:21 +0000 (UTC) X-FDA: 82505127642.03.E98A1C5 Received: from out-185.mta1.migadu.com (out-185.mta1.migadu.com [95.215.58.185]) by imf01.hostedemail.com (Postfix) with ESMTP id 217064000E for ; Thu, 29 Aug 2024 11:55:17 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="bw/pmVru"; spf=pass (imf01.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.185 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=1724932449; 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=OAQ4lMRxkKE30BQ85RFYubSduZKYsX0TPx4pJMHH9ts=; b=nDloQHHv25P08ccn5C+PJEzMWhoTK7uln2GqhSQabCTu6SsiwZH9CXcTCbF9jXhTaEMG9A OF1sXigrOZEclvTyMzqCFDK6y03BAP+gcgc/M6V5QJ6U/vFKepltndBBkAtjYNSKsxWNnD hpxCI3diBR1KWXOTFPgyXiagbeaAZCU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="bw/pmVru"; spf=pass (imf01.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.185 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=1724932449; a=rsa-sha256; cv=none; b=bxvE7VG7auWG9/KsCyas8WndNVHpcQJ2T+CHIzGNLTHRdUGYaxm7fucaIeEUJnVfskknlq nV2JBRR6TtarA3gjYnrGJiRkUoDvtZ9e2C4GE5VoVGoDIWAmr5GpfE4H/F4cIKjv70vsHU izAAHCNLqsmWU6iLZCVfID+rktbE+MU= Date: Thu, 29 Aug 2024 07:55:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724932512; 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=OAQ4lMRxkKE30BQ85RFYubSduZKYsX0TPx4pJMHH9ts=; b=bw/pmVruE68blg7sBE+toIJxwqbaXYwuMwUWCmDgIkNrWrfJKlhCEWb1HRDORlcT4j9Utc hoT+m0nfIp5o+sarCEicDCILGgxBGKki4zCbTYK6GR52n+4s8KszWrmITZIGzWc/PyLAIe cBdH4XwYF4a+94r+2OofoLSIS9yofjs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations Message-ID: References: <20240828140638.3204253-1-kent.overstreet@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: prbmpub1rjc6zskthe91mnij6m17xkx4 X-Rspam-User: X-Rspamd-Queue-Id: 217064000E X-Rspamd-Server: rspam02 X-HE-Tag: 1724932517-248798 X-HE-Meta: U2FsdGVkX18OADjjqcEZJQncSM6OvvBQeI854YJz3SL5fWMpQCTiJdJ8A/toI8HdfAwhaJbv2OWmySfJEbXGQV0DFiBVp0IEkEbrkMeU4N9HrXrvSFj5D9wGIvV4Ik3ovs6VtbmoqScKiWuUI2yc6hcyPAjbLlLbWWI8q/0CUzXxPS5pr/d4l60yDd9Mx/y6gLVF34+NzR1Rgr6tTXYaOov1uFpaJ+Mq/qp7JEBKzTZCHDWzmFBCgkS940dMJdaKX8TLGgLhsvYjfMjzoUsfdpazRieH5n6/U1AorWuR7+jeH8Twvb662Cnc1YIht88JIVZHDf+q7Coj44U6Ft1OroKSlYCL0X7EMLZRJmHhX5DjsfGm9F7JK3yFWzaPvGxQ1vyt5A85hCPABMS7fLjIrNYmq8ZyHKFZTDvYtgc5gcpgewpT5uajSbnR4lNXCA75in3BTyN9w6yveFiDv2d3OE6be4548VecXA60LeNbGBHMdalMg/yAQujtw3xygtrdihVWv4DX0GBOgnxUXXUtJBgmMdTGsza3SQdSr+PHPBtZnWcHPFcBxWoiBkNkKSDQKP2+J2hTUEVYbVhxIa0HQpuh9PuayUgatAJm7tIVW/z5SeydPPDq3Z3LEH7G4j/mqKiau2wBlnXGOLnL2fkEVNjhaamMbMjDNGT5Itac3bgqooOrQT2keqZjimt9M5UWphrApT6FIQWZFgD6/tuK2dpM5ImJNAjyGQEA0t4PFbnMAT0KCqzfF6TXO16g0hDUr66l8DEelwRYLO6lACoBUfyKsKwgUOLFvVcoyE/tnz1lci8m9kUaAGlbJiTW3qqnOwA0cw/tFAuzhKI4pQ5P++jQzzzbLvswpdCZAllUbBIexGQmFxkiPa5uucyZDgcGaarXi4NOJlYQPV8uL3drUeTEaFpc9HpBg65OMhwRAKGSsjdImnqBHp6KQSYk3VF5pcoCXzYeeOiAJMVmF0M JwL27g4t tM0mfM7fGSlgX5SLWU2lrPstE8rFhFlaYRImk8Bo0m0hsdZM5W5xV06bUc6cm+/rDGvvHBGS2kSI063mK2VdyWumc0bUzpeWs9njTUcW85NTZVNYCtIe0sDVDRX+nchYilPSMIzfehSTaX98AyIvotTHGdP/bI7y6RSzn 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 Thu, Aug 29, 2024 at 01:08:53PM GMT, Michal Hocko wrote: > On Wed 28-08-24 18:58:43, Kent Overstreet wrote: > > On Wed, Aug 28, 2024 at 09:26:44PM GMT, Michal Hocko wrote: > > > On Wed 28-08-24 15:11:19, Kent Overstreet wrote: > [...] > > > > It was decided _years_ ago that PF_MEMALLOC flags were how this was > > > > going to be addressed. > > > > > > Nope! It has been decided that _some_ gfp flags are acceptable to be used > > > by scoped APIs. Most notably NOFS and NOIO are compatible with reclaim > > > modifiers and other flags so these are indeed safe to be used that way. > > > > Decided by who? > > Decides semantic of respective GFP flags and their compatibility with > others that could be nested in the scope. Well, that's a bit of commentary, at least. The question is which of those could properly apply to a section, not a callsite, and a PF_MEMALLOC_NOWAIT (similar to but not exactly the same as PF_MEMALLOC_NORECLAIM) would be at the top of that list since we already have a clear concept of sections where we're not allowed to sleep. And that tells us how to resolve GFP_NOFAIL with other conflicting PF_MEMALLOC flags: GFP_NOFAIL loses. It is a _bug_ if GFP_NOFAIL is accidentally used in a non sleepable context, and properly labelling those sections to the allocator would allow us to turn undefined behaviour into an error - _that_ would be turning kmalloc() into a safe interface. Ergo, if you're not absolutely sure that a GFP_NOFAIL use is safe according to call path and allocation size, you still need to be checking for failure - in the same way that you shouldn't be using BUG_ON() if you cannot prove that the condition won't occur in real wold usage. Given that, it's easy to see how to handle __GFP_RETRY_MAYFAIL and __GFP_NORETRY: if they're applied to a context, then the usage is saying "I need to attempt to run this section with some sort of latency bounds", and GFP_NOFAIL should lose - as well as emitting a warning. BTW, this is how you should be interpreting PF_MEMALLOC_NORECLAIM today: "I have strong latency bounds here, but not so strict that it needs to be strictly nonblocking".