On 30.07.25 15:57, Eugen Hristev wrote:
Hello,
On 7/30/25 16:52, David Hildenbrand wrote:
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@xxxxxxxxxx>
---
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?
Thanks for looking into my patch.
Yes, registering after is also an option. Initially this is how I
designed the kmemdump API, I also had in mind to add a flag, but, after
discussing with Thomas Gleixner, he came up with the macro wrapper idea
here:
https://lore.kernel.org/lkml/87ikkzpcup.ffs@tglx/
Do you think we can continue that discussion , or maybe start it here ?
Yeah, I don't like that, but I can see how we ended up here.
I also don't quite like the idea that we must encode here what to
include in a dump and what not ...
For the vmcore we construct it at runtime in
crash_save_vmcoreinfo_init(), where we e.g., have
VMCOREINFO_STRUCT_SIZE(pglist_data);
Could we similar have some place where we construct what to dump
similarly, just not using the current values, but the memory ranges?
Did you consider that?
--
Cheers,
David / dhildenb
