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 3C7DFC5472E for ; Mon, 26 Aug 2024 19:04:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DD5C6B007B; Mon, 26 Aug 2024 15:04:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 266286B0083; Mon, 26 Aug 2024 15:04:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 107366B0085; Mon, 26 Aug 2024 15:04:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E971B6B007B for ; Mon, 26 Aug 2024 15:04:34 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 92EC5C10AC for ; Mon, 26 Aug 2024 19:04:34 +0000 (UTC) X-FDA: 82495322868.03.EE01224 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf11.hostedemail.com (Postfix) with ESMTP id BE20F40014 for ; Mon, 26 Aug 2024 19:04:32 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=R+cGw2Tp; spf=pass (imf11.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.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=1724699005; 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=Q4Ic9Fq8l/YRsMsbrKHAvIEYDvZrJ7Rz8RzOxpo/lhI=; b=0Uitc7+mPjAceiaT9wOhzczxnV090d9rAUk56AqKm8TJ8kHWdxUteSCalqQ4dgWJ1fD8SX 6U5evOq2GqrSPNduQkOnYq9FJ4GstrgKyb3+7e03pfHi0vqbUD01sGnG0kqssjLj1FbDNQ ApqMRuUgz8S32wsijRIBtX1f/d/HYas= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=R+cGw2Tp; spf=pass (imf11.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.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=1724699005; a=rsa-sha256; cv=none; b=WjRElNgwHUfgQkyMe1osamHx5RJRe3jRPB32vlV8esfTaiktD+ViuVOncyGrIg5POpdYzO yjB05khfNMeSbNNn8LEj1F3UibINf08rfRJREZpYxsSTMj9py0/t+iPB1zWHDe62fdpbEE 7taZpSytYsGp/SVrRUUM5WIZ5kfdP4k= Date: Mon, 26 Aug 2024 15:04:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724699070; 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=Q4Ic9Fq8l/YRsMsbrKHAvIEYDvZrJ7Rz8RzOxpo/lhI=; b=R+cGw2TpUaJ84nERzAZm5TNmUYh7XrjcjIzhqMaWFPsw+ctPzCjwwcJhwJ7as4GwRQwOlS qR3JJ7MXwbLIpzIePIZRY5zfJ4VItwn1yj8RXDs7aFM2gP2EtGGX++FAMuv3bwLSvzAFc3 UAH+oBwr1sZn5+0OygfTSiLdlPrRnPI= 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, Michal Hocko Subject: Re: [PATCH 2/2] mm: drop PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-1-mhocko@kernel.org> <20240826085347.1152675-3-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240826085347.1152675-3-mhocko@kernel.org> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: u1mpahtowu6u5qt9i6fcrd59n4hxwanc X-Rspam-User: X-Rspamd-Queue-Id: BE20F40014 X-Rspamd-Server: rspam02 X-HE-Tag: 1724699072-913965 X-HE-Meta: U2FsdGVkX18jflXKwNYGp3z+C0/v16pdOy5umIzXl5O9/kHLXQe2VEDe3Yzm7Lop1SaoNHmaehxxVP15itE3xCRVOU5gLLp8cRIjsBc3jodAgeuoi474YnufxERR5Jj5jhTppYzHZ9z38+Nx1P1kKNJ6up0Jjx10AKavsC/H1d5s2x+QQp5qC0zqKgeqS2BXnHxbO62lvP7ToZn52ddLPaNT4DzL+uC45UPKLOUfATphhJBFPpaO57icWvd1zPXmMk5yersc469CbehIQ49Nx4EAv30jTwryUJ6V9P8206qHaFTtv1m34s0uWxhaEKPxhJf5f6t29vEdDXkUYoMIxJLfs9qE8uxnRpIGmjmr5PBqXTxdsunS+VDfFApyxXFi6WUGkIjYakvzdzUCh7TNQ06sNjhY8JG/Tt/sqzK+/5KwzQvnTF977sFA7TZtg/iZiA84OLkUy78q0T06QuTurLm9wzhz9Zw1SPk0Fc8WoIx0vcFijz2MIjadUl+shHnFAn8fXbhgAwfnxNP7C/m4npYA6bSqp4o19SVC1PACqs6i5fcfbzzB6cbU4d6Y5vym4Pkn53JAKF7oUkKv6ha8W5j4spDSiukOFO3Xhgl5Gr0h4ji1g/VwgJS3//6xqnR5gDM4Gl3elwyicgBdi7qgcvpAfBqX+HkOI5O9MclNAqaUkFVOtYmH8B4DHRJeQwb8qc1oyxKnq4ccUUhBPOD/fXWfJuYpafwC2eYsmOCmEo+hidZwYBRt4fhry49/ETk8b4AIUCl89yzHeUQf+CGVHtUyeMASYGLwBsQOvel3Ltmy03fQuKcLEGJg8+a7U9avx7yLHWmsSr32cOxy9fKN1A4dSzokoruaGaJp1g5EFNteVwDBvQlDmexaxe0bM0Gqsz6rFaDGbKvBb9ZCRKKvEfJukzWle53bSnWW5mqNGM+eLtyITUoS+J/PoQ38CSIJZYPGZBZrbPQHz7jI9CH FLn4QWIW Qp0fCLgGh/jQrJhn7yVndPmJxJc3Wt+FzgoOZWcwFRVakR1y/xSP3VLb5u4bO9EF5AewYXdaE7NPpzy6L2up4LscYESQCK7jY0/hiQXXQ4wK43orMtXvABMshJtp8FYAREyL9upxoW9fc0+HgJrwtjjXt2ScWwnUQSwzMubVaeX3NnD8T9Mpncw3cIPBFHiahvY4WKUsthWipjDAMgu/AHOPiypZaR4t31o7m37aSp4tXwuywMoSApV8+P188gef7AeS/j5VkOVgFXDRyx1h0CzlcrZNstpUESMkN2jixB7DadyY= 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, Aug 26, 2024 at 10:47:13AM GMT, Michal Hocko wrote: > From: Michal Hocko > > There is no existing user of the flag and the flag is dangerous because > a nested allocation context can use GFP_NOFAIL which could cause > unexpected failure. Such a code would be hard to maintain because it > could be deeper in the call chain. > > PF_MEMALLOC_NORECLAIM has been added even when it was pointed out [1] > that such a allocation contex is inherently unsafe if the context > doesn't fully control all allocations called from this context. I don't really buy the unsafety argument; if it applies to anything, it applies to GFP_NOFAIL - but we recently grew warnings about unsafe uses for it, so I don't see it as a great concern. GFP_NORECLAIM is frequently desirable as a hint about the latency requirements of a codepath; "don't try too hard, I've got fallbacks and I'm in a codepath where I don't want to block too long". I expect PF_MEMALLOC_NORECLAIM will find legitimate uses.