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 9BD7BC5472E for ; Mon, 26 Aug 2024 19:58:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 379A16B0093; Mon, 26 Aug 2024 15:58:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 303306B0095; Mon, 26 Aug 2024 15:58:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17DB76B0096; Mon, 26 Aug 2024 15:58:14 -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 E47046B0093 for ; Mon, 26 Aug 2024 15:58:13 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A82461C4488 for ; Mon, 26 Aug 2024 19:58:13 +0000 (UTC) X-FDA: 82495458066.04.9B8471D Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf01.hostedemail.com (Postfix) with ESMTP id A971640011 for ; Mon, 26 Aug 2024 19:58:11 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=WU+ENd0w; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.52 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=1724702224; 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=Xh14Sdlc2n6IxKjJ6RlYGRrhImnkQmnSBBa6O3qnYnE=; b=5sDKlWYl4VqvV0YVVsR2G3ewldHP3KUXUK3hhB85rRyTg1WcfkI9GxUc1E9Q+TsjfxoMbJ NEzzYfUyJHpZ0gNFWkJ6uPCfVuhXhUJDao9PWtplW+1Ks+hiTgazr53mnc02qZx607Xnfu rd/5iIa4iLPxD0FVVacfGxYmIGoj0t0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=WU+ENd0w; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724702224; a=rsa-sha256; cv=none; b=g6DV5Qf5nQ0JPF5gzBkM+vRhUv0fX+4S34q0Pm4b13WyLqKSVdlfYIil68ztyn0jGPeQCj k3ifivJ4glKPvICSjF6J+zbabqHzqQBxDVOQ1+spt6gpPQRfcB4ixwYWvvBp7btXGz7uol APaJSxcjByf6GoHzvSAg0dw53SZhWVU= Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-a8682bb5e79so626702066b.2 for ; Mon, 26 Aug 2024 12:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724702290; x=1725307090; 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=Xh14Sdlc2n6IxKjJ6RlYGRrhImnkQmnSBBa6O3qnYnE=; b=WU+ENd0w+5UsCR0ZZsFoE+f5PGZgI0ca6Lu2CII/FQCZfSSFh36iwm4jAd+hmrhwYB YmICmf9afhXNQEKhXsRayfhhzNgn4aOf7E5SjusX76vt5LmXsaKFK8rDf3mRuWH+SshL 1oKjvmNejFQWAalyElHo3aahPojc8R0mJncUSmxeQf1oC7kXqgb1WqVfpFD9GRN4r6ds zXCHmaucNO7G0eFymxUMjcO38hyPzm66PrMe7Tl+4MOShBGBElpluRk+HafqP9R6LaOG g3V7UEGJICtr2fqeUhoVpCbcoOe/9S9jMyyQ9WiFW/FWDUlpgRTCs4h+tlO4sLy8jRXk QDVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724702290; x=1725307090; 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=Xh14Sdlc2n6IxKjJ6RlYGRrhImnkQmnSBBa6O3qnYnE=; b=r9egLuyWPZXrDXNLdu/AQ/cHzcLkVGhqGxW2Jbr6I5BcuV5NOh7MUvd9Fd6vSKnv0p gGCo1UxAnkC8LGpQpnfGeotpC2bAXlT0BKJ9IPwF1CwoLbUc32UYyEyxqzacpiRZOhnR eybc79oeKvME3Ltn1PIPtkCfhBsNz7SL9/CWuk9T5fcMu7Caiik9wEbfAzqhZ1m9kEz1 kt0YvRmZCztTQAw40RaLCJcpiY9dfXeYBSvcyVQBilNTjWcEzkkwN6N6ZRamcnAX7UvI L4HFxm8D0IT2Wc73cVg7vOX2nLZMk7pjs/yHUSLyDcrgBEmwDnOj548iMl7PSOfLQMbf MRpw== X-Forwarded-Encrypted: i=1; AJvYcCUK448QkLtaKLScLYh2zBLxZtV7cLXT3HyvQnXRXhI4g1l3UhMn1cE77Fwo5L0MQC+LxBmyWLHnCg==@kvack.org X-Gm-Message-State: AOJu0YxXrMX3FNpB1OEXGcgyvVLDHSaTmpqM+bhD7CtjgfGIqYEx5CgA oao2K6blbsmBzqRCCtALTHjL2vddzsd+kIKasQnn4g4PtXHWlDhmEAx6joWz3uM= X-Google-Smtp-Source: AGHT+IEqLDw4bnaGQwfVtxUnt5R+nT/cvXOLGueUtNtCDMXl1cKCg9G27paLPy3+tFp8unGIxIOggQ== X-Received: by 2002:a17:907:2d8e:b0:a86:83f9:bc1f with SMTP id a640c23a62f3a-a86a54de2cdmr683406666b.61.1724702289954; Mon, 26 Aug 2024 12:58:09 -0700 (PDT) Received: from localhost (109-81-92-122.rct.o2.cz. [109.81.92.122]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a86e582d896sm13574466b.131.2024.08.26.12.58.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 12:58:09 -0700 (PDT) Date: Mon, 26 Aug 2024 21:58:08 +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-Stat-Signature: 5t9p8oq9fbfhmio4k7m173sxeim1rr3n X-Rspam-User: X-Rspamd-Queue-Id: A971640011 X-Rspamd-Server: rspam02 X-HE-Tag: 1724702291-776265 X-HE-Meta: U2FsdGVkX1+FsGAqojo4yfSWB2q+V66w10XsESh1+5bp/4xIKXQSjpjDjcKPq7S6OuiEgFD4XaG2/wpk8h+3o6LkkXpwLWE1JZ11wZ9oJQm2hAis1/fqymknO9Qzx5S8lKNyMQVw9xXQkge/R3/TehWhyUnnHDHV6LDAYTLsBrF5HSMN/M9hykyKGMwHXV7xkRRj8TxXQQjFMRrmp898ZLH5lcvdLBd4LlW1tspG6dOVQLwN+mgQ3weU7lj7RlpXgAPjD8XpRW3/1S0GpsE1pdUlMvTMVdqbuq7DKzCwe7+loAQJtkndNmOJrAiASTGo0PoGZjX1IcwSW6PLh+nIyBcMq1sqYL4A7d1dDSTeXyEtQL/K+e6cz13tIs4Y/pUcuXrs3a+xITqKW5psJfbn4DE0/WZ2fPZjPveBBSfyMGB4eIVQUqdzYV+fqyhMImWXnYQ4hk0L7T0inw4BeuyCMR3+NLgytF+yQOfjmBacreT+3rFAhs4XHLz5bqsD/ZsH7P9CjYkXuDPbKLRpEdIaUOpSdeGu9X7FeuAQ11qLUj6dVZ6KBTPzrDlLWfh+vUSqX5SjAclcck18isQeyqec67YaedGufZHVhSoifeRKtFDIIqr6NELczkypQcayGIaOGW2Eyszin1utjvUNKfkRZXeMH+4NMW9FFkV6cCcBRNubQLH96gpHJ4ZOzaW10cOu1hYIWZN7DQjxGXY6QB/TRohfxFsbtwGsDJnZyAxX+0SAmYDw4AhhBd/Oea8VrsUwoD/X5EZ+2anRV8JWrbQ1cNvaA+sQ2N4j+AgzQx2/ftVyrfhk1HRXEZ6/Hmlb0L7GjgVy6BtgzkOzuKfsIyBmUxWg1FWWzQniYXlVaBmzJVCTpTPN9WfJEnt7QlYuY3yn04sEzX44S9S1S8WES+LxZEkC+Y80/gQJz4u0M3V4ZrhDL8kFeDjnRDktG6ANYXehMCqyYkUyhR/bwMzg5M/ FDHx0pK9 bgL9qJBqPdhikn0eWUI5xrMB0g8VcIlWsk+IT0Xfj8ZHXZbSTmYeaKCahIuiJVi/P3puNh8LVnGw0QrjKiCRzu2uJ0SVEWv74kV+aX36FzjGJsL/7E1O37owZN6pAWPF9Zy2/4+U3eTYAvT4TNYVNpsvNTicwFtRThLdEeV6NEpRg8zJj8TlUP+fH4nrDzu3RZELYhgT43ze+M9l8LEeCQ265RlVsDCPtdZH/gwW/hQj4OWrQ2uU9vkVBKLPYgc8ifuVirvb9huBKPXnlEII0hEauXnHQfve5lc5r7nBPN4s40HihjWiZKtve5XJZFnw14IWQJaATaAWSY4dudWjpBYnKtCtySjMtaOgu+RyH+gBc1FdiT5gITdeLinez8E4UpxMA5Ag/foBbS8EUVGf6SrngveV/HHcFN+2RSmSrpbMtqAX9MIKNrFlhm2/g7ARx0UlifeKKvWmuF+QE/15HjPXZ4A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 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 Hocko SUSE Labs