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 4C439C7114C for ; Wed, 28 Aug 2024 22:58:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC4DB6B0089; Wed, 28 Aug 2024 18:58:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C74EE6B008A; Wed, 28 Aug 2024 18:58:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3C9A6B008C; Wed, 28 Aug 2024 18:58:52 -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 959526B0089 for ; Wed, 28 Aug 2024 18:58:52 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 095B04020A for ; Wed, 28 Aug 2024 22:58:52 +0000 (UTC) X-FDA: 82503170904.04.1A44B8E Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf25.hostedemail.com (Postfix) with ESMTP id 133AFA000A for ; Wed, 28 Aug 2024 22:58:49 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jO8UfRbS; spf=pass (imf25.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=1724885841; 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=/Y+KL6eyJT0WZ4G/3MDB1ADSECvGADNZEvjLZdjJmno=; b=x0qd2PcmbfErHKDneNqD91fo9JbzYbWOnbRLivQg4ZgWNfdvxDJZ49OAJ0huGg+1GAJVO2 ceDie/On6C2ey2Z6MDxeluMjOXo7ItrawF5eLXfZj3w6rwbQBFRMSL/syX/xKeGTFqDEqe ITj2VU7SIjCrdfHM5jW0Oj67NJIeaws= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724885841; a=rsa-sha256; cv=none; b=ShqHqvb48lUBYlNy39fkIofTi71f0VYr2iF6avTo8+w/fmdNd2tDZQ3RBWmgJ4ptHYuVGg 6zFrpl1AhnMulv6I1HAW5+cgPQHJFrqS4fO/EesmTgzsD9Xb8gmPynCVWLBY9axmwLiuJM CdUAiitlB4UZ554wM9jdLPXeHZ+pDNo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jO8UfRbS; spf=pass (imf25.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 Date: Wed, 28 Aug 2024 18:58:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724885927; 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=/Y+KL6eyJT0WZ4G/3MDB1ADSECvGADNZEvjLZdjJmno=; b=jO8UfRbSvTlKwGbGO1SWxPISd9Oifb7my57CV2jUzlCzyC1pGXTD1cRKeKbppb4YSPzsnj +V0QqcLpILXiMCfIX3WU2w59Td+p5SLQ3PGxy3I/HHbjmYTDMmG3ymMl8bpS5nOtnjOvx1 AkhGJU9hy6nK1v3V6HDAIJ2Cy6f5Z50= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations Message-ID: References: <20240828140638.3204253-1-kent.overstreet@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: fufawifdbdbcn8qrqg8eqi6cxcgkbdbw X-Rspamd-Queue-Id: 133AFA000A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724885929-934265 X-HE-Meta: U2FsdGVkX19Pnigk0Uncky6tvBQ/aQMXZsTs5F0EeeoVrg2g/rKBpFiu7Ab+ahJMEQ1CmjG7GfiT86Zhz1QCmWvbfddquvc7GgOJHfHjzszC1IdnKy/BQSHxXm5LcSj9zVRha48EIbOP5304GfJOLJbxhuCOQoV3sFhxFO2zFYLtkN6vRfzPSZlezMPAbHCEuPTMSEGAFuT0ymdNNWtmz+QWYHd3XcMnZV6CX29BVWsXjCjqUdazLRCmbGyCWUASp0JhECLXGWoWyQebZSkQfXQG8pbRZVbL1xbCQZC5WygDHmQIyOpR0U8V/DC6XUA634iPAx5lyKgMha22UsMbTA4GihyQ70UBe30LOuFlArk+FUigZv97MMyWpZvg2FIGEoZVYiT4Jd5j1nBkofQUz9ApvH9uBeTYSsVPaF33vTCsY+FrrckGfzSrQK3diefno7JNaJYoHPrrNEP964Yk5n6I6vtwUyuDrCZF+356aHPb7xIStg+CceZM1lYRiXC2h3psY8nLSJX37gTa/+TAXoztK3hkCto3mGXQBhplo9LW8ITaKT70bLVMDOTWLEX82aMK/XHd/6umZYyUsyLLBPbEbJUP0WDTZRexbhuceXvGAsDFhZ3A7HLCIfE60CDL8DExG/LMOVrX3yy3rhf5Y4t7Xuj3G7kvufZPnDxnyRfbT7keUQPF2ZXAO+brf/835nh7R1auG5uAZHYb2YB6occidjr7S2eb+zuIsL6Mx0C3Ol9woWkKiUe6AS1sk8TlNITEe4WZSnqnjfIc8RNUQPq3BdPIocSRUU1f/Xm1KGqlDlvWOij88ewjz/UQRUg1mCQy0S2UzkAnVWrzS8vA2VM91Oy3HgzVK7ykETB8xT+j8fY6lsaBovRMSy7EH7AChknDerf/MTKtaDiD7lRico7u/66WI3aGQAYZ8f2bZFh5/Xu2I2Fokpi7NVJe6D0AE1AD1P52VRb5ra4fqfR 9EwYO7SA lrw0NnlPW9tQD8XTM/T6bCpKc/khcluBNFPzKayeqD7XJDTgCZAMH1cddFIaqAmMM1yKbxB/A3PFRca6sxNjaYTWjQ9o/ckFngt/pQgs5ZTRQ6vEyIZViCFZbgiUw8eWx4lhmXI7DCwKf8uBA7JaMH8DLPe9DeeiBZH6ABLybuAleAdbJIqAqp8BBA2ci/uoq40y+ 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 Wed, Aug 28, 2024 at 09:26:44PM GMT, Michal Hocko wrote: > On Wed 28-08-24 15:11:19, Kent Overstreet wrote: > > On Wed, Aug 28, 2024 at 07:48:43PM GMT, Matthew Wilcox wrote: > > > On Wed, Aug 28, 2024 at 10:06:36AM -0400, Kent Overstreet wrote: > > > > vmalloc doesn't correctly respect gfp flags - gfp flags aren't used for > > > > pte allocation, so doing vmalloc/kvmalloc allocations with reclaim > > > > unsafe locks is a potential deadlock. > > > > > > Kent, the approach you've taken with this was NACKed. You merged it > > > anyway (!). Now you're spreading this crap further, presumably in an effort > > > to make it harder to remove. > > > > Excuse me? This is fixing a real issue which has been known for years. > > If you mean a lack of GFP_NOWAIT support in vmalloc then this is not a > bug but a lack of feature. vmalloc has never promissed to support this > allocation mode and a scoped gfp flag will not magically make it work > because there is a sleeping lock involved in an allocation path in some > cases. > > If you really need this feature to be added then you should clearly > describe your usecase and listen to people who are familiar with the > vmalloc internals rather than heavily pushing your direction which > doesn't work anyway. Michal, I'm plenty familiar with the vmalloc internals. Given that you didn't even seem to be aware of how it doesn't respect gfp flags, you seem to be the person who hasn't been up to speed in this discussion. > > It was decided _years_ ago that PF_MEMALLOC flags were how this was > > going to be addressed. > > Nope! It has been decided that _some_ gfp flags are acceptable to be used > by scoped APIs. Most notably NOFS and NOIO are compatible with reclaim > modifiers and other flags so these are indeed safe to be used that way. Decided by who? Cite the list discussion, and the reasoning. > > > Stop it. Work with us to come up with an acceptable approach. I > > > think there is one that will work, but you need to listen to the people > > > who're giving you feedback because Linux is too big of a code-base for > > > you to understand everything. > > > > No, you guys need to stop pushing broken shit. > > This is not the way to work with other people. Seriously! No, your patches and the reasoning you've been pushing are broken. A safe interface is not one that "does not fail", a safe interface is one that never invokes undefined behaviour - and generally that means it'll return an error instead. And programming in the kernel means that you check for errors, period. This idea that you have of "safety" meaning "we'll just conveniently remove or ignore the cases where GFP_NOFAIL would have to fail" is complete and utter garbage.