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 7EE8AC5320E for ; Tue, 27 Aug 2024 07:35:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11BDF6B007B; Tue, 27 Aug 2024 03:35:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CC2D6B0082; Tue, 27 Aug 2024 03:35:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED5DC6B0083; Tue, 27 Aug 2024 03:35:16 -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 CE0CF6B007B for ; Tue, 27 Aug 2024 03:35:16 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 864AE161612 for ; Tue, 27 Aug 2024 07:35:16 +0000 (UTC) X-FDA: 82497214632.17.94EC851 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf03.hostedemail.com (Postfix) with ESMTP id 8111420007 for ; Tue, 27 Aug 2024 07:35:14 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=SbmAs3Jg; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724744044; a=rsa-sha256; cv=none; b=d1dg7174POaxUIf3TvmLmqlOzjfDGnduBZJ5CIs9l4g2y43usGy8nYgWhqysggKXxIXi9n //GvsnwVHK5BwGV5qZ5jJYB5VUDXcmEx8Lnmzm8tysyzCdL3vbChdeeKtQW6sGDQfWAj46 R8+nNsO1hMt/MR22cv9iIvj/W0j7d34= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=SbmAs3Jg; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724744044; 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=NCalSenT4u/MD5WlKs1thsXqDcN0KXoCRYEnOG92GYQ=; b=Y2m3ZVs7L4lTYd5COByQyVCPp18FwnXE3D2h+68TflINtfoTeNmrfzsrGnrPBM03q1pzv9 X3ZRdzUcFjZ4IJnr3Iq7VweiiH8AWt5idnRKkMIu7XmDXuB6hk/cqhKJfWJlZmu+iD/a1K plrhfscjBu+I9WPdxQynPDrATqLkc/0= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5bf009cf4c0so5467782a12.1 for ; Tue, 27 Aug 2024 00:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724744113; x=1725348913; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=NCalSenT4u/MD5WlKs1thsXqDcN0KXoCRYEnOG92GYQ=; b=SbmAs3JgxxNuMHkayWLXtFgg3G4SjtjSJ3Rf5OEUEHWr6a/YLXpcFw0Hyz+UKu8rSV DSxr4CA+nFiCKGnBjgWtLdoyHNLs/Hr3d9bP2rqtmK5qSUzZmf+lpsHLTa+D5uljpVkg 1+ugWq7r+58igM6wpg2CBTgPPqCt+dWKWlErkU6afOvu0V6kVAk+A8mchdxFHVDMuvmf FiCi0QcKLjFr0WwqwedJruC3VInTgE4iSYh2ycBcDGK/S1fZVHldkhxnom7Z5Xff6nI0 JD2KbxoEe0dvBRPcwjcmpDt73LweEJUJTTiiuyoO0dsKXyHspdEeKBQe653+QYKqwFrN HDSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724744113; x=1725348913; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NCalSenT4u/MD5WlKs1thsXqDcN0KXoCRYEnOG92GYQ=; b=XEM1vA35YXeMtomvBj5UEBk5fz9QZwHsTl4w+PcxZiUBoBnLMOiZbPpzNcdc8tLaUZ xTeTbfLx5QUUVFrM4GdTe0vXQ/5V625yiG3rj47nMblzyw6kXDrRHmulgIO0lC4EsUId UAoqZ+WrPnVX1hHBRqicR15AIw62RqJo/SB4cRcgpnKjBKLvIgC/srs28chvybmdf0YY BUiZxMPDZe20XLzz7ZfnHk1iXhVNeL6XPJCpekSPLLGxZy2CH2RKHkNcne2/rNhdIjq5 5qQOPZejz+l24R/Ary+W7dMl9EwbNCAo2oF/m/LrqsY2eTsyPgAlJx//BxZK9DTky73M a4EQ== X-Forwarded-Encrypted: i=1; AJvYcCUip+T5y0r2wSmFxQjr/mAaXe+0d1dT3VAn2LxNiPQ80NbeOq3s09sP7TbjVo6sFBMVwzGg2aL2YQ==@kvack.org X-Gm-Message-State: AOJu0YxM1gVPnnUyAZuDv524OiwYJ1auWDqwH4moZ9MmXer/WsRfU+K9 oPrFwsXkPA09aRqnqMCS48nKl5WaJD2QFK4U5cXdH7ls6fbyWzaPX88RroLmZO0= X-Google-Smtp-Source: AGHT+IFy+Emn6v+C/Q4MQkjVPHkA7ImY3QFkLrA5Qcu6aFtW3nn7+I7nf1MQSkQY5Mz9qUsXKwmv5A== X-Received: by 2002:a05:6402:40d6:b0:5bf:7dc:bbae with SMTP id 4fb4d7f45d1cf-5c0ba29756fmr1619934a12.6.1724744112729; Tue, 27 Aug 2024 00:35:12 -0700 (PDT) Received: from localhost (109-81-92-122.rct.o2.cz. [109.81.92.122]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c0bb1c5b39sm676803a12.20.2024.08.27.00.35.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Aug 2024 00:35:12 -0700 (PDT) Date: Tue, 27 Aug 2024 09:35:11 +0200 From: Michal Hocko To: Kent Overstreet 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-2-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8111420007 X-Stat-Signature: zqz74m3u8edjm34g1g39kgrfmg5pydg8 X-Rspam-User: X-HE-Tag: 1724744114-657788 X-HE-Meta: U2FsdGVkX1+KVr0rq7994UMdt7O4DA1lNgUQxGn+mmLnvT5hqd3Lo9ST6dDoID/BkXRXQc5pUKC0FcASdgOkKX8IISIa7nxsm16Nbuo8+OjdS2V081s4YIk47FQBz+82hACbZhsRl+BJ5w0TsrPjL7ZDNd6NUHF03400NqJkW5Y/95ggOkDV8kpmBN5404OkX/AV5WwIumMUVmJMggTt5AcE69ujofJDXlznDYz1oHcXprhJVKKzru8ArRBHxaj5HGoAbfNI/xgV5AD9SasqkikoekYKL7HjPiJBX4b4TheQBrbXvKzO3QTllWxcc6LwawSLKK9NcY7VLqT5IftYSpwGrlWKccJTRPWQaTO8QZm8lRHrxQPFdOj46VWHRCxJUbmzG65qDgpJBZzJB1H0yzmSWspv1l47UESKA5RFeu4N2tT2/d/YsnVOwH0KVdAWWAoCG4mu/tMGvkBQGuGuoKbMf8A075T5Xa9qhE2NunaNAo31QDJIxTS5S5qEcQMEoaFLTVT9RJNEpaJz/UpArAQgqJlh0acdWk5Pk3/BmemD7jU9VyWUi8aEvuJAwe9Fl0/4r63HmosXKba1N03CLZxQk6z8VcGNJ36o+iwSsQ4Z5g0MVGQBi2LpyF7sCCq2V4UBCUkA/Tj7lufS9h0hX92vFjXn/KnnaQpQR53ZxSDTmLLsDEFrPi7e0aGIWjcOBzkffo/R3gGESkxMEiJ8C5QbtGARYAIatQavoqfov0enz1sHaq9QLc6G/UEsUkSPlgphXq99m5UPXK21qq1A/AIBZTgNDoUSZyOHeWOcax3X5GEQ6LfCucavGBVr+1hGwsHQ/Hhz7asVy2H87YNLADvC8KzD+aohCU0cm3ynjdiBofyH2Up/BHk/wAjaOUUVZMZIWhWv5tIQW+v9Wgy5Zswa8lKG7fX5rr3bYyoe9l0W0Tq15WbZSnGEZ/NkNGZFEw5abW8op9aBgEx0sCS TJBvS5DK geinP1cWv0j/6uHWHfcKu4ft2wNKcFxYKlEVL/9Q7neVKNsVIWNW8zVyNAbxVR+5W4N3y7pdfJyqexl6PZsWrxh73dhfAQDeeA+MvMRwak+n6I5ON2uJ2ZRLS43ms/NLPufoxsDhQ8hipBaEovU2HTQZ5cluaQ4nJAynDgGvvi0CbD8DeFmKkPzPcLyIIJ1bGQBtURgm0xRzsn7/lam3luuWVvISekJmOg1xxPiS7yNkoCgj63ZOHerowPk7FLnRNX5m1o2/LKlTtTi7U4K67gwQOzG6wBfCc3ekCc7IF0asfRHvrxmDkfIUtfoexLbbOz3j5LCq0PlhNeZ2vhI1Zj+gceUfgpLsUwEtvqbpVCmEBiXzkBBI9DwvavtoJz4EoT+yhHoSWeknE4kLYJskRW6CUPQ== 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 27-08-24 03:05:29, Kent Overstreet wrote: > 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. Agreed! And GFP_NOFAIL for allocations <= order 1 in the page allocator or kvmalloc(GFP_NOFAIL) for reasonable sizes is a supported setup. And it should work as documented and shouldn't create any surprises. Like returning unexpected failure because you have been called from withing a NORECLAIM scope which you as an author of the code are not even aware of because that has happened somewhere detached from your code and you happen to be in a callchain. > > > 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. This is a runtime check warning. rmqueue: WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); > 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. If you use __GFP_NOFAIL | GFP_KERNEL from an atomic context then you are screwed the same way as if you used GFP_KERNEL alone - sleeping while atomic or worse. The allocator doesn't even try to deal with this and protect the caller by not sleeping and returning NULL. More fundamentally, GFP_NOFAIL from non-blocking context is an incorrect an unsupported use of the flag. This is the crux of the whole discussion. GFP_NOWAIT | __GFP_NOFAIL or GFP_ATOMIC | __GFP_NOFAIL is just a bug. We can git grep for those, and surprisingly found one instance which already has a patch waiting to be merged. We cannot enforce that at a compile time and that sucks but such is a life. But we can grep for this at least. Now consider a scoped (implicit) NOWAIT context which makes even seeemingly correct GFP_NOFAIL use a bug. -- Michal Hocko SUSE Labs