linux-kernel - Re: SLUB: Add Kconfig option for SLAB quirks

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] [day] [month] [year] [list]

Date:	Fri, 6 Apr 2007 13:31:48 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	linux-kernel@...r.kernel.org
Subject: Re: SLUB: Add Kconfig option for SLAB quirks

On Fri, 6 Apr 2007, Andrew Morton wrote:

> urgh.  It would be better to continue to rework slab/slub callers in the
> fashion which you have been doing, don't you think?

Yes definitely but I do not want to risk getting slub dropped from mm.

> Rephrasing my earlier point: are we doing things in the correct order here,
> and efficiently?  It is not settled in my mind whether we want to merge
> slub _at all_.  Do we have enough information yet to be able to make that
> decision?

Check the initial SLUB_V6 patch? It has long list of issues that were 
addressed.

> And if that information indicates that a slub merge _is_ justified, why is
> the chosen approach superior to the incremental one: if slab code is grotty
> (it is), clean it up.  If slab has unnecessary stuff, delete it.

SLUB is a fundamentally different design. We can address some of the 
warts in SLAB as we do the cleanup but the basic way of handling objects 
on queues is core to SLAB and is not used at all in SLUB.

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