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 3B067C5321D for ; Mon, 26 Aug 2024 19:39:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67A536B0083; Mon, 26 Aug 2024 15:39:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6298A6B0085; Mon, 26 Aug 2024 15:39:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 518156B0088; Mon, 26 Aug 2024 15:39:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 34D716B0083 for ; Mon, 26 Aug 2024 15:39:58 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DAE1DA12BB for ; Mon, 26 Aug 2024 19:39:57 +0000 (UTC) X-FDA: 82495412034.29.6CB9159 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) by imf10.hostedemail.com (Postfix) with ESMTP id 0FB97C000A for ; Mon, 26 Aug 2024 19:39:54 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=V8cvKRlV; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724701132; a=rsa-sha256; cv=none; b=8QE35nGaiLk1WslnZvGQ+VGaXSSwKAgb1ZqQ9/T8L9zmEgvMeotQfo+dn0K5OHOPSBDdoD pzHNvHPLq57JVEMQ1nrnbyK/2sabNVyunG0wb9hmURBJFfeWvCxLkH6mzlmZhbEcdqCh4J Ci2GURBhniaRYAN4QPh6w3Ip/uf/+Dc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=V8cvKRlV; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724701132; 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=8E/6L+ulNsRyaHYOTIlLjfcvhy62fxlcDeAIHJ8v4Ks=; b=Nh1y3BwvFcvdIQvhsNKSWjTQOVug4W9eh6hrkhlmcAVhnx/xMwGllsX1Y+evwbIkAYVtS5 kD9dYSdiYuIUp11IXB8PPDCOwAffW3wY14J2K/joUjF+VrsYPjSoPJ1zg/+xTTjHaVVGuq KoiXrDUNeK3OPPTljElAvE4wiQQ0KG8= Date: Mon, 26 Aug 2024 15:39:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724701193; 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=8E/6L+ulNsRyaHYOTIlLjfcvhy62fxlcDeAIHJ8v4Ks=; b=V8cvKRlVtBhQKeYuIHdYYCUBDHWBs7l5h7bwYMUlck2FF7vO0I70RWpj0RHO9D1SxfpY/R aOaZ+6ve08kYIPyePAQplsSQyHKdzdyPJjqJpH8sea54fRE8DsES3fVtNbNeYK1C5R627I HJLBFnfng6C5djJJ8e4kAR/ovwX0ymE= 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, Michal Hocko 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: <20240826085347.1152675-2-mhocko@kernel.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 0FB97C000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: bkq5aqn1mnrt19a6355ue97hndcc5gbn X-HE-Tag: 1724701194-799368 X-HE-Meta: U2FsdGVkX19y5eqnHHYcELbU+g7PowLiN7Iqe2yu/QO+Hk4/rs2zbls/8PphP0q6e8WnK47IUP4n48Zz5Rtos2gVbq2ApZV+T5dHTHI6WKTlqH69a9gthws02GYOsu8k4GrRVd7iLMrmEhfj2lOnvuf3PE2/mZ3I4hZ9YzZ4uYAjUHm1XBtj6ZP6eQCDvZ/Zs3/Xw1xMF/hO4OK6hraHGhJNBRMHvgeDjG7FG5r8QTue2UKqCfIL1X9qaZIYcqJi6y1PzvClVfAo0zp//AwimtHg8Ni7PL1K9CyjCih1tGtTxHKyyN7yjQfvkQx09cZuxJR1jXOHUr0JS85wNu0NZjQuPCYQACO9auxj7VtQ4cbcuFKeNL3aJ/RZ2ZvVGzADvivFSPs3ZA6/tGp2DMKoXF1FanKA0uanD14w4LbKbZ5lMj+ppL6qfRDxIHk08NS3xy/t480R/YLbnGNCW4LxsvQzH+5RhIxrSPrdAAtn3xaU+U9Z2QUM09aTm21m9v/Rq2xCiCt0ylzqwZ0KYZH/PoAtZwJOhbzpA8dAUdbwzxZGP0lMnavhj3aQRY8H6xxUXbVT/JvhLZjZj/72nXgPeyoE0hW/FwLfYU4iUMfM+c0OUeoZxekPD1ww51KwLZbRzl81/eKouXaQQBGdJoVjTDRNaHfB8kIs3vUoY+TiA3jEvBOHwCcu4FrKaVOB8HIl8npQINz4ezwL/xXbDrUctm7I7WAk7On8HWz5Ikba6YTfR87J4SkS0L1z5U3uLJPwNFe9pHzINHpTd+ghAE5WUpM21kKwEJsbTuBj1WEbirJz0o4qtsYD11OvBGOHDjNIYmNtvndBROkJCa+MXTiQzlHQFdE7b1ARijoxZ8m2Tbioqks/C19nMDvMOvs9ZbnqHl+GI9n8CnsZhVDs1XIVBpqzVxPwxOH5bi+m6QffsGaLs6e2Y/NzOtfb1I5GW4MjozDw1M81GRYSqPL8OW4 lB+C+Sko wcAVY969sfv4qmsHtbpDvoRfYePbgZqgA9VzTVOTiba9rfXWBvd+O+8ajcXSSF2xEpXrMQ2YCzvcpbk/Ljzwm4mYQBBHT2pUvRu0hdKvtRB/GfFLZdpha9OV6PHtEJkGX+ftsKXa0m+WRzn3+kXfFZNVJxi4Fv9ApfT3DfVpopBYnRSJanGdm0jzmY+tKbgwkNz/G/XwKx5YIshaqpLzJTk/2UqzxPanyyKm2PHkBXUSoZTjroj3ZngKCnLGeH/+anKVDl0AFIYPiTXaluqIOOBIsZKgrE2974G5FhHCtRc/iqf4= 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: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. Given the amount of plumbing required here, it's clear that passing gfp flags is the less safe way of doing it, and this really does belong in the allocation context. Failure to pass gfp flags correctly (which we know is something that happens today, e.g. vmalloc -> pte allocation) means you're introducing a deadlock.