linux-kernel - Re: [patch] slab: Do not use mempolicy for kmalloc

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]

Message-ID: <Pine.LNX.4.64.0609131641340.20799@schroedinger.engr.sgi.com>
Date:	Wed, 13 Sep 2006 16:48:58 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Ravikiran G Thirumalai <kiran@...lex86.org>
cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Alok Kataria <alok.kataria@...softinc.com>,
	"Shai Fultheim (Shai@...lex86.org)" <shai@...lex86.org>,
	Christoph Lameter <clameter@...r.sgi.com>,
	"Benzi Galili (Benzi@...leMP.com)" <benzi@...lemp.com>
Subject: Re: [patch] slab: Do not use mempolicy for kmalloc_node

On Wed, 13 Sep 2006, Ravikiran G Thirumalai wrote:

> > We only do this under certain conditions. The main purpose of this 
> > function is to allocate an object without having specified a node.
> 
> Yes, the conditions being cpuset constraints or a mempolicy being in place.
> Again, since objects can be allocated off other nodes under certain
> conditions, I thought it was good to document it...

This is only true for the CONFIG_NUMA case.

> This is the case when we are requesting an object from a non existent
> node/invalid node.  So we have 2 choices, either to spread the allocations 
> as per the cpuset constraints (the same treatment as kmalloc), or to 
> allocate from the requesting node, either ways we are not strictly 
> confirming to the user's choice of node (which we cannot).  I cannot see 
> major advantage or disadvantage either ways, so I chose to keep the policy
> in current mainline code -- spread according to the policy set.

The two cases were your patch still applied memory policies were:

1. nodeid = -1. This is one particular case that we wanted to fix because
   it means use numa_node_id().

2. The case where the nodelist does not yet exist.

AFAIK this situation only occurs on boot strap when we are actually 
attempting to allocate from a different node than what we are running on. 
Falling back to the local node is the right thing to do because we have 
that already working. A process that is running on a node must always have 
the nodelists for all caches allocated. The cpuup callbacks take care of that.

kmalloc_node needs work like page_alloc_node. page_alloc_node() never 
consults memory policies and thus one would not expect kmalloc_node to do 
so either.
-
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/