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:   Tue, 24 Oct 2023 17:25:47 +0100
From:   Matthew Wilcox <>
To:     Andrew Morton <>
Cc:     Jan Kara <>, Hugh Dickins <>,
        Hui Zhu <>, Theodore Ts'o <>,,,
Subject: Include __GFP_NOWARN in GFP_NOWAIT

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

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;
                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] =
                                                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

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_NOFS	(__GFP_RECLAIM | __GFP_IO)

Powered by blists - more mailing lists