linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Eugen Hristev <eugen.hristev@linaro.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-mm@kvack.org,
	tglx@linutronix.de, andersson@kernel.org, pmladek@suse.com
Cc: linux-arm-kernel@lists.infradead.org,
	linux-hardening@vger.kernel.org, corbet@lwn.net,
	mojha@qti.qualcomm.com, rostedt@goodmis.org, jonechou@google.com,
	tudor.ambarus@linaro.org
Subject: Re: [RFC][PATCH v2 22/29] mm/numa: Register information into Kmemdump
Date: Wed, 30 Jul 2025 15:52:45 +0200	[thread overview]
Message-ID: <ffc43855-2263-408d-831c-33f518249f96@redhat.com> (raw)
In-Reply-To: <20250724135512.518487-23-eugen.hristev@linaro.org>

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@linaro.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


  reply	other threads:[~2025-07-30 13:52 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-24 13:54 [RFC][PATCH v2 00/29] introduce kmemdump Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 01/29] kmemdump: " Eugen Hristev
2025-07-26  3:33   ` Randy Dunlap
2025-07-26  3:36   ` Randy Dunlap
2025-07-24 13:54 ` [RFC][PATCH v2 02/29] Documentation: add kmemdump Eugen Hristev
2025-07-24 14:13   ` Jonathan Corbet
2025-07-24 13:54 ` [RFC][PATCH v2 03/29] kmemdump: add coreimage ELF layer Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 04/29] Documentation: kmemdump: add section for coreimage ELF Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 05/29] kmemdump: introduce qcom-minidump backend driver Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 06/29] soc: qcom: smem: add minidump device Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 07/29] init/version: Annotate static information into Kmemdump Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 08/29] cpu: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 09/29] genirq/irqdesc: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 10/29] panic: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 11/29] sched/core: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 12/29] timers: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 13/29] kernel/fork: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 14/29] mm/page_alloc: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 15/29] mm/init-mm: " Eugen Hristev
2025-07-24 13:54 ` [RFC][PATCH v2 16/29] mm/show_mem: " Eugen Hristev
2025-07-30 13:55   ` David Hildenbrand
2025-07-30 14:04     ` Eugen Hristev
2025-07-30 14:10       ` David Hildenbrand
2025-07-24 13:55 ` [RFC][PATCH v2 17/29] mm/swapfile: " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 18/29] mm/percpu: " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 19/29] mm/mm_init: " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 20/29] printk: Register " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 21/29] kernel/configs: Register dynamic " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 22/29] mm/numa: Register " Eugen Hristev
2025-07-30 13:52   ` David Hildenbrand [this message]
2025-07-30 13:57     ` Eugen Hristev
2025-07-30 14:04       ` David Hildenbrand
2025-08-04 10:54         ` Michal Hocko
2025-08-04 11:06           ` Eugen Hristev
2025-08-04 12:18             ` David Hildenbrand
2025-08-04 12:29               ` Eugen Hristev
2025-08-04 12:49                 ` David Hildenbrand
2025-08-04 13:03                   ` Eugen Hristev
2025-08-04 13:26                     ` David Hildenbrand
2025-08-25 12:55                       ` Eugen Hristev
2025-08-25 13:20                         ` David Hildenbrand
2025-08-25 13:36                           ` Eugen Hristev
2025-08-25 13:58                             ` David Hildenbrand
2025-08-27 11:59                               ` Eugen Hristev
2025-08-27 12:18                                 ` David Hildenbrand
2025-08-27 14:08                                   ` Eugen Hristev
2025-08-27 20:06                                     ` David Hildenbrand
2025-09-01  8:57                                       ` Eugen Hristev
2025-09-01 10:01                                         ` David Hildenbrand
2025-09-01 12:02                                           ` Eugen Hristev
2025-09-01 12:17                                             ` David Hildenbrand
2025-08-04 12:16           ` David Hildenbrand
2025-07-24 13:55 ` [RFC][PATCH v2 23/29] mm/sparse: " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 24/29] kernel/vmcore_info: Register dynamic " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 25/29] kmemdump: Add additional symbols to the coreimage Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 26/29] init/version: Annotate init uts name separately into Kmemdump Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 27/29] kallsyms: Annotate static information " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 28/29] mm/init-mm: Annotate additional " Eugen Hristev
2025-07-24 13:55 ` [RFC][PATCH v2 29/29] kmemdump: Add Kinfo backend driver Eugen Hristev
2025-08-26 17:14 ` [RFC][PATCH v2 00/29] introduce kmemdump Mukesh Ojha
2025-08-27  6:42   ` Eugen Hristev

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=ffc43855-2263-408d-831c-33f518249f96@redhat.com \
    --to=david@redhat.com \
    --cc=andersson@kernel.org \
    --cc=corbet@lwn.net \
    --cc=eugen.hristev@linaro.org \
    --cc=jonechou@google.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mojha@qti.qualcomm.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tudor.ambarus@linaro.org \
    /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;
as well as URLs for NNTP newsgroup(s).