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]

Date:	Fri, 28 Sep 2012 16:11:46 -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:

> > The first prototype, SLAM XP1, will be posted in October.  I'd simply like
> > to avoid reverting this patch down the road and having all of us
> > reconsider the topic again when clear alternatives exist that, in my
> > opinion, make the code cleaner.
> 
> If you want to make changes to the kernel then you need to justify that at
> the time when we can consider your patches and the approach taken.
> 

If I cannot speak up and say where there will be conflicts in the future 
and ask that Glauber spend more of his time down the road to figure all of 
this out again, especially when a simple and clean alternative exists, 
then that seems to result in a big waste of time.  Nothing is suffering 
from taking the alternative here, so please follow the best software 
engineering practices of allowing an implementation to reserve and ignore 
bits in an API when appropriate and not do it globally in the common code.

All of the move to mm/slab_common.c has obviously slowed down posting of 
SLAM and I haven't complained about that once or asked that it not be 
done, I'm simply pointing out an instance here that will conflict later on 
if we go with this patch.  That, to me, is respectful of other people's 
time.  That said, I'll leave it to Glauber to decide how he'd like to 
handle this issue given the knowledge of what is to come.

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