[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ffc43855-2263-408d-831c-33f518249f96@redhat.com>
Date: Wed, 30 Jul 2025 15:52:45 +0200
From: David Hildenbrand <david@...hat.com>
To: Eugen Hristev <eugen.hristev@...aro.org>, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-arch@...r.kernel.org,
linux-mm@...ck.org, tglx@...utronix.de, andersson@...nel.org,
pmladek@...e.com
Cc: linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org,
corbet@....net, mojha@....qualcomm.com, rostedt@...dmis.org,
jonechou@...gle.com, tudor.ambarus@...aro.org
Subject: Re: [RFC][PATCH v2 22/29] mm/numa: Register information into Kmemdump
On 24.07.25 15:55, Eugen Hristev wrote:
> Annotate vital static information into kmemdump:
> - node_data
>
> Information on these variables is stored into dedicated kmemdump section.
>
> Register dynamic information into kmemdump:
> - dynamic node data for each node
>
> This information is being allocated for each node, as physical address,
> so call kmemdump_phys_alloc_size that will allocate an unique kmemdump
> uid, and register the virtual address.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@...aro.org>
> ---
> mm/numa.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/mm/numa.c b/mm/numa.c
> index 7d5e06fe5bd4..88cada571171 100644
> --- a/mm/numa.c
> +++ b/mm/numa.c
> @@ -4,9 +4,11 @@
> #include <linux/printk.h>
> #include <linux/numa.h>
> #include <linux/numa_memblks.h>
> +#include <linux/kmemdump.h>
>
> struct pglist_data *node_data[MAX_NUMNODES];
> EXPORT_SYMBOL(node_data);
> +KMEMDUMP_VAR_CORE(node_data, MAX_NUMNODES * sizeof(struct pglist_data));
>
> /* Allocate NODE_DATA for a node on the local memory */
> void __init alloc_node_data(int nid)
> @@ -16,7 +18,8 @@ void __init alloc_node_data(int nid)
> int tnid;
>
> /* Allocate node data. Try node-local memory and then any node. */
> - nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
> + nd_pa = kmemdump_phys_alloc_size(nd_size, memblock_phys_alloc_try_nid,
> + nd_size, SMP_CACHE_BYTES, nid);
Do we really want to wrap memblock allocations in such a way? :/
Gah, no, no no.
Can't we pass that as some magical flag, or just ... register *after*
allocating?
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists