linux-kernel - [PATCH] mm: do not print backtraces on 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-next>] [day] [month] [year] [list]

Message-ID: <20100921121818.4745f038@annuminas.surriel.com>
Date:	Tue, 21 Sep 2010 12:18:18 -0400
From:	Rik van Riel <riel@...hat.com>
To:	linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: [PATCH] mm: do not print backtraces on GFP_ATOMIC failures

Atomic allocations cannot fall back to the page eviction code
and are expected to fail.  In fact, in some network intensive
workloads, it is common to experience hundreds of GFP_ATOMIC
allocation failures.

Printing out a backtrace for every one of those expected
allocation failures accomplishes nothing good. At multi-gigabit
network speeds with jumbo frames, a burst of allocation failure
backtraces could even slow down the system.

We're better off not printing out backtraces on GFP_ATOMIC
allocation failures.

Signed-off-by: Rik van Riel <riel@...hat.com>

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 975609c..5a0bddb 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -72,7 +72,7 @@ struct vm_area_struct;
 /* This equals 0, but use constants in case they ever change */
 #define GFP_NOWAIT	(GFP_ATOMIC & ~__GFP_HIGH)
 /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */
-#define GFP_ATOMIC	(__GFP_HIGH)
+#define GFP_ATOMIC	(__GFP_HIGH | __GFP_NOWARN)
 #define GFP_NOIO	(__GFP_WAIT)
 #define GFP_NOFS	(__GFP_WAIT | __GFP_IO)
 #define GFP_KERNEL	(__GFP_WAIT | __GFP_IO | __GFP_FS)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/