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 B3E73C83F15 for ; Thu, 29 Aug 2024 12:42:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DD086B007B; Thu, 29 Aug 2024 08:42:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38DDE6B0083; Thu, 29 Aug 2024 08:42:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22E596B0085; Thu, 29 Aug 2024 08:42:54 -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 02B916B007B for ; Thu, 29 Aug 2024 08:42:53 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 74DBB160DB7 for ; Thu, 29 Aug 2024 12:42:53 +0000 (UTC) X-FDA: 82505247426.16.DDF669A Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) by imf23.hostedemail.com (Postfix) with ESMTP id 7AD02140019 for ; Thu, 29 Aug 2024 12:42:51 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=d9wkAv5S; spf=pass (imf23.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.179 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=1724935327; a=rsa-sha256; cv=none; b=AxuUVlRsOKjZ+B0WgkwSgD+J2rWe+K/f9g99e4dm/IsjGG5iCnHbq5qcZG/EJYOwEsC224 CsNPtNbQe2queH1Lj/SwUzCQeAjSktkaHpWmw2uUy6NG99hxaXbDlfinmQwism7GNPtUgR vtllcEPj/okvoM37L+FMSCZ/H5ERCww= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=d9wkAv5S; spf=pass (imf23.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.179 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=1724935327; 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=tNwHoeoh/+wF32dV32WxYpQ/YVsPYMrSItFbwY6BfW0=; b=PLorm6Zkus3PI5M7yYuqCk+U4Vgzsu0w+G38g2jz2+3s2W3d/MMXXE1GKDwHeea+r3OSWC LAg/hgxf9/DyrfeTKNYs84DBr4yj2OeikB2Zn/MK3bssKGpNx0W+ffJ5le5KZE8IsQgWNN BXXsTpNWtrKcpBETiCzYPkrJxXtBMhw= Date: Thu, 29 Aug 2024 08:42:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724935369; 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=tNwHoeoh/+wF32dV32WxYpQ/YVsPYMrSItFbwY6BfW0=; b=d9wkAv5SG8C9ESy/IzIJVu675IQ2gFGCDH5HGa/p1MhQWtHdRWCyssPcIJXad0jP1TV/Gh nPXEbSSrSAjb9e8Dm9WDgpg9yv7oFgCIG5WDqZW+aswtTdzVe4B9/J4+BmQIMtgI0CUYH3 e18O0ZfrWXr7tU024NNjA2YNEHXFWuA= 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: jka37wj4qnf7xbabr5u65n39e8jb5emq X-Rspamd-Queue-Id: 7AD02140019 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724935371-120955 X-HE-Meta: U2FsdGVkX18cxskuizvRXZ+qOeYhePMSiLdkffasQyB6lGp4ZhTAeC/s0Vz0hghcr0WYgcqJZs5vgZnXxaiyzY0Oyz1vKDu9bD/XgTC0xIyAoeH02q6fj6PPjewvvrqjOrYEPmw+/KZUPHd5rpwnSrTClBNNF7ydXSJgOQ7Hvgyglap7RmcHSX5fFOAulycwJx0sGFK3XKHUSEuQttAxlFQBEDWKnu8A6edC7UBwp1jZPoMqeNlYC8aeGM99ObhlQbF+C11OL2c/5QCBuBOhzElu8ckdNTANvHqRKMAkzNVezHbAxpvd+HavYsQWKlDUAaxUAWcJnmgj0qi0lzDU7AbfK2qfs0svCNJUNnjqNMRoOx7oRlr1qHumld3uY9gLMUyDA4OsJRoxhQErYrofxAh+X9u4hx0z2KawPFNSv79sWZfB5acg3gwwNL/ZHI08dFLj7mvt47I7W1j78zLl7o8eVuUsSuYN1e/hdsb80VL5j0lUAQ70n0hySu+V1VuvGecNZb3+0zIGDU2owgzjd7kcOuJbzP2H4IiamKtvd2yWybLXrqrVy1AP4VN++L8gH8lbKF3BPHDQw2c9BhLaJO7VO2lAJVUll5dOz5MJMqlu0PGoDUM1JBwN+XU3QDZR2E890txJsI7a8Ef4lfxzRJgbcUhI07zuKE4u0cy40dp+CifZ3b/+SsfexJ3Vpsd0pcSNtMFtYYU2SW9yPaYcmpd27bKThLfrjZoErSNrP1bTOSWUsqmRb9+N0mrcLbzSQvnhvnJ6MZGTMQ05YEhH+yps/rbtcoOYX/mwX2ZbK6+eD6W7jdP+FWaW5tQkalpp1Gx4yJLtX0mJlHGeZBjYOah+4RmjZx/ec3lG2Et7F1XkSr9NGfc1p396jpyCbYlw3wpZRvi6j3Zy8fFaoWHiXqglS8bEKsw9KBkRKGPc+3m98AiNlVYoTR+bXIsQOeCZqUV7WXs45UfYyvB0OCC 5SPfsBfS KLyLQFd15fIss+6kI87XZ53Dm9EcML707bemHGs0WAIlW+l+YDCux7BVrCs82noiQujh30pwjAl+Ip1jbnEUyNBkahBMSlMA02LNzycxNxI7j/y5BkbTlZMiDKgwS1cTrjpnDXWr/qw2mwIIOsWqWl8zNc8Hz3v1u8PLZ 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 02:34:08PM GMT, Michal Hocko wrote: > On Thu 29-08-24 07:55:08, Kent Overstreet wrote: > > 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. > > Unfortunately a lack of __GFP_DIRECT_RECLAIM means both no reclaim and > no sleeping allowed for historical reasons. GFP_NOWAIT is both used from > atomic contexts and as an optimistic allocation attempt with a heavier > fallback allocation strategy. If you want NORECLAIM semantic then this > would need to be represented by different means than __GFP_DIRECT_RECLAIM > alone. I don't see it as particularly needed - the vmalloc locks you mentioned previously just mean it's something worth considering. In my usage I probably wouldn't care about those locks, but for keeping the API simple we probably want just PF_MEMALLOC_NOWAIT (where those locks become trylock). > > 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. > > If your definition of safe includes an oops or worse silent failure > then yes. Not really safe interface in my book though. E.g. (just > randomly looking at GFP_NOFAIL users) btree_paths_realloc doesn't check > the return value and if it happened to be called from such a scope it > would have blown up. That code is safe without the scope though. There > are many other callsites which do not have failure paths. Yes, but that's unsafe anyways due to the max allocation size of GFP_NOFAIL - I'll have to fix that. Note that even if we got rid of the smaller max allocation size of GFP_NOFAIL allocations we'd _still_ generally need error paths due to the hard limit of INT_MAX, and integer overflow checking for array allocations.