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] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0704021125210.31277@schroedinger.engr.sgi.com>
Date:	Mon, 2 Apr 2007 11:30:31 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org, mpm@...enic.com
Subject: Re: [SLUB 2/2] i386 arch page size slab fixes

On Sat, 31 Mar 2007, Andrew Morton wrote:

> Can we disable SLUB on i386 in Kconfig until it gets sorted out?

Found it. Another issue with relying on page size special casing in the 
SLAB.


i386: Another case of i386 exploiting page sized slab cache special casing

i386 uses kmalloc to allocate the thread structure assuming that the 
allocation results in a page size aligned allocation. That has worked so 
far because SLAB exempts page sized slabs from debugging and aligns them 
in special ways that gobeyond the restrictions imposed by 
KMALLOC_ARCH_MINALIGN (which are valid for all other kmalloc caches).

SLUB also works fine since the page sized allocations neatly align at page
boundaries. However, if debugging is switched on then SLUB have to add 
additional debugging information after the object increasing the slab 
size. The total object only be aligned following the requirements imposed 
by KMALLOC_ARCH_MINALIGN. There is nothing there that would require
a page size alignment.

The solution here is to replace the calls to kmalloc with calls into 
the page allocator. An alternate solution may be to create a custom slab 
cache and setting the alignment is to PAGE_SIZE (works with SLUB. 
There is no problem here with page_struct modifications). That would allow slub 
debugging to be used on the threadinfo structure.

But this is a page sized allocation after all and for efficiencies sake we 
should call directly into the page allocator and not use slab.

Signed-off-by: Christoph Lameter <clameter@....com>

Index: linux-2.6.21-rc5-mm3/include/asm-i386/thread_info.h
===================================================================
--- linux-2.6.21-rc5-mm3.orig/include/asm-i386/thread_info.h	2007-04-02 05:57:31.000000000 +0000
+++ linux-2.6.21-rc5-mm3/include/asm-i386/thread_info.h	2007-04-02 06:03:09.000000000 +0000
@@ -95,12 +95,14 @@
 
 /* thread information allocation */
 #ifdef CONFIG_DEBUG_STACK_USAGE
-#define alloc_thread_info(tsk) kzalloc(THREAD_SIZE, GFP_KERNEL)
+#define alloc_thread_info(tsk) ((struct thread_info *) \
+	__get_free_pages(GFP_KERNEL| __GFP_ZERO, get_order(THREAD_SIZE)))
 #else
-#define alloc_thread_info(tsk) kmalloc(THREAD_SIZE, GFP_KERNEL)
+#define alloc_thread_info(tsk) ((struct thread_info *) \
+	__get_free_pages(GFP_KERNEL, get_order(THREAD_SIZE)))
 #endif
 
-#define free_thread_info(info)	kfree(info)
+#define free_thread_info(info)	free_pages((unsigned long)(info), get_order(THREAD_SIZE))
 
 #else /* !__ASSEMBLY__ */
 
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ