On Wed, Sep 17 2025 at 17: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:
>>>> 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"
I know that feeling.
>> 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.
I'd rather call it inspection.
> 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).
Correct.
>> this would go to a separate section called .tagged_memory.
That'd be confusing vs. actual memory tags, no?
> Maybe just "tagged_memory.h" or sth. like that? I'm bad at naming, so I
> would let others make better suggestions.
inspect.h :)
I'm going to use 'inspect' as prefix for the thoughts below, but that's
obviously subject to s/inspect/$BETTERNAME/g :)
>> 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.
Right. We really don't want to have five different mechanisms for five
infrastructures which all allow to inspect kernel memory (life or
dead) in one way or the other. The difference between them is mostly:
- Which subset of the information they expose for inspection
- The actual exposure mechanism: crash dump, firmware storage,
run-time snapshots in a filesystem, ....
Having one shared core infrastructure to expose data to those mechanisms
makes everyones life simpler.
That obviously needs to collect the superset of data, but that's just a
bit more memory consumed. That's arguably significantly smaller than
supporting a zoo of mechanisms to register data for different
infrastructures.
I'm quite sure that at least a substantial amount of the required
information can be collected at compile time in special section
tables. The rest can be collected in runtime tables, which have the same
format as the compile time section tables to avoid separate parsers.
Let me just float some ideas here, how that might look like. It might be
completely inpractical, but then it might be at least fodder for
thoughts.
As this is specific for the compiled kernel version you can define an
extensible struct format for the table.
struct inspect_entry {
unsigned long properties;
unsigned int type;
unsigned int id;
const char name[$MAX_NAME_LEN];
unsigned long address;
unsigned long length;
....
};
@type
refers either to a table with type information, which describes
the struct in some way or just generate a detached compile time
description.
@id
a unique id created at compile time or via registration at
runtime. Might not be required
@name:
Name of the memory region. That might go into a separate table
which is referenced by @id, but that's up for debate.
@address:
@length:
obvious :)
...
Whatever a particular consumer might require
@properties:
A "bitfield", which allows to mark this entry as (in)valid for a
particular consumer.
That obviously requires to modify these properties when the
requirements of a consumer change, new consumers arrive or new
producers are added, but I think it's easier to do that at the
producer side than maintaining filters on all consumer ends
forever.
Though I might be wrong as usual. IOW this needs some thoughts. :)
The interesting engineering challenge with such a scheme is to come up
with a annotation mechanism which is extensible.
Runtime is trivial as it just needs to fill in the new field in the
datastructure and all other runtime users have that zero
initialized automatically, if you get the mechanism correct in the
first place. Think in templates :)
Compile time is a bit more effort, but that should be solvable with
key/value pairs.
Don't even waste a thought about creating the final tables and
sections in macro magic. All the annotation macros have to do is to
emit the pairs in a structured way into discardable sections.
Those section are then converted in post processing into the actual
section table formats and added to the kernel image. Not a
spectacular new concept. The kernel build does this already today.
Just keep the compile time annotation macro magic simple and
stupid. It can waste 10k per entry at compile time and then let
postprocessing worry about downsizing and consolidation. Nothing to
see here :)
Hope that helps.
Thanks,
tglx
