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 9BCD6C52D6F for ; Tue, 27 Aug 2024 06:58:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 322216B0092; Tue, 27 Aug 2024 02:58:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D11F6B0093; Tue, 27 Aug 2024 02:58:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 198F56B0095; Tue, 27 Aug 2024 02:58:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E8F3F6B0092 for ; Tue, 27 Aug 2024 02:58:43 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A8277A1650 for ; Tue, 27 Aug 2024 06:58:43 +0000 (UTC) X-FDA: 82497122526.29.089C205 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf20.hostedemail.com (Postfix) with ESMTP id B7FB51C0017 for ; Tue, 27 Aug 2024 06:58:41 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=M7ZCczfM; spf=pass (imf20.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724741878; a=rsa-sha256; cv=none; b=IZloOn2btez8xvmyqoje2yOSWG6rm5RM6n0CFKKkDK0UwClhRYlpZIRSyGF9evl8cW1il0 iNPxAE6IZBVZL409D/iVLmaQ++QMf4G3QH3fhdUnDF8qZ9IdiXa9+Hb3MTYncKjV+u3vWg 7FjR7gZJH3l7Ef+2UsXYtTDHwZtDJZk= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=M7ZCczfM; spf=pass (imf20.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=1724741878; 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=ZY9iE015kjWusc18TRiosgvJ+Wsi74GjN7yQxl/1tqw=; b=cnD69YBBd1WnC3Ovb1sKJHT1ZyCoKm25oQXK0MXK6vmcsG6A+MbBgvbqqzHXcHZK/r+1N5 BWNLlgPlksxU/571KXM25gABsv5NCVjPdJ+K1JWPbHBUU89NqicTaBe7AsitbRUT66jM/j SGvTydrbtNQ8Qyb7Gs1995NXsnBZG+s= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5c0ba23a5abso785513a12.3 for ; Mon, 26 Aug 2024 23:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724741920; x=1725346720; 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=ZY9iE015kjWusc18TRiosgvJ+Wsi74GjN7yQxl/1tqw=; b=M7ZCczfMAl02DJSCE/D69ae60Ook3X+rSCmNxg1ItZUSIhTPvhEyHLB78Y3d5a1HA1 /F0i4/s17MnsjE5oZeE9F+Jk+RX5TAcaKW3Jp2GOKOUTv5tY9JtpPtU5SklnKTZD+gq4 dXRluaMH9RzzQPrq+uho1Em5gLBuHZT9XDxiuWmM/JSSfDREKuRycRuqEDqCmpXNNlXG 9c/uVwNeEcPPZbCv/Eipmsy0Ycmstek7EUoXGIoqTrxdmI8t0Q21AE18YjF8XwPfz3V5 k5lCI7uRhdi24XNmjStRJfqO/TsZnKVHkKpVpYWNhI9EmwCQqBwRU+746YS16fnW7fsM Qt6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724741920; x=1725346720; 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=ZY9iE015kjWusc18TRiosgvJ+Wsi74GjN7yQxl/1tqw=; b=oNilTEnI+f2z6l0mkXeChkvuiM9ls/SAqGN4Wq/i7Obob5Fchnoj/ATNgpwtVI+1vy ABYK3HLCL5C8P0Qzw1WyvhlU+k8OiczdZcu7wGRHHWnbke8b6g7SLh5jSSSKWDT2E2fQ oO8dzUODsLJsotMDmOQXH/uTb98ND6fC1RDKfYTBjy3h5lFhbN7nrVJ5AWJG8R+xzo1r 46y59gejbgIbJSeefEIDZfvCltL8NOXNrgq6q2QDr9Sq0AQHI74hNrombswlaOi9tYvF fRIN0Q0uVf4wgMX+kaVHVvmbGhY98mAQLMADuFx+SP6cSuQjzKXoIvclu/Befz8rnbx9 LLPw== X-Forwarded-Encrypted: i=1; AJvYcCXIMkheq2tlQVvijX8epWgEV3SZKXkN0n2jdZOqv/E4Gvs5WQB1b1F1PXEZCbA4IMhqI5SEcXrwZA==@kvack.org X-Gm-Message-State: AOJu0Yz5TCIJaACJmwcpTW+YOvY/psZ/kcOqR92PkXg2VHfGR/fdHb2M G9aJ2dWojwz50HGjM69Ck8pdrID1TdGKGKM3UqOUg1sFH6DnoSaGsOIdsn7XdSk= X-Google-Smtp-Source: AGHT+IHGiyAa7bX/33A23l80oaz7c5FgGRiOJ9rxmhA/0tIr4irzNxptSfoweilUX1Ghv/r+StubWg== X-Received: by 2002:a05:6402:90b:b0:5be:bcdf:4110 with SMTP id 4fb4d7f45d1cf-5c08910fb32mr8955148a12.0.1724741920178; Mon, 26 Aug 2024 23:58:40 -0700 (PDT) Received: from localhost (109-81-92-122.rct.o2.cz. [109.81.92.122]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c0bb471981sm640391a12.71.2024.08.26.23.58.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 23:58:39 -0700 (PDT) Date: Tue, 27 Aug 2024 08:58:39 +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: 6bhkgf9pca158trbszixea987aota983 X-Rspamd-Queue-Id: B7FB51C0017 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724741921-331915 X-HE-Meta: U2FsdGVkX1/cQ1y0xq+u9BFXDJ41FmNMe1Tc1HYsB+t5wn2lSsvt85/4zNy39yrllfnkVvX/BStmP/8rkOj/CtiTgHiF0S+Gx4cL4yv53447yri4wkSp+vUAC+dSS38OX4zSeEsZSgt3i5XsETN9eklDenThGniFHGjhwCDzTcr2Xddwt1KTLE3khTKUz5Hwpjimy+NNUYfQgx2e2oeMlmt0eYngu09Hpdw6zIAL3P5k2QQ06cumMLV0vohl5wfGlOeITlvO0gR/5j7ZU/NTAfgNqcupVA8oQ6c0eFXEery0pWI9KkGYtNAgyrUFlsKOqC/je6sh+Fp2P0DaGF1gclt9Sj+gMSAIW5Y2xpJpSjoQus9h/y+8oAT2TKP08v5rEMSEmo2JreH59LTUp8gZFgO+vMPh6YdtwhaU3K3YFvf0AEJoW6Jh0FizKlXNdmEa2wDSatXab1aIXmspjz2BzYVzpZbOdzGmjSQTykSqx7xrCEz2GSm0Vjbpu6KK3fbVqQcgj7Zlv3fxvfA/WbylYwL6RPSGdg/oiiUF+kWUDBaosgUKL34obeRfiltd78VdiaoEeBQjC+ox7mQxD1bmFeQpds8pRIuANfxljgMsO5koH+/tmvvunoBlsltBKSgCZk4GYC+xHQN6XFyagciMExER9s9imA1b693Yql1ELv4CNlHYLzxM30M8gXkBxyT9jyuPTgVwkgaQUN1nM5K7s8lf0zMW+9OCwXXdGZQDGtkGbBC2F9Q+8cQrHiwB5NVgDKOEdDWnFtWQfH42otvgtiNzhdU5QQbtxMq3OU5BYV8l4lkRZyyfb2Q8Do+Tko2A8jCxX5Z967K82Xpyfcn3ZM50McpTM92FFro6XZsN1ch076SI0KHvR2i0tZ++8olZEk4auh87FVyv/Ew755RTt2KvUOM6192EDkr7tjXPPCZGyqejn18BGwoCy/gJx+SCAZX45cHoaIuqDnweCHD KdT3CNHr Z77OoOW/jG3ZNZ2lXxaQS5uEEbnyd/kvkB1EzS1AcWNOLZIZb1ujo0RfRSvL7YpJVAo7xWQws347Yw7VLgQxxlfCliyA+IvM6kOP8dSV2jyGTTYEMdo4oZqIEs/ED16NA7MCa+2Hi+SV7vTBQ+rNSivso0koec1KjVKGQ6NxqnSHV362PgK1BFfPHikQjbU5mxVbD6jNLHMUhPl02Zoj8wnKbqDSsu0kZZ3Z+mSnUyuv234JrrheKryiZqRr5Yh5be+LYm0AwZF3yCXh4679tB4tRy79+xcQVnAHwTsYEq2KQUrKh1q2G8JhOgmdMN2QuSjhP4isvAkTsVByehWXeHl1LVQlEk5aAW9N/kCyiQZZVztykP7FCklg7qtjFwg9bNZ25KCVdCpH5Jr/Wg00WWpmi4g== 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 Tue 27-08-24 02:40:16, Kent Overstreet wrote: > On Tue, Aug 27, 2024 at 08:01:32AM GMT, Michal Hocko wrote: > > 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. > > You're too attached to GFP_NOFAIL. Unfortunatelly GFP_NOFAIL is there and we need to support it. We cannot just close eyes and pretend it doesn't exist and hope for the best. > GFP_NOFAIL is something we very rarely use, and it's not something we > want to use. Furthermore, GFP_NOFAIL allocations can fail regardless of > this patch - e.g. if it's more than 2 pages, it's not going to be > GFP_NOFAIL. We can reasonably assume we do not have any of those users in the tree though. We know that because we have a warning to tell us about that. We still have legit GFP_NOFAIL users and we can safely assume we will have some in the future though. And they have no way to handle the failure. If they did they wouldn't have used GFP_NOFAIL in the first place. So they do not check for NULL and they would either blow up or worse fail in subtle and harder to detect way. -- Michal Hocko SUSE Labs