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 3B14CC5472E for ; Mon, 26 Aug 2024 19:43:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C70896B0088; Mon, 26 Aug 2024 15:43:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF92B6B008A; Mon, 26 Aug 2024 15:43:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A99376B008C; Mon, 26 Aug 2024 15:43:07 -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 8D4D36B0088 for ; Mon, 26 Aug 2024 15:43:07 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3A321140FA1 for ; Mon, 26 Aug 2024 19:43:07 +0000 (UTC) X-FDA: 82495420014.04.3A4495C Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) by imf16.hostedemail.com (Postfix) with ESMTP id 7D87E180007 for ; Mon, 26 Aug 2024 19:43:05 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Dc1AOO/q"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf16.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724701315; a=rsa-sha256; cv=none; b=SKjBH/gIo/8keWncB9cShbFzbOmGCnlvcw+kKXlhGt13GCEyxOSD+F/XcP97aIzf/wa57m urk7tsU2H8RbMNLOeZgD4Dgx8+pitS3XlmnBZ6u5LY4jcR8kuZr+PvNlZlTVjEuTMdpIo7 ZSVu5JpYzA/ZNLCkL/xN7cjZn3cUu7w= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Dc1AOO/q"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf16.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.181 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=1724701315; 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=2ZkPXD2IYKOfAOOldbpX3VURfwiKgu7CQydh9Ux0uo8=; b=y3b39m+HP7QDUmdS8e3LnzrZcyE8rXTaRdQrJM4hozYeOg1K/aKWyLyEmwDagarZhRWKD9 sPMKZg3xoOG7Irt0ZWPeLeaqJJLGqV3+JE62lFJeTVlGfj97E/9/92Hiq5fMqCgnu/NTss O4uVTnXzPxUYZBVfMYIX8S66djdKJWM= Date: Mon, 26 Aug 2024 15:42:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724701383; 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=2ZkPXD2IYKOfAOOldbpX3VURfwiKgu7CQydh9Ux0uo8=; b=Dc1AOO/qri2M8aPstAypVWRa+KJNmbPOTYol3+KKZhRV/wbhP6yTLSnGSpij/VarO3cI8P WIB78ZPkpJV2r3XMn4fhNj0JXkqjdV9xZQCW7GogWWDs1lM9E34n0Y1ubTtI8PeVLInCxj B24jIisCjGpZFYA+w0YUTrIaALfKue0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Matthew Wilcox Cc: Michal Hocko , 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 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-Server: rspam12 X-Rspamd-Queue-Id: 7D87E180007 X-Stat-Signature: q5tdroughkdisdqhwyb6epysz4o4ejm4 X-Rspam-User: X-HE-Tag: 1724701385-24761 X-HE-Meta: U2FsdGVkX1+tQYzPgV/+Sx5dOE0uqKxDDWsPgvVv5tJpZ9/VPuK/ZTEq0KztIO4LtkaUdLXrZQVYVbcN02HJ/iA3Ko+Ws3jjvZmUtl0rxsTch578+we6OVA+Twtdsq3YRON7txvJeDRdw3tlSYkUCfuzZq6B4qR9J1XMxydVnNUi/jxZonD8boSSUh2k1fMkoa+EbNDbbu/vXpxhJ7K7GkvVycH+rMn5jX1MSJw+AtcMkzPhaLm/urdUPj23/e4yGNC+fY2dHRV26CS+OFXhqWKKkrDqX3l7H9WSf96QhGvh7ZFUz4RIXSbXwoDxhsLmlmYdbDQywYWjPIykedXOBsKD9lEPCIMUU+k7F7ZsBUkU8+Xx5cr0F87IlRle+A2kRGvk3seIz9ANym7w0JYBZ2Z8LCn8wA7nxIDHgtxo55k2gVtuoo4bqfhTijEpcHcsA7tPms65zyt35wwXU/hBp1/Jfd+Mk1jR72XZiM3oZU9sjOATDfA53Yfz+oy1zsUEiZkB7WlmHXqVcXivWmiINFrX1mrMlmtHZolhPyHkxd7b2Ozj5+nVN9ZRYyesP35zwUK5V/0IS38Mne8osm1HSIi1oKe9tpXrROKcZJZcEWJQN6NkKcVUHCLBahnDPJec6qSiRD6WWLuPfjFxAtWN4XvLfikpAKTKfiLbQHMhpWspUcw5FRgE+qmbt7rYZ7XKv+QKVyYtFFMimn4A1wSquIJmKMHJSZmcHFA9O/RLjYYyEszjOiTGfKupO6s6VYiztyw7PYVjyCBqACZwYowtyOEkYsDFeDBHgEiiqDgZFegefYaVoBQvv7aP1Is50rnfmhdyRNjZQ0iJt3/+rANaQhR8080jRSJRCmSD0fW7nq4nglrTiqcnrTdDcrRRcp03/wVeBe+bW+3RrdhjiXJ4DOKQJqZjU5R3QUa3pQOR8HlINSM5XgM8YnWzgKkcUazJOhg661gCjkWXV/7xqTL zWlvhk0r dy/TVAnCxZ5+3k5p8ul2vQxP165BuYPEYyN9AdpoRDotPCXGeYr+yCKus8f5ImrGnlsD4tBj19CHLp423B+g3nqrujvdF0zqRnsaevC1BgCJ4DBBefwHynSWA0H0Olk//zHSCmfo+yxZdrgcC7fRg6aiLwxRPhKSg/fppYG/jHIH0r78wIFp39WcBv765L1mBRFivQvh1okUu/282VH5yQw0MRaPlDCXC1I+cMxW+1TiKtq+prj1TWyIcZQ== 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 08:41:42PM GMT, Matthew Wilcox wrote: > On Mon, Aug 26, 2024 at 03:39:47PM -0400, Kent Overstreet wrote: > > Given the amount of plumbing required here, it's clear that passing gfp > > flags is the less safe way of doing it, and this really does belong in > > the allocation context. > > > > Failure to pass gfp flags correctly (which we know is something that > > happens today, e.g. vmalloc -> pte allocation) means you're introducing > > a deadlock. > > The problem with vmalloc is that the page table allocation _doesn't_ > take a GFP parameter. yeah, I know. I posted patches to plumb it through, which were nacked by Linus. And we're trying to get away from passing gfp flags directly, are we not? I just don't buy the GFP_NOFAIL unsafety argument.