linux-kernel - Re: [GIT PULL] mm: Remove slab destructors from kmem_cache

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]

Message-ID: <20070723212420.GI11115@waste.org>
Date:	Mon, 23 Jul 2007 16:24:20 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Christoph Lameter <clameter@....com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] mm: Remove slab destructors from kmem_cache_create().

On Mon, Jul 23, 2007 at 02:04:44PM -0700, Christoph Lameter wrote:
> Please do not merge this patch. I will reuse the destructor field for
> the kmem_cache_ops in the slab defrag patchset. If you apply this patch
> then I need to readd the parameter later.

The vast majority of slabs won't have any cache ops, right? Wouldn't
it be cleaner to have a kmem_set_cache_ops() for the few that do?

While we're on the subject, has anyone reviewed your defrag stuff?

I read through it a while back and my initial impression is a) it's
awfully complex and invasive and b) it probably won't protect all
workloads.

As this and several other vexing problems stem from the dcache design,
I'd rather abandon the dcache out in the woods so we can replace it
with something less troublesome.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/