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.1209281326070.21335@chino.kir.corp.google.com>
Date:	Fri, 28 Sep 2012 13:30:31 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Christoph Lameter <cl@...ux.com>
cc:	Glauber Costa <glommer@...allels.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 Fri, 28 Sep 2012, Christoph Lameter wrote:

> > No, it's implementation defined so it shouldn't be in kmem_cache_create(),
> > it should be in __kmem_cache_create()
> 
> The flags are standardized between allocators. We carve out a couple of
> bits here that can be slab specific.
> 

That's true today, it won't be true in a week.

> > I'm referring to additional slab allocators that will be proposed for
> > inclusion shortly.
> 
> I am sorry but we cannot consider something that has not been discussed
> and publicly reviewed on the mailing list before. We have no way to
> understand your rationales at this point and it would take quite some time
> to review a new allocator. I would at least have expected the design of
> the allocator to be discussed on linux-mm. Nothing of that nature has
> happened as far as I can tell.
> 

Nobody here is disagreeing that the patch here is fine for slab, slub, 
and slob as they are currently implemented.  I'm simply trying to avoid 
ripping it out later and asking Glauber to consider something else that 
achieves what he needs.  There is, until this patch, no requirement 
anywhere that the flags passed to kmem_cache_create() may not be extended 
for allocator-specific behavior and I'd prefer to avoid adding such a 
specification unless absolutely necessary; in this case, there is an 
alternative that I've already outlined and it seems like Glauber is 
comfortable with using.
--
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/