On 18.09.25 15:53, Eugen Hristev wrote:
On 9/18/25 11:23, Thomas Gleixner wrote:
On Wed, Sep 17 2025 at 21:03, David Hildenbrand wrote:
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
We discussed that maybe one would want some kind of a "class"
description. For example we might have to register one pgdat area per
node. Giving each one a unique name might be impractical / unreasonable.
Still, someone would want to select / filter out all entries of the same
"class".
Just a thought.
Right. As I said this was mostly a insta brain dump to start a
discussion. Seems it worked :)
@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.
Question would be if that is not up to a consumer to decide ("allowlist"
/ filter) by class or id, stored elsewhere.
Yes, I looked at it the wrong way round. We should leave the filtering
to the consumers. If you use allow lists, then a newly introduced class
won't be automatically exposed everywhere.
Thanks,
tglx
So, one direction to follow from this discussion is to have the
inspection entry and inspection table for all these entries.
Now, one burning question open for debate, is, should this reside into mm ?
mm/inspect.h would have to define the inspection entry struct, and some
macros to help everyone add an inspection entry.
E.g. INSPECTION_ENTRY(my ptr, my size);
and this would be used all over the kernel wherever folks want to
register something.
If we're moving this to kernel/ or similar I'd suggest to not call this
only "inspect" but something that somehow contains the term "mem".
"mem-inspect.h" ?
Now the second part is, where to keep all the inspection drivers ?
Would it make sense to have mm/inspection/inspection_helpers.h which
would keep the table start/end, some macros to traverse the tables, and
this would be included by the inspection drivers.
inspection drivers would then probe via any mechanism, and tap into the
inspection table.
Good question. I think some examples of alternatives might help to
driver that discussion.
I am thinking that my model with a single backend can be enhanced by
allowing any inspection driver to access it. And further on, each
inspection driver would register a notifier to be called when an entry
is being created or not. This would mean N possible drivers connected to
the table at the same time. ( if that would make sense...)
Yeah, I think some notifier mechanism is what we want.
Would it make sense for pstore to have an inspection driver that would
be connected here to get different kinds of stuff ?
Something for the pstore folks to answer :)
Would it make sense to have some debugfs driver that would just expose
to user space different regions ? Perhaps something similar with
/proc/kcore but not the whole kernel memory rather only the exposed
inspection entries.
Definetly, this is what I previously mentioned. Maybe we would only
indicate region metadata and actual access to regions would simply
happen through /proc/kcore if someone wants to dump data from user space.
Now, for the dynamic memory, e.g. memblock_alloc and friends ,
would it be interesting to have a flag e.g. MEMBLOCK_INSPECT, that would
be used when calling it, and in the background, this would request an
inspection_entry being created ? Or it makes more sense to call some
function like inspect_register as a different call directly at the
allocation point ?
We'd probably want some interface to define the metadata
(name/class/whatever), a simple flag likely will not do, right?
--
Cheers
David / dhildenb
