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 75F54C5472E for ; Mon, 26 Aug 2024 20:27:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D20A6B0083; Mon, 26 Aug 2024 16:27:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 081AA6B0085; Mon, 26 Aug 2024 16:27:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8AEB6B0088; Mon, 26 Aug 2024 16:27:49 -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 C6ED46B0083 for ; Mon, 26 Aug 2024 16:27:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 85C9F121393 for ; Mon, 26 Aug 2024 20:27:49 +0000 (UTC) X-FDA: 82495532658.11.AF400E5 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf07.hostedemail.com (Postfix) with ESMTP id 8A53540014 for ; Mon, 26 Aug 2024 20:27:47 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=QSD8QVcx; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 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=1724703981; 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=Xm4/rM2Nbm4BxU6M6mgAwrLUVy2sx5HXqvLkcYe+2qw=; b=5BgbJjpChOe7DvxMbpqjopYJSwxz4yG4P/V8ShS8ZobejhXLDmlonD46w1Bo1ZTlwQSNoa n8u2MD0X8E4ma7fK+WiEDO8YVXPOTk9/Hl5lbPhZdncinlZw7aGlNXWEtEiG+JBtJaCssC oyQ/bJ6Jirp1sqQMInCeS71HRc2utjg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724703981; a=rsa-sha256; cv=none; b=KYYScbmyqcP8Gmknawj1xUz+YwQkMfo80NvAqrYtlbm4Ue2Npyf0qAn8VEFZl7ElJe7dJD T8KqQM3ycSsz/pgQa5U24ZY0DcJy1Y95X5TjynIVPQxolP2eXSbCbTz+Oi7NhwVDEZYj5n FLRfLpNVSCqOmtHd1NVRuBB8bCan/Sg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=QSD8QVcx; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a869332c2c2so706470966b.0 for ; Mon, 26 Aug 2024 13:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724704066; x=1725308866; 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=Xm4/rM2Nbm4BxU6M6mgAwrLUVy2sx5HXqvLkcYe+2qw=; b=QSD8QVcxtNfVsFm8pEuadPxKwk8zl4c2hEMjsigvrxDhG0iu/wygMs5l5T1NRnatzN dcfLXa6CA50cRQfgzejsF19uAOPqghUBCWzRoObRvsgpBHc7eZDKZf1i4sQdhm/7ULpK U5xhl4eSdF8FflIiFrI1UzC7z1DGm8axPN6+AZe1je6yGhY64EE44cstXCSqsyZ4us65 4Z6l1YaK2yANGms9tEalY5lvsOQfCZwU/akS0/OXtdLSF5ySuvnkwnCm6x18AzAk09Ai QRj1r3h1LU51HMcufu4L3Jqyk0/tVc8ZwVh3RsRxA1y3yXfx3IAS057dUIbkjGebMviX q7bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724704066; x=1725308866; 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=Xm4/rM2Nbm4BxU6M6mgAwrLUVy2sx5HXqvLkcYe+2qw=; b=tEBkJrVSvmj/fZaTHezOwKL391LPgcCs2Ac6tXsYAIfOd40nWNmWLqcxrxqFzmGyVR JVQRTAqPmwo2oWJya42PBph/hoirSDMJ993fUYPID+amHfY0Aj9jg0d906wzH1TCMhk4 IltkYxXKlmL/IMhTOK6susiNsPHMiHHmzC+/gRoOvNOTdTKLQ3mgUeajyrZRxQlSaIUq AlVZ9g2I3BEn8DGx/4zSsv6p/5oLx3SRq+5n2vK60GrRBm1Af49MXvvMvSOTvXnUtQGo mw+yAPM5iNeQ7ikP4906bb4Lbmr6/xvAEhgctB/J31663wNDnoYb5UAAt2XvZw1aV96K BHPw== X-Forwarded-Encrypted: i=1; AJvYcCVVKNDTtVMo8iAt+RKkb+KKWMdmEVvtilonMMM/w+mB6Th+DeTxo48YPttez4KlKflqjj9+FE4cpg==@kvack.org X-Gm-Message-State: AOJu0Yz7WS1uv9FLIHbEK3G4DkuaIIU8/QzsYMN6GLYHU2bA4ZBdQ7Bj N4iVZcywgfDVcSZee7YBAIaru4iajFuaeRSyJj8pq2QxBKotbmUwTvQruBWTeCA= X-Google-Smtp-Source: AGHT+IH2ZvTxn8FRBuIAeUAVyqlVMPlbsz0a4GJhJVustV8Wa4viBPRARgLwUA5BIC4e5Ivl5ZHx7w== X-Received: by 2002:a17:907:944f:b0:a86:96da:afb with SMTP id a640c23a62f3a-a86e2932824mr83954766b.10.1724704065932; Mon, 26 Aug 2024 13:27:45 -0700 (PDT) Received: from localhost (109-81-92-122.rct.o2.cz. [109.81.92.122]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a86e548624asm17353866b.42.2024.08.26.13.27.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 13:27:45 -0700 (PDT) Date: Mon, 26 Aug 2024 22:27:44 +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: yhm6ujyctgmtusgxb9hox3kfsq3rp6xn X-Rspamd-Queue-Id: 8A53540014 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724704067-681839 X-HE-Meta: U2FsdGVkX1/+0lYMh2sidpGNrW85/Y6evU5K/F1M0v3ul1oZQ8B7xbLI2Va5oHadxE/EeNbOy6p2NRv+FD/S18tpYpdNSTfieXvlmYYdPXiY3K4rZzubCYG5uFNjbrQMuXZIM5VU/4BP3l1+UrS9DzxGvZx/g8WDRxdr3vpZ/6rASPCiZ7o0/0kZn0RFULqKRL49e3uCdZ27IOXUl7UwS24iUXKYrTe20o+Y3odblD5BbTaAYHd4tZI5BOXdfwj+PaWYm4OLqGyFSse94BnjnYaVdz3grB8aJOoHrhhLuNiP1gmgKr3+ddBRT9EeXph1BWQbVSbctah6fEOrKaqSrXTK9SUbaPPq+v0ZgJK/TdZVycdghjVu0zalxZsPXteOu7+DxaMBIb7ldHziT7CtczqbmIc4V3ZYY4FEIV+vEFlmPZbWEiIPLM3WIMB5kDAPOIO5kmBs2GG0XDPVJDNNnJAzSC0redYFh4B1WuJC8fMm/OURbOQj0N9pa/7lONtF8BsjJjOd+PpeNEg9gp8uneYQLiVZfxFDx1xbzCmXU43fAkS1IsPfpzr1H3cN1bfyPbdAuWUSAiib4yuH4aP+5ZQ7lvlqG6IF03dhhlrwUvtERWJNu8cmtmAM0A4kG8Jhgpyv69h8kS46YOKJehCvUN9Qpy7t+TtyI8Ycv4D10zlg4a9dDdSJYz1U6S49HnkU7wgnTfCAJc/ulQ93Cg3siQCistHfEsEj2wHLVxuFfHBYXR9IHI1lbE6gON/rwP9vMufqSVHZlqhZ/iF3yVKdDUPVTw1ZVDQCMakJJ84qFWhEDY7bqHVqnDPopwjoI56tFp4iWdzPyvRD8sqwrgRYynzFJCPOYkU3RiStZMFBD9wbRQAt86JAxxPmaM1oMEdxZQvMEnCySfHaPADC+HtHlbVrnkrWK5mOJ9ThQaVJ1dZRMFs31233yGw7U2ZppT0jT4+zDd2cbDmzYY5D8NU Sa7bNuYG VAgEMGcxU0Bl+v/jHAtfQLOtfTcmrRCRkuGeUs1vYstw7n++UBXCZHxsN+VU15EeTf6pJb2B0kfbqp7+2TIO8E9dNa/1uvFnmS53HCKEbFPHPv5nuohcrtHZWdKiXUv+4y2qxACSf9WJWJgHpNUpVTeiE7ZsYeJchnJSClyt6UzW3oC72+Wb5PTgIqS2kynwVR9UjuBmCFOc6E1nUIhR5g0UzgUI2EyB3BtP0RqfRbKGXgOZRRst7e7tvckSByyHrGY0/J3bGO+TPJoJRrypBaA9YBOu41ikehzZoxo4C69tchYnSInqa3lzXvXnuxtWaShN964Fgwr05krs7In9rubJyw+sb17PjeIUZ174+lLOqF+KgGerChfOQIUnC5y/FoUtx/P68kYdedSax8cD86BhHyDx7E/jGI8RfIk6vC8up0qnJdeWh6nF5o4AgRFgKZ3CLsoOu0RenfBwazh3/I6PEVQ== 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: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. -- Michal Hocko SUSE Labs