Thread (17 messages) 17 messages, 4 authors, 2020-03-20

Re: [RFC 1/2] mm, slub: prevent kmalloc_node crashes and memory leaks

From: Vlastimil Babka <hidden>
Date: 2020-03-20 08:43:16
Also in: linux-mm

On 3/20/20 8:46 AM, Srikar Dronamraju wrote:
* Vlastimil Babka [off-list ref] [2020-03-19 15:10:19]:
quoted
On 3/19/20 3:05 PM, Srikar Dronamraju wrote:
quoted
* Vlastimil Babka [off-list ref] [2020-03-19 14:47:58]:
No, but AFAICS, such node values are already handled in ___slab_alloc, and
cannot reach get_partial(). If you see something I missed, please do tell.
Ah I probably got confused with your previous version where
alloc_slab_page() was modified. I see no problems with this version.
Thanks!
Sorry for the noise.
No problem.
A question just for my better understanding,
How worse would it be to set node to numa_mem_id() instead of NUMA_NODE_ID
when the current node is !N_NORMAL_MEMORY?
(I'm assuming you mean s/NUMA_NODE_ID/NUMA_NO_NODE/)

Well, numa_mem_id() should work too, but it would make the allocation
constrained to the node of current cpu, with all the consequences (deactivating
percpu slab if it was from a different node etc).

There's no reason why this cpu's node should be the closest node to the one that
was originally requested (but has no memory), so it's IMO pointless or even
suboptimal to constraint to it. This can be revisited in case we get guaranteed
existence of node data with zonelists for all possible nodes, but for now
NUMA_NO_NODE seems the most reasonable fix to me.
quoted
quoted
quoted
 	if (object || node != NUMA_NO_NODE)
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help