linux-kernel - Re: upcoming kerneloops.org item: get_page_from

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.2.01.0906241134510.3240@localhost.localdomain>
Date:	Wed, 24 Jun 2009 11:42:33 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Pekka Enberg <penberg@...helsinki.fi>, arjan@...radead.org,
	linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
	npiggin@...e.de
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist



On Wed, 24 Jun 2009, Andrew Morton wrote:
> 
> hm, I didn't know that slub could fall back to lower-order allocations
> like that.  Neat.

Slab doesn't do it, though. So we still need to get rid of the "order-1" 
warning, at least (slab_break_gfp_order).

> What's the expected value of s->min in allocate_slab()?  In what
> situations would it be >0?

For slub, s->min has an order of just "get_order(size)" (ie the minimum 
order to fit an object).

For slab, the logic is different, but if I read the code correctly it 
boils down to the minimum order, except that order-1 is accepted instead 
of order-0 (strictly speaking, that only happens if you have more than 
64MB of RAM). With no fallback.

And it's quite reasonable to expect to be able to do small kmalloc's 
without failing.

So I'd suggest just doing this..

			Linus
---
 mm/page_alloc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index aecc9cd..5d714f8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1153,10 +1153,10 @@ again:
 			 * properly detect and handle allocation failures.
 			 *
 			 * We most definitely don't want callers attempting to
-			 * allocate greater than single-page units with
+			 * allocate greater than order-1 page units with
 			 * __GFP_NOFAIL.
 			 */
-			WARN_ON_ONCE(order > 0);
+			WARN_ON_ONCE(order > 1);
 		}
 		spin_lock_irqsave(&zone->lock, flags);
 		page = __rmqueue(zone, order, migratetype);
--
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/