[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Jan 2018 08:05:25 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Christopher Lameter <cl@...ux.com>
Cc: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
David Windsor <dave@...lcore.net>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-xfs@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...nel.org>,
Christoph Hellwig <hch@...radead.org>,
"David S. Miller" <davem@...emloft.net>,
Laura Abbott <labbott@...hat.com>,
Mark Rutland <mark.rutland@....com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Christoffer Dall <christoffer.dall@...aro.org>,
Dave Kleikamp <dave.kleikamp@...cle.com>, Jan Kara <jack@...e.cz>,
Luis de Bethencourt <luisbg@...nel.org>,
Marc Zyngier <marc.zyngier@....com>, Rik van Riel <riel@...hat.com>,
Matthew Garrett <mjg59@...gle.com>, linux-fsdevel@...r.kernel.org,
linux-arch@...r.kernel.org, netdev@...r.kernel.org,
kernel-hardening@...ts.openwall.com
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.
