linux-kernel - Re: [patch 2/2] slub: enforce cpuset restrictions for cpu slabs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Mar 2009 14:29:31 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Menage <menage@...gle.com>
cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 2/2] slub: enforce cpuset restrictions for cpu slabs

On Tue, 3 Mar 2009, Paul Menage wrote:

> > Unfortunately, we can't add a slab hardwall flag to the cpuset to
> > configure this behavior since that would require locking to dereference
> > in the fastpath.
> >
> 
> I don't think that it would - cgroups and subsystems should be RCU safe.
> 

That would help for cpusets that are looking for NUMA optimizations (i.e. 
probably long-lived objects with local affinity) but would not ensure 
memory isolation from tasks in other exclusive cpusets from allocating on 
my slab.

So to address both NUMA and memory isolation, it seems like we'd need to 
add a `slab_hardwall' flag that would have to be disabled for both cpusets 
(the one hosting the cpu slab and the one allocating an object) to ignore 
the hardwall requirement.

That isn't a very clean solution, but is certainly plausible if 
Christoph's objection is that in the vast majority of multiple cpuset 
systems it is far better to allocate on cpu slabs than for true memory 
isolation or the ability to allocate an object on a specific node (for 
which we currently have no solution) for affinity.
--
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/