linux-kernel - Re: [PATCH] slab: Ignore internal flags in cache creation

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]

Message-ID: <alpine.DEB.2.00.1209271552350.13360@chino.kir.corp.google.com>
Date:	Thu, 27 Sep 2012 15:56:03 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Glauber Costa <glommer@...allels.com>
cc:	Christoph Lameter <cl@...ux.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...e.cz>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH] slab: Ignore internal flags in cache creation

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().

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