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 D8555C52D6F for ; Tue, 27 Aug 2024 06:01:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 483F86B007B; Tue, 27 Aug 2024 02:01:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40D336B0082; Tue, 27 Aug 2024 02:01:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2ADD96B0083; Tue, 27 Aug 2024 02:01:40 -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 0BA676B007B for ; Tue, 27 Aug 2024 02:01:40 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AC4F01615B8 for ; Tue, 27 Aug 2024 06:01:39 +0000 (UTC) X-FDA: 82496978718.14.627BEA0 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf21.hostedemail.com (Postfix) with ESMTP id BD2611C0007 for ; Tue, 27 Aug 2024 06:01:36 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=M5LA3O1S; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724738411; 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=2V26ymBzYP2Z7GWKZsLXO+lAp6n0aHmQIkOVXPd0pbM=; b=gBMJ4g5PGR9d7eSzc7UlKJj63/jtzuz/knZnPWOMBAXA4btEW008OWNH8g2Wps+IdPrs7L 6g6yeDMSdQuBRBtQV5baAvCi3wqLF/y6yBV3UY2XjMpqcrJ11DwaEEoYizrGRAL5D5RbpH OxnHFA52r7Z2uIGIGw1+mwnWBDwb2p4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724738411; a=rsa-sha256; cv=none; b=tX2kp+e5KUj1ffHUQneuL1r4fUYAqmkru/Wv7Do0Idvn6+w2rj1Odsw0ZzFy9lP5HW0p6v 0SupkiBzObXuVuOepmqj7bS/8Nf/374t594LZcgLe80YQPy8rk63Z/d596POgSxnazdI/y YQa9/RtfOXnaec1QRhIf8e2tvtL1jxc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=M5LA3O1S; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5c0aa376e15so1063484a12.1 for ; Mon, 26 Aug 2024 23:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724738495; x=1725343295; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2V26ymBzYP2Z7GWKZsLXO+lAp6n0aHmQIkOVXPd0pbM=; b=M5LA3O1SAsuMaQfr6NjCBDl2TIiA9b183F5jV55MMdot9CsW4LM9kqIf6WRd3MA2Gq //3KvI4kl6AjnPAthkfvmJFmbIGsCd1Z0D/bVg/dcU5GO0nyKI7UXhB58gKtz+i36SRw 8VZhMzPADRhJpikT+kheR2nPxj26lENbdszA5X8oRLMkK7EWNSjtfb3U2oEZcE+2Ol2G ORUUbfB6XoXscn1CHOmPn23EweJAJ0u77xK4j1YT5h6+4NXLkIWCL3kEv8OGStCcg9/D grZ0pHrGIycVdLN9OjlMGhNxUoYGMt3i8lUtqoNhnEpNjWU1DTMRviLlNa9n+HJDNnsv ty+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724738495; x=1725343295; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2V26ymBzYP2Z7GWKZsLXO+lAp6n0aHmQIkOVXPd0pbM=; b=GR+/rcgYEJ1gf0DmBHtdeuB1T8j3zQqZJ3Ih92zRzh6Lowk7sJhLpRRt4UHMMAve2b fk9Ck/yoVLrs+8zM9BYoDmwPm810SoTVQ2Vw8BqkwZIaDGJlhG8bebPWlCSM7swOe4ol 5mM/0+3dtshMU/u9IyKnRdx3x+y2Q5LPp5NexQX33RZL0QdAG4puk1dXOCX3Nw8j8Mf+ 7gsEWsRm+4o6pS9gR1myMSWNB9juzsUB0VP1FwQrDPsj+K1hLyJNjEW7OWyp4meDiHiS 5L1T+yeYHUmDV1bveBGVv/teOmDU6zAelkCYxHeeJj+0u8aof2LtZv4nNvbPDQDGD0Ma /Nfg== X-Forwarded-Encrypted: i=1; AJvYcCWHS2ovWsnBkrplvfTrKlGVFt72V1kMqsdZqG29dgOCsTR9h8JRMfWse9HWiVytINc06Adh9JuB6g==@kvack.org X-Gm-Message-State: AOJu0YwpeO9QESjjC8k9uZDc6hbgqa/1PL2cFYcv3YUEIO0m15ga04GM 4JvT7nUHjmdxquG5XyjoMLk/EBTEuZ5BnmiZpbB9D681uszDi+3LcE8SD58W0NU= X-Google-Smtp-Source: AGHT+IF2gqL09d/X0zV5rFVkiVrS2Z5bbUz8sAze/K0DL8uePv7zb38gZRMFPwimQZSTcgTR1WWbYw== X-Received: by 2002:a05:6402:26d3:b0:5a1:2ce9:f416 with SMTP id 4fb4d7f45d1cf-5c0891b4825mr11035852a12.37.1724738494768; Mon, 26 Aug 2024 23:01:34 -0700 (PDT) Received: from localhost (109-81-92-122.rct.o2.cz. [109.81.92.122]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c0bb1c5b39sm602082a12.20.2024.08.26.23.01.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 23:01:34 -0700 (PDT) Date: Tue, 27 Aug 2024 08:01:32 +0200 From: Michal Hocko To: Kent Overstreet 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-Rspamd-Queue-Id: BD2611C0007 X-Stat-Signature: u1uqg8s8yyb3mgtjnndgc1an81y7qsw1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724738496-990868 X-HE-Meta: U2FsdGVkX19/q36FQUoKQ054KIJMN6aQvS1KhvAaORBWEVxGNeX87/VY3IJD0YqCXdLXyvxsHzkh0ToIil5++tG4jCbcU2ec+Hl8TQSK2KWC3xtU0TG94Z7Or7jQj7MbRrp70MUjPNPEH6m8GfhCb1uI1Im2diibNCXbcGMzCtTtrUACyKUjMtsbxXl9VZ3AUw5YATtQJQwnDXQQToD6NC83vwBxNon4cTlMBahf5S/BS1EiaU5ae4amedKpS0bepXx8PVCr8JxSRPqOahZ+lV7PZ2BAOcaWF2WGMccklbNR1m24UrbMWgkK/KbKxAIroe0N3J85twZFwNC68qYLH2bzS3fyBaCXpi4VzLCc9+CHMNqxnfyC+zOmoO/8YfZO1hpnOETmrUu5wl/TYoI3mnWqXk3GYGinJI+0Xrm3Ta3kd60gntwC2l03SGWiO+o0xqPPrCkkAKYNZGJLXK9GNT/mb1OvwfqT0eZvMaQZVPUvJHgsSAjET6RWE1PcpNeHm9IxAdb8ceBP+NRes3XvDoIWks60g4gSuPLHV8c3IZmDuxATWISqJKihtb48FZDkJCJpTmT0A3T0VcgnFMr+6rx8YjhpUdzYCCNUYS9bGakIvIf6p3vt6VCnVTsAA0asT0pC7UJIi3dZDwrMaTpEzv3HxV4jmUB4Xrx/l3Th4dlO1ggnpudw0RPRRN/C29gs5B5gB9ZWaMi9crvdDK1lIiWmJFKKhIXPJI5MSEM/Cj0d6X3mpqaNgbqTIUJ63p5ool7f/924zxn8Q/kNuAk0udjc+vj5wPUPk19MLK+XHy34yKW7Ln1H3pcnBy0f1dKKVoDBK+dmCQSkS3nIvY17pWNvFRL1CIJJwDRTNVNXjkOPuKIcwXgEgnmL2YcwYsAfbNShYdhswy2UO6X8JZJbw0oR2KUcS1F6C+nrbei8STL/ryM2BBkdLuNl5HV1OSc+geB/77zF78mTmH3SKh+ ecelpww6 aAvpIxYMN0qnfAGbbFyohEjfjCwwIiioePsXg7SSifzMt3Yl0SriWJNv4oJN2jA7IQsGyDEhEyEhzC5b6kDp/+Fix17ko5Cwha+4i3GANdWVoQVhEka0dzdlboIoUVdwijl9Uo8SllhkTdyvlKS2JesOa3o7KIcqK6nMpSVUEpM4AXRin07uTNNR0RJYkd1zWL8f/UbsdWWyOeuOP3FUZHwa41bmG2jVDDzHdNuIa5GoLRnM/CKremNGeWk4+G+X65NLtUQhR3hbPo6c739P02lnYZAXWgO2ga66d9/eXGrFBsWy3rkO14OELCGkRe7XpO0bvy5xSFg6IuxPM331MstayhVgtwQQZhnVfm+3RRyS+fHiRE1Opqx5yJdJzyBKAGHk8L0C277OLJLe2Cnlzi8YAv8EVxP1tgm/iMEvFb/Q31klvrwO6ofUnMs8bD5C9fiCwv+xaE8zmO2LYZkgPqvKhGQ== 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 26-08-24 16:43:55, Kent Overstreet wrote: > 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. You are not really answering the main concern I have brought up though. I.e. GFP_NOFAIL being fundamentally incompatible with NORECLAIM semantic because the page allocator doesn't and will not support this allocation mode. Scoped noreclaim semantic makes such a use much less visible because it can be deep in the scoped context there more error prone to introduce thus making the code harder to maintain. I do see why you would like to have NOWAIT kvmalloc support available and I also do see challenges in achieving that. But I completely fail to see why you are bring that up _here_ as that is not really relevant to PF_MEMALLOC_NORECLAIM use by bcachefs because it demonstrably doesn't need that. There is no other user of the flag at the moment so dropping the flag before there is more misuse is a reasonable goal. If you want to bring up vmalloc NOWAIT support then feel free to do that in another context and we can explore potential ways to achieve that. -- Michal Hocko SUSE Labs