linux-kernel - Re: [PATCH] gfp: Include __GFP_NOWARN in GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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.