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 7D499C52D6F for ; Tue, 27 Aug 2024 07:05:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DC6D6B007B; Tue, 27 Aug 2024 03:05:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0648C6B0082; Tue, 27 Aug 2024 03:05:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E47176B0083; Tue, 27 Aug 2024 03:05:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C32496B007B for ; Tue, 27 Aug 2024 03:05:41 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4E0621A164D for ; Tue, 27 Aug 2024 07:05:41 +0000 (UTC) X-FDA: 82497140082.24.EDD288C Received: from out-176.mta0.migadu.com (out-176.mta0.migadu.com [91.218.175.176]) by imf15.hostedemail.com (Postfix) with ESMTP id DECB5A001F for ; Tue, 27 Aug 2024 07:05:37 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=XNqTUCGD; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724742276; a=rsa-sha256; cv=none; b=ZMyNQanOzJ3tXapBMKSZxZLhzcYm147aeQvMhsYhiOiawkjDqt+ji5iM0qFJ/Rqt+Wc9Tk osCQgLUf6WO9larDiETgSIMSITrVgVx2/h23DEs0AP5cm+/EWwKTRo0wHavsQeqRzVXRLg Fq54/fQfoR9rAfhC2Gf2Z6j7JTbQ3To= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=XNqTUCGD; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724742276; 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=NbC7t9Ien1nGCt/SYyLxwfKS4f4sVv6OHgu5DtaqtWw=; b=nWHaXl/w9OadQqU4hjQnEhtAuWuTOGcB4lHSRcXI7mLO61gUp5rfjltu3CeEYbDocW1ECT mO5JzqHYuanCEz9IokW33s+ysj+cCCVRTMp2Ba5AOi3gGtt3mBf1242lJn3CmEs61P9VL2 A9miZIafjdnsbQmn5GIbS7NLFgYKH3k= Date: Tue, 27 Aug 2024 03:05:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724742334; 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=NbC7t9Ien1nGCt/SYyLxwfKS4f4sVv6OHgu5DtaqtWw=; b=XNqTUCGDYD34QEkKy9rj2djn0dqWUZxABFTovjz1OcieUKH1/01ZL+fGhJkUpDpEG0E3mv 0e+SAv7j76TJpFI6J89B42q8BVrZFeb8ZVU4DNjV/FOsqIkBY3pDy7sj01W8Agufy/MUW3 qjO4AQGYTPb13PcIFsLsmaD42sgsKG8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, 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 1/2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-1-mhocko@kernel.org> <20240826085347.1152675-2-mhocko@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: DECB5A001F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ug6hebhf9hpjiwptbjmmyhc6orawzbnk X-HE-Tag: 1724742337-958536 X-HE-Meta: U2FsdGVkX1+7/zu5LjzXVA8Y9NLwN9oBCzWWiWP3YNsi7oOmRn9Q2In1QexwaB1e1P4c3WCuW/sva/xmE6f4g/Kp9c+ADNFMA3hvF4Du9j6x5BGAV+lHTnp+80w9obnp3RcLreoKHiiQtsWKu02MqU6S30VHreL/kmxDNuGuAQBJBybbOUxP/9MDyWxDeauj4053oGcuwMNS1lTw/XAbxTKdLnredREPF8NczqyU8xCld+KN4T+WjVgMzCAYrhE9CBVyiPLQUvFsbBkOhX5DpcUVo8mw8cqH+M4qcP5015BBcbpL6pM2CV8brRx/8Ua2vZo3p0+3L2y2DexcE6dbQMBCjzbAJviMOLQ4MiUsc9BeGZloevrw6cz/uw/wRsvyC3O6ykb6MjMXHWx9uFAlTtCPLlP6r8oE4+T0RLviBQiudDVqB5bRHCGa1a72stogF29Q5nWqizP/W41MQ4/WqczbfTl0HhZHvGMAFTe1aDzpFZWJkhe382rAcIkSBgm058ctNwVTep8/GeUTA0svNlysTbqJWtyDbiodliyrmI9k9NN79VjY6A4uTcseVIQ8SaMzaYD/zsjYBLCB3pLME2gdrJCFFxNgjL1zoympsnC5Rx4iFdeHGnKewXIImcUfFuDjVlZ6EYcTkJ/lilSSqyhJZhRh4JfZyvsmOBc0IbidCzyBxAv36kAF9ES/+8jdfdUnlT/BbQmy6lgEeL2fMa0+2jcTxej4+tQrb8YSYXr5yHRhCAlSE+Spddhv6jCkPgDObceGixuFZE6bC7QvM8TWLotCXIadxoxY7z8p0HiiJXB6w/F+VM9u3kfku1P/EmWHpN8wM5CU3ZDhWUom/asIzuLGeP9bMyrL3gKMzf2zzSokwiBDg+NmKsq67B4EQ+p5hADEBPd+D9lZ3PUHrT9JnxcXSla/WMAhzO4yy983p6sJJZ7xgYRL/rn1oHQIPJpADUUrsDFOeyNnK0D wWd1tWUe 2iF5YTiEC1VPqcX5yi7odhCTPebl7WE5ZrZ7KVuSlKLr/kwLFUJ8Zf6e4tam98MqQx47dKV5FF3MZT3kmCvNLrkVagL23CUHlGSGl6d4c+IJ+2nJzojUL8YzhUAPC+BgfBsfideY+IjOOQ1wkUa9EXU0Jk9g4pYtcR+pFXMjT/aJ27i6M8zsHJEzm7okd6LRZIJYWiResNPQIhoa/STNGIy7qU/kY7xem2fwqYgCDEz48GrA= 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 Tue, Aug 27, 2024 at 08:58:39AM GMT, Michal Hocko wrote: > On Tue 27-08-24 02:40:16, Kent Overstreet wrote: > > On Tue, Aug 27, 2024 at 08:01:32AM GMT, Michal Hocko wrote: > > > You are not really answering the main concern I have brought up though. > > > I.e. GFP_NOFAIL being fundamentally incompatible with NORECLAIM semantic > > > because the page allocator doesn't and will not support this allocation > > > mode. Scoped noreclaim semantic makes such a use much less visible > > > because it can be deep in the scoped context there more error prone to > > > introduce thus making the code harder to maintain. > > > > You're too attached to GFP_NOFAIL. > > Unfortunatelly GFP_NOFAIL is there and we need to support it. We cannot > just close eyes and pretend it doesn't exist and hope for the best. You need to notice when you're trying to do something immpossible. > > GFP_NOFAIL is something we very rarely use, and it's not something we > > want to use. Furthermore, GFP_NOFAIL allocations can fail regardless of > > this patch - e.g. if it's more than 2 pages, it's not going to be > > GFP_NOFAIL. > > We can reasonably assume we do not have any of those users in the tree > though. We know that because we have a warning to tell us about that. > We still have legit GFP_NOFAIL users and we can safely assume we will > have some in the future though. And they have no way to handle the > failure. If they did they wouldn't have used GFP_NOFAIL in the first > place. So they do not check for NULL and they would either blow up or > worse fail in subtle and harder to detect way. No, because not all GFP_NOFAIL allocations are statically sized. And the problem of the dynamic context overriding GFP_NOFAIL is more general - if you use GFP_NOFAIL from nonblocking context (interrupt context or preemption disabled) - the allocation has to fail, or something even worse will happen. Just because we don't track that with PF_MEMALLOC flags doesn't mean the problem isn't htere.