Re: [RFC][PATCH v3 09/16] genirq/irqdesc: Have nr_irqs as non-static

From: David Hildenbrand
Date: Wed Sep 17 2025 - 11:48:02 EST

On 17.09.25 17:32, Eugen Hristev wrote:


On 9/17/25 18:18, David Hildenbrand wrote:
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 there is a mechanism to tag all this memory, or regions, into a
specific section, what we would do with it next ?
It would have a purpose to be parsed and reused by different drivers,
that would be able to actually use it.
So there has a to be some kind of middleman, that holds onto this list
of regions, manages it (unique id, add/remove), and allows certain
drivers to use it.

Right, just someone that maintains the list and possibly allows traversing the list and possibly getting notifications on add/remove.

Now it would be interesting to have different kind of drivers connect to
it (or backends how I called them).
One of these programs an internal table for the firmware to use.
Another , writes information into a dedicated reserved-memory for the
bootloader to use on the next soft reboot (memory preserved).
I called this middleman kmemdump. But it can be named differently, and
it can reside in different places in the kernel.
But what I would like to avoid is to just tag all this memory and have
any kind of driver connect to the table. That works, but it's quite
loose on having control over the table. E.g. no kmemdump, tag all the
memory to sections, and have specific drivers (that would reside where?)
walk it.

Yeah, you want just some simple "registry" with traversal+notification.



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)

Just because I thought about it again, "named memory" could be an alternative to "tagged memory".

--
Cheers

David / dhildenb