Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Jan 2018 08:05:25 -0800
From: Matthew Wilcox <>
To: Christopher Lameter <>
Cc: Kees Cook <>,,
	David Windsor <>,
	Pekka Enberg <>,
	David Rientjes <>,
	Joonsoo Kim <>,
	Andrew Morton <>,,,
	Linus Torvalds <>,
	Alexander Viro <>,
	Andy Lutomirski <>,
	Christoph Hellwig <>,
	"David S. Miller" <>,
	Laura Abbott <>,
	Mark Rutland <>,
	"Martin K. Petersen" <>,
	Paolo Bonzini <>,
	Christian Borntraeger <>,
	Christoffer Dall <>,
	Dave Kleikamp <>, Jan Kara <>,
	Luis de Bethencourt <>,
	Marc Zyngier <>, Rik van Riel <>,
	Matthew Garrett <>,,,,
Subject: Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for
 usercopy whitelisting)

On Tue, Jan 16, 2018 at 09:21:30AM -0600, Christopher Lameter wrote:
> > struct kmem_cache_attr {
> > 	const char name[32];
> Want to avoid the string reference mess that occurred in the past?
> Is that really necessary? But it would limit the size of the name.

I think that's a good thing!  /proc/slabinfo really starts to get grotty
above 16 bytes.  I'd like to chop off "_cache" from the name of every
single slab!  If ext4_allocation_context has to become ext4_alloc_ctx,
I don't think we're going to lose any valuable information.

My real intent was to reduce the number of allocations; if we can make
it not necessary to kstrdup the name, I think that'd be appreciated by
our CONFIG_TINY friends.

> > (my rationale is that everything in attr should be const, but size, align
> > and flags all get modified by the slab code).
> Thought about putting all the parameters into the kmem_cache_attr struct.
> So
> struct kmem_cache_attr {
> 	char *name;
> 	size_t size;
> 	size_t align;
> 	slab_flags_t flags;
> 	unsigned int useroffset;
> 	unsinged int usersize;
> 	void (*ctor)(void *);
> 	kmem_isolate_func *isolate;
> 	kmem_migrate_func *migrate;
> 	...
> }

In these slightly-more-security-conscious days, it's considered poor
practice to have function pointers in writable memory.  That was why
I wanted to make the kmem_cache_attr const.

Also, there's no need for 'size' and 'align' to be size_t.  Slab should
never support allocations above 4GB in size.  I'm not even keen on seeing
allocations above 64kB, but I see my laptop has six 512kB allocations (!),
three 256kB allocations and seven 128kB allocations, so I must reluctantly
concede that using an unsigned int is necessary.  If I were really into
bitshaving, I might force all allocations to be a multiple of 32-bytes
in size, and then we could use 16 bits to represent an allocation between
32 and 2MB, but I think that tips us beyond the complexity boundary.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.