On 17.09.25 17:02, Eugen Hristev wrote:
On 9/17/25 17:46, David Hildenbrand wrote:
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.
The idea was to make "kmemdump" exactly this generic way to tag/describe
the memory.
That's probably where I got lost, after reading the cover letter
assuming that this is primarily to program kmemdump backends, which I
understood to just special hw/firmware areas, whereby kinfo acts as a
filter.
If we would call it differently , simply dump , would it be better ?
e.g. include linux/dump.h
and then DUMP(var, size) ?
could we call it maybe MARK ? or TAG ?
TAG_MEM(area, size)
I'm wondering whether there could be any other user for this kind of
information.
Like R/O access in a debug kernel to these areas, exporting the
ranges/names + easy read access to content through debugfs or something.
Guess that partially falls under the "dump" category.
Including that information in a vmcore info would probably allow to
quickly extract some information even without the debug symbols around
(I run into that every now and then).
this would go to a separate section called .tagged_memory.
Maybe just "tagged_memory.h" or sth. like that? I'm bad at naming, so I
would let others make better suggestions.
Then anyone can walk through the section and collect the data.
I am just coming up with ideas here.
Could it be even part of mm.h instead of having a new header perhaps ?
Then we won't need to include one more.
I don't really have something against a new include, just not one that
sounded like a very specific subsystem, not something more generic.
--
Cheers
David / dhildenb
