[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJCRgXYIjbJ01RsK@tiehlicka>
Date: Mon, 4 Aug 2025 12:54:57 +0200
From: Michal Hocko <mhocko@...e.com>
To: David Hildenbrand <david@...hat.com>
Cc: 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, 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 Wed 30-07-25 16:04:28, David Hildenbrand wrote:
> On 30.07.25 15:57, Eugen Hristev wrote:
[...]
> > 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?
All those symbols are part of kallsyms, right? Can we just use kallsyms
infrastructure and a list of symbols to get what we need from there?
In other words the list of symbols to be completely external to the code
that is defining them?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists