linux-kernel - Re: [PATCH v3] mm/slab_common: Support the slub_debug boot option on specific object size

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]

Date:	Fri, 24 Apr 2015 08:52:37 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Gavin Guo <gavin.guo@...onical.com>, penberg@...nel.org,
	rientjes@...gle.com, iamjoonsoo.kim@....com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux@...musvillemoes.dk
Subject: Re: [PATCH v3] mm/slab_common: Support the slub_debug boot option
 on specific object size

On Thu, 23 Apr 2015, Andrew Morton wrote:
> >
> > +		if (i == 2)
> > +			i = (KMALLOC_SHIFT_LOW - 1);
>
> Can we get rid of this by using something like

Nope index is a ilog2 value of the size. The table changes would not
preserve the mapping of the index to the power of two sizes.

> static struct {
> 	const char *name;
> 	unsigned long size;
> } const kmalloc_names[] __initconst = {
> //	{NULL,                      0},
> 	{"kmalloc-96",             96},
> 	{"kmalloc-192",           192},
> #if KMALLOC_MIN_SIZE <= 8
> 	{"kmalloc-8",               8},
> #endif
> #if KMALLOC_MIN_SIZE <= 16
> 	{"kmalloc-16",             16},
> #endif
> #if KMALLOC_MIN_SIZE <= 32
> 	{"kmalloc-32",             32},
> #endif
> 	{"kmalloc-64",             64},
> 	{"kmalloc-128",           128},
> 	{"kmalloc-256",           256},
> 	{"kmalloc-512",           512},
> 	{"kmalloc-1024",         1024},
> 	{"kmalloc-2048",         2048},
> 	{"kmalloc-4096",         4096},
> 	{"kmalloc-8192",         8192},
> 	...
> };
>

> Why does the initialization code do the
>
> 	if (!kmalloc_caches[i]) {
>
> test?  Can any of these really be initialized?  If so, why is it
> legitimate for create_kmalloc_caches() to go altering size_index[]
> after some caches have already been set up?

Because we know what sizes we need during bootstrap and the initial
caches that are needed to create others are first populated. If they are
already handled by the earliest bootstrap code then we should not
repopulate them later.

> Finally, why does create_kmalloc_caches() use GFP_NOWAIT?  We're in
> __init code!  Makes no sense.  Or if it *does* make sense, the reason
> should be clearly commented.

Well I was told by Pekka to use it exactly because it was init code at
some point. The slab system is not really that functional so I doubt
it makes much of a difference.



--
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/