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 40880C71135 for ; Thu, 29 Aug 2024 10:02:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 730F06B00AF; Thu, 29 Aug 2024 06:02:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E0F66B00B0; Thu, 29 Aug 2024 06:02:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CEFB6B00B1; Thu, 29 Aug 2024 06:02:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 408B96B00AF for ; Thu, 29 Aug 2024 06:02:44 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C477A40AED for ; Thu, 29 Aug 2024 10:02:43 +0000 (UTC) X-FDA: 82504843806.18.E14630D Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) by imf27.hostedemail.com (Postfix) with ESMTP id E64FC4001A for ; Thu, 29 Aug 2024 10:02:41 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=dBfg8s78; spf=pass (imf27.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.172 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=1724925692; 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=vCHet4RZcs0kzetPKYvg5pHpi0wGxVpQFJgUua5GPMM=; b=cFacaFhiCC31XWyGrLir4a+YFk6zo9K6oIcipjlgOKpN0/jnzg9X/qPtZvxzGzCCwANvFO VWKkKQ+nfVnGiVQcjBj4wfOOXj1nXBCfDD1175S8KZi3SLAV2UJ/WfBTJ4cs/JLrrsJCAi HQASOdcljRbdIUHtI+oJLyenM4U74ow= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=dBfg8s78; spf=pass (imf27.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.172 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=1724925692; a=rsa-sha256; cv=none; b=TfwDxcHXb27rmAIb0xZkK1li84efjzx7Sjchiaq2o2OvxcKMOqOzca4Rlxz5D9iuIg7Ahn uNOR9k0LijOEj6r3I3dGlHn3Y/l1ZAEvk2CfQB3sa6iKly4KLgmL9jwUpqX3Kn1ia+eb0u opKYTQnxsgIyvynuPj/JX3biECA2We4= Date: Thu, 29 Aug 2024 06:02:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724925759; 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=vCHet4RZcs0kzetPKYvg5pHpi0wGxVpQFJgUua5GPMM=; b=dBfg8s78XD0nKKh3fhBzSsLjvpxP0HZmNBFpY8rQfHhOjWt9wcWxj5eRjCuMaRb4l/mbX1 fOrnuwxhjP1j+pTPiTiS684piwt/S1W69rAJ7g5aESrwkXPWBZrRaeO1AIPwJs0mFQAAlr brODC8Os+KdfdyG0h5OGTXWwEUS07JQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Dave Chinner 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 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-2-mhocko@kernel.org> <20240827061543.1235703-1-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-Stat-Signature: faw5dtu711pwuxqy454bhn3g88m1scih X-Rspam-User: X-Rspamd-Queue-Id: E64FC4001A X-Rspamd-Server: rspam02 X-HE-Tag: 1724925761-35408 X-HE-Meta: U2FsdGVkX19779wZVdSN25jqK48xY5coPIZ1ZELd7R+9Ol84y1s8Ozz7wdzMipkWBXhqjZMXStW1haF6Z4tqf/G+PGaQqw/dfuF+iQUWxx74R7eP6Yzr71+s7vb/0jRxVHEU6vv4cxfdKL7It27Byo8OOD5o98l27Z8gIat75b4kaNcfGc9cOWhNmkb+7Sg2viF0kWvtindW9JZPMNq1KyPEEK6lFr6fFzHbAVVimDT/k9WOJwHLrG4SR6XF0p7cphSgI4JmfcSYZNwuBgQZZZNZhHeJCGR1dDbA5B6gDkF4cX2eN4Gnz7hwnAQ/zhIWneokTyRv7yMNUzMKNwlrZKQhxwB9CXz7PcKpfcA4UQP7J2jfdMfTqHTad5eobkzCa0nQKKu9+zfHkX5/s/u41inEvip0BOb61X/tZin7FcQGIND2iafY8HPM6Ye8p9I9bEziODtXaBlBOsVUZiXQD7I5pNRQ6VIPxhoDFpeGs5P1N5b6wqBhcx//udS/h5ovQFKNif4qxA2X5+fuQ6fQJR2fW32KRbWNWb8w53lnEhTQ9DE87cZaX8vPeNEUuZu41kqosliGQqyO5VYg61XdQbX+LEu9sNVWhRgzuUFCvu5p8qHiB3xRzaGASllhEVUvxWsXKmk/hB55MSBIo9lVmNHZHKkDiW1qFTnlQqVUKH+Kx1JJEWdG3IWMQmfKstuvgL0dlb92WsWZuXxxNTd60ey8l2/TsHU80Fpox3rYsEOwMh1lzFnN8PgBrW2dN+CTxNSIjAOFSNp5jd7E/26GTqn3OSdOMEh9R3oqTxKHXBSGOSm+CuoKD/fYNe18/FO4cFv0DippAybov2PQOK5VkcTcMaT1pZHDrA8MdsK3f6TQwEC3SDdKLpblNhPlj9c4SSviCOBYq1SoeaZSu8p33FtyeYCJ8MC7Jvrq0sMFMIZvX5ICoZtTI7cS7lk6CceAfB5E2ml1Pt+xK7eo4C4 kuTcl/bq iTsHCC0dZTfcOCpa0RA+Z1nSZhb/ZbaAptxHUuLxNljj1ZcIuZ6Fs93ln56lcsVsOUTDyPOs7Xc6ath5L4fNk2k1wj6COUjaBy+wcbylJ/Ll1gck/phQHXjGcOieek3Or91gfjjFqomZP3JhlKCfBxKod6AG2Xsk0A41Y8b/lkC5no31C+jyYWDtTQpruLU0MCalBH9Qd2Xg1zoZ6WSk/sb1nL81LuVFrysXtwxQb5GTfFNWyO5VtRjIfC3ZH1jkd9tpa26xJ8fo/Hc5NmiPgxnMAf8OjXbKe882x9XwJqLQm4PyAUoAcr1r5WOKg9SuWNXi6yv9vKIOnMx6UVEl+eNsOfaXopFjnFDYj 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 02:09:57PM GMT, Dave Chinner wrote: > On Tue, Aug 27, 2024 at 08:15:43AM +0200, Michal Hocko wrote: > > From: Michal Hocko > > > > bch2_new_inode relies on PF_MEMALLOC_NORECLAIM to try to allocate a new > > inode to achieve GFP_NOWAIT semantic while holding locks. If this > > allocation fails it will drop locks and use GFP_NOFS allocation context. > > > > We would like to drop PF_MEMALLOC_NORECLAIM because it is really > > dangerous to use if the caller doesn't control the full call chain with > > this flag set. E.g. if any of the function down the chain needed > > GFP_NOFAIL request the PF_MEMALLOC_NORECLAIM would override this and > > cause unexpected failure. > > > > While this is not the case in this particular case using the scoped gfp > > semantic is not really needed bacause we can easily pus the allocation > > context down the chain without too much clutter. > > > > Acked-by: Christoph Hellwig > > Signed-off-by: Michal Hocko > > Looks good to me. > > Reviewed-by: Dave Chinner Reposting what I wrote in the other thread: This series is based on a fundamental misunderstanding of what a safe API is: a safe API is not one that doesn't return errors, it's one that never invokes undefined behaviour. It was decided years ago that the scoped APIs were the better replacement for the gfp APIs, and they need to exist. This "GFP_NOFAIL exists therefore we can't tell the memory allocator about situations wehre it would have to fail" is utter insanity - it's the exact opposite of defining a safe API. A safe API would be one where we /did/ always tell the memory allocator when we're in non-sleepable context, and the allocator always returned failure instead of context switching. This is utter brain damage; rule #1 of kernel programming is that _you check for errors_. If you don't know that your GFP_NOFAIL usage is in a safe context (and that's not just memory reclaim context, it's also the size of your alloction) then you have to check for errors.