From: Vlastimil Babka <vbabka@suse.cz>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Sachin Sant <sachinp@linux.vnet.ibm.com>,
bharata@linux.ibm.com, Nathan Lynch <nathanl@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, Michal Hocko <mhocko@kernel.org>,
Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, Kirill Tkhai <ktkhai@virtuozzo.com>,
David Rientjes <rientjes@google.com>,
Christopher Lameter <cl@linux.com>,
Mel Gorman <mgorman@techsingularity.net>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [RFC 1/2] mm, slub: prevent kmalloc_node crashes and memory leaks
Date: Fri, 20 Mar 2020 09:43:11 +0100 [thread overview]
Message-ID: <90075919-dd9b-e38a-47a8-aea8520b3b94@suse.cz> (raw)
In-Reply-To: <20200320074638.GG4879@linux.vnet.ibm.com>
On 3/20/20 8:46 AM, Srikar Dronamraju wrote:
> * Vlastimil Babka <vbabka@suse.cz> [2020-03-19 15:10:19]:
>
>> On 3/19/20 3:05 PM, Srikar Dronamraju wrote:
>> > * Vlastimil Babka <vbabka@suse.cz> [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.
>> >> if (object || node != NUMA_NO_NODE)
>> >
>>
>
next prev parent reply other threads:[~2020-03-20 8:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 14:42 Vlastimil Babka
2020-03-18 14:42 ` [RFC 2/2] Revert "topology: add support for node_to_mem_node() to determine the fallback node" Vlastimil Babka
2020-03-18 16:06 ` [RFC 1/2] mm, slub: prevent kmalloc_node crashes and memory leaks Bharata B Rao
2020-03-18 16:10 ` Vlastimil Babka
2020-03-18 16:51 ` Vlastimil Babka
2020-03-19 8:52 ` Sachin Sant
2020-03-19 13:23 ` Vlastimil Babka
2020-03-19 13:26 ` Sachin Sant
2020-03-19 13:47 ` Vlastimil Babka
2020-03-19 14:05 ` Srikar Dronamraju
2020-03-19 14:10 ` Vlastimil Babka
2020-03-20 7:46 ` Srikar Dronamraju
2020-03-20 8:43 ` Vlastimil Babka [this message]
2020-03-20 10:10 ` Srikar Dronamraju
2020-03-19 14:59 ` Sachin Sant
2020-03-20 3:42 ` Bharata B Rao
2020-03-20 8:37 ` Vlastimil Babka
2020-03-20 8:44 ` Bharata B Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=90075919-dd9b-e38a-47a8-aea8520b3b94@suse.cz \
--to=vbabka@suse.cz \
--cc=bharata@linux.ibm.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nathanl@linux.ibm.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sachinp@linux.vnet.ibm.com \
--cc=srikar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox