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 12:07:49 -0600 (CST)
From: Christopher Lameter <>
To: Matthew Wilcox <>
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, 16 Jan 2018, Matthew Wilcox wrote:

> > Sure this data is never changed. It can be const.
> It's changed at initialisation.  Look:
> kmem_cache_create(const char *name, size_t size, size_t align,
>                   slab_flags_t flags, void (*ctor)(void *))
>         s = create_cache(cache_name, size, size,
>                          calculate_alignment(flags, align, size),
>                          flags, ctor, NULL, NULL);
> The 'align' that ends up in s->align, is not the user-specified align.
> It's also dependent on runtime information (cache_line_size()), so it
> can't be calculated at compile time.

Then we would need another align field in struct kmem_cache that takes the
changes value?

> 'flags' also gets mangled:
>         flags &= CACHE_CREATE_MASK;

Well ok then that also belongs into kmem_cache and the original value
stays in kmem_cache_attr.

> unsigned int would be my preference.


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.