From patchwork Tue Oct 24 16:25:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Wilcox X-Patchwork-Id: 13435117 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 AD237C25B47 for ; Tue, 24 Oct 2023 16:26:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37C886B02C8; Tue, 24 Oct 2023 12:26:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 305C76B02C9; Tue, 24 Oct 2023 12:26:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CE066B02CA; Tue, 24 Oct 2023 12:26:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 09A4E6B02C8 for ; Tue, 24 Oct 2023 12:26:04 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D3416120244 for ; Tue, 24 Oct 2023 16:26:03 +0000 (UTC) X-FDA: 81380881806.08.1218F6D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id AED1DC000F for ; Tue, 24 Oct 2023 16:26:01 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tZKJPTUm; dmarc=none; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698164762; 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=b4w9aRyrS+9I1Nc5GJ428AZWRpJVCoZGZd7zMybYBaw=; b=WtQRGEPCRgy5vnnzpKBfBlmaxZLhIDQc1jnIQXe//nN/GI7qyfy4a9JgRGsPfjpxD1XrKh UzjBDubCDII0m1APuQp/bihXmERBt0uDuheBmDE9uN1NHY6NFPIGC93W1bDN3d6Fm9o68W rP5d/con/dTost9SqCzsFWZQ3g6vI+M= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tZKJPTUm; dmarc=none; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698164762; a=rsa-sha256; cv=none; b=VR3+tRczERYZm7vlTqg2uayDDJZtfDoQEOcvPdrwwJ3dDjjWOTbKRRisCJQFoduAVKSKBW K4euNF0Bf/IpnXhSd+Lp0R+WEE3I82uLnOyBrFBmll2iVVk6YGlZo68p2h3yd6qo1Dg6w2 sapRNK9wxvnngYHY7GDjWanKyqDKP78= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=b4w9aRyrS+9I1Nc5GJ428AZWRpJVCoZGZd7zMybYBaw=; b=tZKJPTUmDGV+PL6Z4HbvGgkm0T MVGRUPIGDLJ3+T23gKpqolCVsty3W5rl7cc/DRgxyyWKqROabY6TCBLV7vXXfvHgeOtMs/KS/qu07 BIuFXVHVtKbhz8H0pDKdNPIpMqjTr9OlHwWYGr4/+7EM9tRD8AiuQUcylF/BxWXkwhAotiUzsnC7a VAXOZgKqWlH8yHk+Tv80+xEQcVpcmaRVofLneCZE5JPJFywxBPYcTXYIEwnpyfwlXUh83bgPH+9zL F3ycEbmIlohHNboqntPVz6AzYpzlMYxUksXX2nfAWu2nRK5i/VKAbk0fonkYnZQyyomoxHYGnKufT BAT6PjdA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qvKDz-003UvN-Rd; Tue, 24 Oct 2023 16:25:47 +0000 Date: Tue, 24 Oct 2023 17:25:47 +0100 From: Matthew Wilcox To: Andrew Morton Cc: Jan Kara , Hugh Dickins , Hui Zhu , Theodore Ts'o , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org Subject: Include __GFP_NOWARN in GFP_NOWAIT Message-ID: References: <7bc6ad16-9a4d-dd90-202e-47d6cbb5a136@google.com> <20231024100318.muhq5omspyegli4c@quack3> <20231024075343.e5f0bd0d99962a4f0e32d1a0@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231024075343.e5f0bd0d99962a4f0e32d1a0@linux-foundation.org> X-Rspam-User: X-Stat-Signature: bc1unmtfdffh4f7bwekh7e8kqpnq6bpd X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AED1DC000F X-HE-Tag: 1698164761-604457 X-HE-Meta: U2FsdGVkX1+1UCqZnD5D+oz1yMNXQn+qEM7/kS4O5ABUOizXvbiiMlfkZDVBkpg1QfKotT3neCnkD+jk216jzgUYyl95seJrkhwZ13FvyrNn1xU8RAvMdqhA9H1/A2vQlpvJsySbqaMKGnGYeH/HE78U17y96Z9uHyPNZVw0ABv0u20Oc7cs/XrDoWC6Fl86MHFufvoFmIMrVLsVZaH2z9rDH5+F/TpPsYu6IYXN7lx4bWuge2lkSJuei0xrqJ5AzRkG53EUWeUQmiKfggX0fNpLUYceQv/xWNFxV1UZjRiPDb5hboOX/Zb3pW0ZmnaNhZamdxVHDy8rtCo/LfUbx+zdGkThdoisEYvJRKvBB0erPJ6roor8k2qZO0CJhJi9eTXJRez+PENhgE07uUiEWpBN9ah4k6+sSNnpEGPrWbWfqvDDE3QzVOyCUdok1Tp5Z33kN3R5XiXrxE+kKS2MNaswIs6Xla/xSFXlhsqeSKVi8j/7npIEAp+c1fUwbVwi5xf0B3/SQeCM+ZkrmhODwgGIpVX9OUrqoM8EYDsnu1Xgcj8C7kUWD0FNXSCUudubDOhCL1ZDgErA/efWO1bPMzn4ztBcjFzNdDXUtTcnlOg1lmLKhrJM8NT/99GD1lhdKsnl1xqFqK7I4ef0dQ244h6nrDvpBzTK4SHqfG2hSm35F1CmerUo3XYb9/QZ6YfMC7yLpcH0mxTTro3TmIsVsfY3DM7Qp79V+ECrYX5STpClvLnjvD/pEKzRIXJ4sivUZ8jdZal1MrXw+hh/FTf0xGSG19JaLSuMdBebMGUOviRcjlSaxienRxkrdgv1PXKvlPoItpYRoUUVzWpbYvqFIXAG0HOiD8uVD4JQhUih5XX/81wd0QnCvME9igVnboi+3lhuDmATk95Ibyux7kQgW4kGYd3O7HMsM0QkJI6C6kV+gvD79rqMD4fBIsUHmyZiy9iv3yqGnFEVDJMosjc 8cBMf4+E fl4ZLQtQsrPtofXsZcwAQcphcUKGkrCI/V72Gag53AyXiubSO6NaqVZg/Cbt+fWnSUgL1ohXsN0NoF6MqjK5mP/mTrcVCiNTG1NEam1ST6iBeSvpmai0fW63fr4Mg80JYPR8XESEABvp6wzdBzpy2oEsccbhSwCEq5SAlrxzDaLFenA8t8l5A4ewKNxV9RrxJhmD07LWhQz+Anbo= 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, Oct 24, 2023 at 07:53:43AM -0700, Andrew Morton wrote: > On Tue, 24 Oct 2023 12:03:18 +0200 Jan Kara wrote: > > > On Mon 23-10-23 23:26:08, Hugh Dickins wrote: > > > Since mm-hotfixes-stable commit e509ad4d77e6 ("ext4: use bdev_getblk() to > > > avoid memory reclaim in readahead path") rightly replaced GFP_NOFAIL > > > allocations by GFP_NOWAIT allocations, I've occasionally been seeing > > > "page allocation failure: order:0" warnings under load: all with > > > ext4_sb_breadahead_unmovable() in the stack. I don't think those > > > warnings are of any interest: suppress them with __GFP_NOWARN. > > > > > > Fixes: e509ad4d77e6 ("ext4: use bdev_getblk() to avoid memory reclaim in readahead path") > > > Signed-off-by: Hugh Dickins > > > > Yeah, makes sense. Just the commit you mention isn't upstream yet so I'm > > not sure whether the commit hash is stable. > > e509ad4d77e6 is actually in mm-stable so yes, the hash should be stable. GFP_NOWAIT is a loaded gun pointing at our own feet. It's almost expected to fail (and that's documented in a few places, eg Documentation/core-api/memory-allocation.rst) Why do we do this to ourselves? There's precedent for having __GFP_NOWARN included in the flags, eg GFP_TRANSHUGE_LIGHT has it. There are ~400 occurrences of GFP_NOWAIT in the kernel (many in comments, it must be said!) and ~350 of them do not have GFP_NOWARN attached to them. At least not on the same line. To choose a random example, fs/iomap/buffered-io.c: if (flags & IOMAP_NOWAIT) gfp = GFP_NOWAIT; else gfp = GFP_NOFS | __GFP_NOFAIL; That should clearly have had a NOWARN attached to it, but it's not a code path that's commonly used, so we won't fix it for a few years. Similarly, in Ceph: if (IS_ENCRYPTED(inode)) { pages[locked_pages] = fscrypt_encrypt_pagecache_blocks(page, PAGE_SIZE, 0, locked_pages ? GFP_NOWAIT : GFP_NOFS); ... actually, this one looks fine because it goes to mempool_alloc() which adds __GFP_NOWARN itself! There are a bunch of places which use it as an argument to idr_alloc(), generally after having called idr_prealloc() and then taken a spinlock. Those don't care whether NOWARN is set or not because they won't allocate. Anyway, are there good arguments against this? diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h index 6583a58670c5..ae994534a12a 100644 --- a/include/linux/gfp_types.h +++ b/include/linux/gfp_types.h @@ -274,7 +274,8 @@ typedef unsigned int __bitwise gfp_t; * accounted to kmemcg. * * %GFP_NOWAIT is for kernel allocations that should not stall for direct - * reclaim, start physical IO or use any filesystem callback. + * reclaim, start physical IO or use any filesystem callback. It is very + * likely to fail to allocate memory, even for very small allocations. * * %GFP_NOIO will use direct reclaim to discard clean pages or slab pages * that do not require the starting of any physical IO. @@ -325,7 +326,7 @@ typedef unsigned int __bitwise gfp_t; #define GFP_ATOMIC (__GFP_HIGH|__GFP_KSWAPD_RECLAIM) #define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS) #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT) -#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM) +#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN) #define GFP_NOIO (__GFP_RECLAIM) #define GFP_NOFS (__GFP_RECLAIM | __GFP_IO) #define GFP_USER (__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)