| 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
| ||
|
Message-ID: <Pine.LNX.4.64.0704061328270.23939@schroedinger.engr.sgi.com> 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/
Powered by blists - more mailing lists