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 48A92C5472E for ; Mon, 26 Aug 2024 19:47:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D846B6B0088; Mon, 26 Aug 2024 15:47:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D34096B008A; Mon, 26 Aug 2024 15:47:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFBFE6B008C; Mon, 26 Aug 2024 15:47:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 95C166B0088 for ; Mon, 26 Aug 2024 15:47:12 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 607D1A1392 for ; Mon, 26 Aug 2024 19:47:12 +0000 (UTC) X-FDA: 82495430304.01.A6F103C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id C51058000B for ; Mon, 26 Aug 2024 19:47:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=n0VnPxq1; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724701545; 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=hBFh3cA2kmH2dkDFxpJSjKEkaQyWfxc4ceQWYnieJHc=; b=46NRD3aIEghv9sD0ngF+s7F0SY8hH5dL09mnYu8HyqpFQBnMN4LgbJ7GdFen013xmzaR4D IyDbRvPZFb+6I+4quOQxsV5/LyhWO49YK52jmay+qNUawOBcVi5NOGr5yMp++IIgGU1Cb/ 0dA4tSH1k1uRZz8o/gnkYULf7d9prcA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724701545; a=rsa-sha256; cv=none; b=dDL1pQlsDIF88ZlnnUbAIOG3KG/Nq/XxqVwmS5NSsJ5O0K3v9ZstNI8+93dOO29cH67S+B VplhXMwMK+++c6yAiaqz1TCNTifMdkPRb4iQ0ndjwcojwO8TTCuKpPtR/ScpF69EiEHd37 VtcPghu+7crNMOpIqlbA+JCSoVs8Rcg= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=n0VnPxq1; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=hBFh3cA2kmH2dkDFxpJSjKEkaQyWfxc4ceQWYnieJHc=; b=n0VnPxq1/cHl3id8AuHRGWQFSz LfIfWHT4xoCyQ1o6oc5Ezn0NtdfxljghXB/BT2xy8DNoKM4K1iOSAACgo43JnBexawiQkax3ePXWs fWLn7C3ET0FeAqipbn3R5uUNKM1Z8sUDXRz8K6B2xi304aGgPDVRhmk3pVcLFWw6UNshrWE3Aq+bC zbELhyb7tZ0sLvIz8JKLR17ynZcG88rPjYM2+voXAPi+FzNbV833syhi/su7xlhy05Qrpt58+vFlT lJhObAZhGcns6yUUgH1dyBkIPgXICIgWwcCwuVaaijFDaaZP5o7bmt6zSBRZYjrV7VU3q3qpVxwGv 7vWb5Jsg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1sifg8-0000000Fw1N-097R; Mon, 26 Aug 2024 19:47:04 +0000 Date: Mon, 26 Aug 2024 20:47:03 +0100 From: Matthew Wilcox To: Kent Overstreet 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C51058000B X-Stat-Signature: o8gnnthpkj3oi57qrde6sq1n5mey7bqa X-HE-Tag: 1724701630-832638 X-HE-Meta: U2FsdGVkX1/I9lHNd0QXy9Q6KNS+ukp02NmmW8XygIiEJS4KSkR08trYMAW+60IPJJg3hpWjxBzHkVYfW45g1W5hHUpwvJgKfkqOSRWJL0SKJ/y8WoPrNkoQzTFtBNpvoqaA7tdCVPzY5b+A5lqMMFC1i1TJr9LLDxr6PqfmufX5NVuWIYNSV5EyXIyViu1zqhZFLKTJvODGSWfYSrBGNqY8jlY3MQNRNnkIYt23sP9CW5YlZUQ4mH2b6tGCL5PJOm6GKj8VS/Gh4h+vshyMK3ulrYfnQoCD70WDrPSYbY3oieFYDRxGPMCnW290YGf5eC4xljLgmMtRSZOxMeAdlQqQp+cKo4r2dvi7qF/0HsZYLadLrzAO9aHm0//sSuNNhrYE4A2zDOFR0JkGuB7FqrAvi1BXDr5x++e3f2dQy8TysKMu/Qna8GdB10NMxm+6hvBxet4dLGzzqUvshvXBGMAc/DYJKDQ3gAiDn+ei05+YnW/ZwMl8JZnVGiYZHykLtwd7XK1m/iXhXbC94xLnKDwKJo6T8wwN/nr+PnbaDmLgEUr04AsnS9lgNVEqn9wM41hEWfKyV+q8aUSLkIQkZc235ajH7xolN1G0YbxL7D7DS61gh3/IvFGMOzWl62r+aaMlcV+fLrg+2wfnSYxW7C57S3Tbw9yJ6RpmSOOZe6PrdrG5HyEtm6gL/PYZL2/QITFQBV6l+4vqGiR52QUwOb9DsekGBOqEzq+TyrQoFuIyOgKnqq9rEXN9mdVl/3ItMcRLsYAW2DtDjQi62doUx9pDssLvPuCuXJ2StLQTq/TCVn0uSPmnC921eI7gqviLDnmvqnasd36/iZT760ZNKA3vTLnVsNj/fBgJgQTHdL++kHgQJR42T9+69JnZGUqsM5+vZOLf/itxPnPkTCVZMpxJ8sDRfMPnpEdX7VysSj86FBPE0AZt7O5lhVzPlFj7H7n9bhMEzjHMa+pcrjw UbLmIyQS /Y3e99cgZLbXyL10EVFYYdFYEScdcMsGQwBHlfi7vjtWawSin8cJq2BRwcGw5CHE+JlLCKSRpIMEwTbe1Tvhj4szYAMcJRwYpFCIiwHDwjP6w1lunLo13hVIArFBGsDD7ObNMyIwwFMrzB8vgh90/OkS9vHxU1Xp+vuemIHVDp+gOWh49saOCq/0RnTz5k+ca7a2BJ7NVxTCyu9DHn55+NrhBp4R9fXXdWi1OWdFRVzKxAqDr4b5nSDcQOMzwl6qsEhY0W5QdnveIrUwadN2Zx955ZTQ6/afbQZYrff7Dh0Z5URu+qUFo0N/fZYZQyzkrX7YEebSPa5m3Yog= 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 03:42:59PM -0400, Kent Overstreet wrote: > 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. The problem with the giant invasive change of "getting away from passing GFP flags directly" is that you need to build consensus for what it looks like and convince everyone that you have a solution that solves all the problems, or at least doesn't make any of those problems worse. You haven't done that, you've just committed code that the MM people hate (indeed already rejected), and set back the idea. Look, it's not your job to fix it, but if you want to do it, do it properly.