On 17.09.25 16:10, Thomas Gleixner wrote:
On Wed, Sep 17 2025 at 09:16, David Hildenbrand wrote:
On 17.09.25 07:43, Eugen Hristev wrote:
On 9/17/25 00:16, Thomas Gleixner wrote:
I pointed you to a solution for that and just because David does not
like it means that it's acceptable to fiddle in subsystems and expose
their carefully localized variables.
It would have been great if we could have had that discussion in the
previous thread.
Sorry. I was busy with other stuff and did not pay attention to that
discussion.
I understand, I'm busy with too much stuff such that sometimes it might
be good to interrupt me earlier: "David, nooo, you're all wrong"
Some other subsystem wants to have access to this information. I agree
that exposing these variables as r/w globally is not ideal.
It's a nono in this case. We had bugs (long ago) where people fiddled
with this stuff (I assume accidentally for my mental sanity sake) and
caused really nasty to debug issues. C is a horrible language to
encapsulate stuff properly as we all know.
Yeah, there is this ACCESS_PRIVATE stuff but it only works with structs
and relies on sparse IIRC.
I raised the alternative of exposing areas or other information through
simple helper functions that kmemdump can just use to compose whatever
it needs to compose.
Do we really need that .section thingy?
The section thing is simple and straight forward as it just puts the
annotated stuff into the section along with size and id and I definitely
find that more palatable, than sprinkling random functions all over the
place to register stuff.
Sure, you can achieve the same thing with an accessor function. In case
of nr_irqs there is already one: irq_get_nr_irqs(), but for places which
Right, the challenge really is that we want the memory range covered by
that address, otherwise it would be easy.
do not expose the information already for real functional reasons adding
such helpers just for this coredump muck is really worse than having a
clearly descriptive and obvious annotation which results in the section
build.
Yeah, I'm mostly unhappy about the "#include <linux/kmemdump.h>" stuff.
Guess it would all feel less "kmemdump" specific if we would just have a
generic way to tag/describe certain physical memory areas and kmemdump
would simply make use of that.
For example, wondering if it could come in handy to have an ordinary
vmcoreinfo header contain this information as well?
Case in point, right now we do in crash_save_vmcoreinfo_init()
VMCOREINFO_SYMBOL_ARRAY(mem_section);
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
VMCOREINFO_STRUCT_SIZE(mem_section);
And in kmemdump code we do
kmemdump_register_id(KMEMDUMP_ID_COREIMAGE_mem_section,
(void *)&mem_section, sizeof(mem_section));
I guess both cases actually describe roughly the same information: An
area with a given name.
Note 1: Wondering if sizeof(mem_section) is actually correct in the
kmemdump case
Note 2: Wondering if kmemdump would also want the struct size, not just
the area length.
(memblock alloc wrappers are a separate discussion)
The charm of sections is that they don't neither extra code nor stubs or
ifdeffery when a certain subsystem is disabled and therefore no
information available.
Extra code is a very good point.
I'm not insisting on sections, but having a table of 2k instead of
hundred functions, stubs and whatever is definitely a win to me.
So far it looks like it's not that many, but of course, the question
would be how it evolves.
--
Cheers
David / dhildenb
