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  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, 28 Sep 2012 14:12:54 +0000
From:	Christoph Lameter <>
To:	David Rientjes <>
cc:	Glauber Costa <>,,, Michal Hocko <>,
	Pekka Enberg <>
Subject: Re: [PATCH] slab: Ignore internal flags in cache creation

On Thu, 27 Sep 2012, David Rientjes wrote:

> On Thu, 27 Sep 2012, Glauber Costa wrote:
> > But I still don't see the big reason for your objection. If other
> > allocator start using those bits, they would not be passed to
> > kmem_cache_alloc anyway, right? So what would be the big problem in
> > masking them out before it?
> >
> A slab allocator implementation may allow for additional bits that are
> currently not used or used for internal purposes by the current set of
> slab allocators to be passed in the unsigned long to kmem_cache_create()
> that would be a no-op on other allocators.  It's implementation defined,
> so this masking should be done in the implementation, i.e.
> __kmem_cache_create().

Ok we can do that in the future. There is nothing in this patch that
prevents that from happening. It would affect the memcg implementation
because they can no longer simply grab the flags and pass them in for
creating another slab.

> For context, as many people who attended the kernel summit and LinuxCon
> are aware, a new slab allocator is going to be proposed soon that actually
> uses additional bits that aren't defined for all slab allocators.  My
> opinion is that leaving unused bits and reserved bits to the
> implementation is the best software engineering practice.

Could you please come out with the new allocator and post some patchsets?

We can extend the number of flags reserved if necessary but we really need
to see the source for that.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists