[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20231109141402.11f951a83a742465f5306ba2@linux-foundation.org>
Date: Thu, 9 Nov 2023 14:14:02 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Matthew Wilcox (Oracle)" <willy@...radead.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gfp: Include __GFP_NOWARN in GFP_NOWAIT
On Thu, 9 Nov 2023 21:15:07 +0000 "Matthew Wilcox (Oracle)" <willy@...radead.org> wrote:
> GFP_NOWAIT callers are always prepared for their allocations to fail
> because they fail so frequently. Forcing the callers to remember to add
> __GFP_NOWARN is just annoying and leads to an endless stream of patches
> for the places where we forgot to add it.
A possible problem is call sites where the developers were relying upon
the core MM's warning, so they chose to omit __GFP_NOWARN rather than
adding a local printk.
We're now silencing core MM's warning so those developers might lose
some diagnostic information.
Random example, arch/s390/pci/pci_clp.c:clp_refresh_fh(). After this
change, the pci_clp developers won't see (or be told about) allocation
failures in this function. If they know about this change, they may
now choose to add a local printk.
It's not the end of the world by any means. One possible way to
prevent this change in behavior is to add a new __GFP_WARN and go add
it to all the sites which use bare __GFP_NOWAIT and which do not have a
local printk for the allocation failure.
Powered by blists - more mailing lists