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 9D353C5472C for ; Mon, 26 Aug 2024 20:44:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 12D6C6B0085; Mon, 26 Aug 2024 16:44:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DC506B0088; Mon, 26 Aug 2024 16:44:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E70FC6B008A; Mon, 26 Aug 2024 16:44:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C43A06B0085 for ; Mon, 26 Aug 2024 16:44:06 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 347C6A13A8 for ; Mon, 26 Aug 2024 20:44:06 +0000 (UTC) X-FDA: 82495573692.13.FBD4255 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf11.hostedemail.com (Postfix) with ESMTP id 45FAE40006 for ; Mon, 26 Aug 2024 20:44:03 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="IMQNyr/Y"; spf=pass (imf11.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.176 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=1724704957; 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=m3mziorGpfLu3KYeI2tTjbhb2E9xHhtNxzP0Q319XOE=; b=g6H5xppHnTA1bQHImyj1rHSDGa9WQVR6vup7Wlv9cBGLZFyDXFIeCYvYLFA+feja8a0eaf jnZK2h2JmRLqwTmUo/FmqRswrLpdVdhxq8Q2I733Aw8KwLqEdNeL6edbXAXKKRsCRr2Dk5 uoTlH6qPoNjv25Tqqh4q8kVoW8OBFM4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724704957; a=rsa-sha256; cv=none; b=FTYxGZs4HfJyN/Ztggr5HBtlh1Xi6JH/W1+Z8RrM0U9FZOPnLfEKm2TyYN8ucEOH/WmE3o tPRFnf69F6txJMokfc9UlM/Y5O4y5iZUSlsn286d/1SZHe6acTkYF16aQX+zumElrm1icD XeYJRCzsOkopyRtgOuaaXI9FtRouxCY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="IMQNyr/Y"; spf=pass (imf11.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 26 Aug 2024 16:43:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724705041; 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=m3mziorGpfLu3KYeI2tTjbhb2E9xHhtNxzP0Q319XOE=; b=IMQNyr/Yfrw7mrlXHINKQ6+WbnxF7kjT0GNIQ+5K0r/LujubHRZQqydUaRWUhoK+Jf26e1 0rrJmuHFT6aJE8CQkcs0S6v1p5oH22dsWsxKHOGKS9FsXLFplyLzkJQZ3I4zhI5APvcj6Y mJUK0eBicp9TRciIt3lPPqb1WQHjkDo= 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 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 45FAE40006 X-Stat-Signature: 6mpg1udxnfq33ekma9p1ix7ga8wuq45f X-HE-Tag: 1724705043-787342 X-HE-Meta: U2FsdGVkX1/9Din6mMwv/2swn2wTZn7AQt4Ms2RBYDxOzR+wPvtDp7ogi2y/YXvyFDtu199OlhRtkuj5DuFM4Obe03UDtndNokaFH+SE1mKYxh2WzKAavTyt83bMH171Rtq79qA0Pkm0R+oJy8zTQKb5pdZc+u+l9HH7H84rwR3tJIbDpQq5O2SkOcTLyNYJeGf7eJjpQ9cA6zHzi7ck9Gm5kSmbfYsz+n3QtUKhYsbWra9Inc/1D1wyPeSbzCeW8aK5XIwtcQ2b7gUEYmHHChBWj9+yzj5BFkktZlPnaVSgTyf6xLya4eRtNzah8xdnQ95fbgLLoPSuZN/Y6N9yn9x1CcyRFTbyA4EXZYrEcfcPIC61H7x4owx2sz2Xxb+lUcHYZx21w958H4UXOXJED5jAhTuni4fMpIpNGnTN8jmrvk3ua58dKMDB7UQRReefojf5cFeAbWdkG+0MRguz+l2tEyCzgpW6Ji8GOBeRTm0Jlvu8v4vhIxQOzYCT/luupM9Tu2E+tBBjuB/ZJpxKk4+NUruXqEzX9EhAzuuxqmuLhvv7jmE7N34vMUDLTdK+0tSQnZhpSLfc2BMjFb9BpEY2yevfzMCZjDSH5S9KNH6Fj/2chIqR9Fx2TDXziOEo3uIssYsNzqC6R2q8Ak8Cbn6WnfGW81fRUbL8a5PwfMdPOYdq0cx3kI7lzBDab1XSal6nVfNzNxnGv1DYbGd/hAYgGiFsAP1T7rvvVljpXrqQCS4gADcl6y33kMRccshSmsY2z2YwYNAKs7SsTX8WZQqhsE47aFal3y7so5gOgUggQeFFhkqWBHwfKt+b9aN5mkhAaTLvddvd7zr7C8lYW4Rr+Llekvv1F1ZfzoJYpeZTbuOAGHpaO4SxQGiQ/Pnh1kb0gg/e8hX7rIW9/ThwgYEFHUyHpD6wtdVZPFLOs8ACkDdf4U4hbWapqtVrMWyPd23ixRXoW/w5X7kLvB+ v7XM3evg yXccT7VQ/ZOyai5cDUWmEMJSc+7RXGJ9F6/fHWoeR5SvFFtL5UjSSQyhxnjUZl1nHWdqiPweEnSRNS9+iZAuBeiFrj5tA3Tpa44foSjQr/1Kb07mbAahAF/gG6Tyo0RljPrsFpnHjjVTlOcIEv9IeEAiHfiJMGEswlSIrcHcBTneEABuRgqHnFsg6qQBYqGDqv14oAjOAXxX4taYtHW98ItCvnWvXqQFVBZjRSttNe0lffeAFYRn933F+Zj5o6rAxrG6GsHjregR8GvyL7gxgZuPlujarlU6rFuWP5SgHzB/m+bw= 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:27:44PM GMT, Michal Hocko wrote: > On Mon 26-08-24 16:00:56, Kent Overstreet wrote: > > On Mon, Aug 26, 2024 at 09:58:08PM GMT, Michal Hocko wrote: > > > On Mon 26-08-24 15:39:47, Kent Overstreet wrote: > > > > On Mon, Aug 26, 2024 at 10:47:12AM GMT, 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. > > > > > > > > yeah, eesh, nack. > > > > > > Sure, you can NAK this but then deal with the lack of the PF flag by > > > other means. We have made it clear that PF_MEMALLOC_NORECLAIM is not we > > > are going to support at the MM level. > > > > > > I have done your homework and shown that it is really easy > > > to use gfp flags directly. The net result is passing gfp flag down to > > > two functions. Sure part of it is ugglier by having several different > > > callbacks implementing it but still manageable. Without too much churn. > > > > > > So do whatever you like in the bcache code but do not rely on something > > > that is unsupported by the MM layer which you have sneaked in without an > > > agreement. > > > > Michal, you're being damned hostile, while posting code you haven't even > > tried to compile. Seriously, dude? > > > > How about sticking to the technical issues at hand instead of saying > > "this is mm, so my way or the highway?". We're all kernel developers > > here, this is not what we do. > > Kent, we do respect review feedback. You are clearly fine ignoring it > when you feels like it (eab0af905bfc ("mm: introduce > PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN") is a clear example of it). > > I have already made my arguments (repeatedly) why implicit nowait > allocation context is tricky and problematic. Your response is that you > simply "do no buy it" which is a highly technical argument. No, I explained why GFP_NORECLAIM/PF_MEMALLOC_NORECLAIM can absolutely apply to a context, not a callsite, and why vmalloc() and kvmalloc() ignoring gfp flags is a much more serious issue. If you want to do something useful, figure out what we're going to do about _that_. If you really don't want PF_MEMALLOC_NORECLAIM to exist, then see if Linus will let you plumb gfp flags down to pte allocation - and beware, that's arch code that you'll have to fix. Reminder: kvmalloc() is a thing, and it's steadily seeing wider use. Otherwise, PF_MEMALLOC_NORECLAIM needs to stay; and thank you for bringing this to my attention, because it's made me realize all the other places in bcachefs that use gfp flags for allocating memory with btree locks held need to be switch to memalloc_flags_do().