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 6FB7AC54E58 for ; Mon, 25 Mar 2024 17:46:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B89136B007B; Mon, 25 Mar 2024 13:46:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B39326B0082; Mon, 25 Mar 2024 13:46:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A27D36B0083; Mon, 25 Mar 2024 13:46:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8F9186B007B for ; Mon, 25 Mar 2024 13:46:40 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0BB651606FB for ; Mon, 25 Mar 2024 17:46:40 +0000 (UTC) X-FDA: 81936291360.11.C90AC2D Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by imf27.hostedemail.com (Postfix) with ESMTP id 4788B40016 for ; Mon, 25 Mar 2024 17:46:37 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=UryULHQb; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf27.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711388797; 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=LeW/80LLELbDXG6lmTnctliU3e5K4P0PV8m9dTnX9II=; b=7GioZGH3OFe8GDjn3yKjPJGDMqyCeMN6CJkfxyIdVRw+KQ2CJ/XqcnkRILnESrSSi4MwAl VAjmd0UjOjct4l3BSTwB2Xv1Q0gJPt5OeWG33pStFtmWP0JSEGEPjAZMkKKIymtn4ZsbBo nrglCvrJASesmeUyMPkYUZeHtnC1Hlg= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=UryULHQb; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf27.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711388797; a=rsa-sha256; cv=none; b=75vuqb4kr6e6gdgiSIToxSp39HMvBaH4Mx+d5+N1HR8wiNz0OIPcjWuV0r4uLYkF59iVgi WCMam7bIrmA+MGOUOp20dADIyeJP8TxiUK741GuoOjoZ/wY0i463K4v8uOTbpVsIqpl3RJ r+8q4ofimZ9ANGVP9JApaV0qm4N91IU= Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4V3L2w0nhjz9spR; Mon, 25 Mar 2024 18:46:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1711388792; 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=LeW/80LLELbDXG6lmTnctliU3e5K4P0PV8m9dTnX9II=; b=UryULHQbJ1hmsv392a66CH18gFV15LlyAZm5bMoryXIR7MtTDZToXZZ631w54ymNMaIP6S i8TdXP+oknMUZZcBBeYtPZRcr48NHQCt5REEvMNI6Jc2VcIGJkaYLGa+BwzfnQ0ldQUTEN pNXVIhxangMss1la5Jo5I3QV3WWKpasVREz18cIxnYeUpO3OM/FmC6o3qiCtAjFz6QYu/D lcXTDuZ9xexJxaKvombo1nbdR4nPPJ61eS+Vh/ZabgU8RX+v1v/lOOLerArMquS/cytEMu JyVutDDJP8f/jc9PLQyux4t3h7znVn8LrsdrZaQo/7dUqfRcdpE4TD6RrF29UQ== Date: Mon, 25 Mar 2024 18:46:29 +0100 From: "Pankaj Raghav (Samsung)" To: Dave Chinner Cc: linux-xfs@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org, kernel@pankajraghav.com, mcgrof@kernel.org, gost.dev@samsung.com Subject: Re: [PATCH 00/12] xfs: remove remaining kmem interfaces and GFP_NOFS usage Message-ID: References: <20240115230113.4080105-1-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240115230113.4080105-1-david@fromorbit.com> X-Rspamd-Queue-Id: 4788B40016 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 9fxjx6c4d5mufjbfr89uxpbnou1bpd74 X-HE-Tag: 1711388797-639303 X-HE-Meta: U2FsdGVkX19WiESWpVs/9uaB6193+U3ZnU0LgGSE8mCi2fRIYgJ5rMIVB58lKv8AVhEkIIc2MN8JpMwAu5DvU/evn8xZBJVsRhxxI9gjAyBD8mTZTe2MaqDkA2zYk8L2KvIGX50jUR4msJmHyQL3PcXWsrm7Rf6cKRAIWLQ6hawr9i/qH97FXpsCKRqOIdxJ/1wZWNdqPG6bh5WpuiCLkeHXDYkqbOSm0+p1jMdZ7vMbalrjFMxNYdKgeRzG3TJgZCKBiZrc0RT09M37DERPr2Ie5mjcQum1fe80TF0hhFHvFGM4gaHRVZy8Fa/KmXi1aZrArRUC4Tgv9w1v8a0PyfT4j7HU9SXiFYTKLEcDgWB+i2pWtKZ3+YRICqJ3zwRs/akmn1dp5Vz/JRD6E3VtZOrBQgd9dx7VoxRGfsz3IKWruXMPptdNrrV1PKjFnlyVU+MwwoIwx7x6O6/05r5JADGkfNZYEfLs/Uvy0WvPY8ZldFNiiwtCSRl+K0LJQgjrPpAYBEAAU9M8Xkx0k7XPb/rkyTxJ4gL9WgWar2HDiFJMP9nSW0FrKFDjAHB9TPXzoEV8NnY4PHOrCn7p3lH4Zh2GZ3QFhFz+JxNToKw5CsVVhtvSuxdFF5eYR31aUQT68QyecHHEn5toETXTLXgqFqMoCUkDBcNwYW8kDLhNkqGKssX3NqFs9tukrbZFtmCJ3Yv2RG/NAh53k/8utd6GIZvsMoir7zTvSqNQUYE/4e+5A1ygIpCbi+8/a0rtlCtl1aFOkub5A5Yea4yJcTd7WfEQwdtDb9mM5rLJU/TAdbMY9DMSausQii6qKo4K6w5VkOQiKTdi+FS+s4kPNDaMr8JsmP9eJWb9cw8GYCSoYnw4JVTt4J7RR5U6jmnaA9x21SJKRRq7plEG/q17ASCxpeEtyJYYLn2oxmf66vQfWuuutSxihaDYV6Wy9JrlSsREsiTRG8VYAIbL6h+/g7D UvbyV+hn gaIBkEz3Yvld14GPIFUIZIO33noXECbUayS13vh/CwlGu8Idr+Vg51V2lD7PUEwSAtTru16bBsm0aFdd7emyk3kYRL2n4CMoJZb+TYIg0NzKBhHzcB1olpVIOXAqV1caUQo8T6t0KoYNkEYlJm+FgIYr7LXumxXR2JUlnvS7sgqwTOYI0iqdtaDKuVJIeBht3DPZQgEZ4ZcSGWtoRckHCdw8ODn26XmSk3SciSsxCenqfyQPk9vFxLQfrWHWBdR8ZOjufVwIvblC3o/KFLVlEA+j8sTrvgOKOcpR6 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: > > The first part of the series (fs/xfs/kmem.[ch] removal) is straight > forward. We've done lots of this stuff in the past leading up to > the point; this is just converting the final remaining usage to the > native kernel interface. The only down-side to this is that we end > up propagating __GFP_NOFAIL everywhere into the code. This is no big > deal for XFS - it's just formalising the fact that all our > allocations are __GFP_NOFAIL by default, except for the ones we > explicity mark as able to fail. This may be a surprise of people > outside XFS, but we've been doing this for a couple of decades now > and the sky hasn't fallen yet. Definetly a surprise to me. :) I rebased my LBS patches with these changes and generic/476 started to break in page alloc[1]: static inline struct page *rmqueue(struct zone *preferred_zone, struct zone *zone, unsigned int order, gfp_t gfp_flags, unsigned int alloc_flags, int migratetype) { struct page *page; /* * We most definitely don't want callers attempting to * allocate greater than order-1 page units with __GFP_NOFAIL. */ WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); ... The reason for this is the call from xfs_attr_leaf.c to allocate memory with attr->geo->blksize, which is set to 1 FSB. As 1 FSB can correspond to order > 1 in LBS, this WARN_ON_ONCE is triggered. This was not an issue before as xfs/kmem.c retried manually in a loop without passing the __GFP_NOFAIL flag. As not all calls to kmalloc in xfs_attr_leaf.c call handles ENOMEM errors, what would be the correct approach for LBS configurations? One possible idea is to use __GFP_RETRY_MAYFAIL for LBS configuration as it will resemble the way things worked before. Let me know your thoughts. -- Pankaj [1] https://elixir.bootlin.com/linux/v6.9-rc1/source/mm/page_alloc.c#L2902