Hi, On 12/12/25 10:48 PM, Eugen Hristev wrote: > > > On 11/19/25 17:44, Eugen Hristev wrote: >> meminspect is a mechanism which allows the kernel to mark specific memory >> areas for memory dumping or specific inspection, statistics, usage. >> Once regions are marked, meminspect keeps an internal list with the regions >> in a dedicated table. > > [...] > > >> I will present this version at Plumbers conference in Tokyo on December 13th: >> https://lpc.events/event/19/contributions/2080/ >> I am eager to discuss it there face to face. > > Summary of the discussions at LPC talk on Dec 13th: > > One main idea on the static variables annotation was to do some linker > magic, to create a list of variables in the tree, that would be parsed > by some script, the addresses and sizes would be then stored into the > dedicated section at the script level, without having any C code change. > Pros: no C code change, Cons: it would be hidden/masked from the code, > easy to miss out, which might lead to people's variables being annotated > without them knowing > > Another idea was to have variables directly stored in a dedicated > section which would be added to the table. > e.g. static int __attribute(section (...)) nr_irqs; > Pros: no more meminspect section Cons: have to keep all interesting > variables in a separate section, which might not be okay for everyone. > > On dynamic memory, the memblock flag marking did not receive any obvious > NAKs. > > On dynamic memory that is bigger in size than one page, as the table > entries are registered by virtual address, this would be non-contiguous > in physical memory. How is this solved? > -> At the moment it's left for the consumer drivers to handle this > situation. If the region is a VA and the size > PAGE_SIZE, then the > driver needs to handle the way it handles it. Maybe the driver that > parses the entry needs to convert it into multiple contiguous entries, > or just have virtual address is enough. The inspection table does not > enforce or limit the entries to contiguous entries only. > > On the traverse/notifier system, the implementation did not receive any > obvious NAKs > > General comments: > > Trilok Soni from Qualcomm mentioned they will be using this into their > software deliveries in production. > > Someone suggested to have some mechanism to block specific data from > being added to the inspection table as being sensitive non-inspectable > data. > [Eugen]: Still have to figure out how that could be done. Stuff is not > being added to the table by default. > > Another comment was about what use case there is in mind, is this for > servers, or for confidential computing, because each different use case > might have different requirements, like ignoring some regions is an > option in one case, but bloating the table in another case might not be > fine. > [Eugen]: The meminspect scenario should cover all cases and not be too > specific. If it is generic enough and customizable enough to care for > everyone's needs then I consider it being a success. It should not > specialize in neither of these two different cases, but rather be > tailored by each use case to provide the mandatory requirements for that > case. > > Another comment mentioned that this usecase does not apply to many > people due to firmware or specific hardware needed. > [Eugen]: one interesting proposed usecase is to have a pstore > driver/implementation that would traverse the inspection table at panic > handler time, then gather data from there to store in the pstore > (ramoops, mtdoops or whatever backend) and have it available to the > userspace after reboot. This would be a nice use case that does not > require firmware nor specific hardware, just pstore backend support. > > Ending note was whether this implementation is going in a good direction > and what would be the way to having it moving upstream. > > Thanks everyone who attended and came up with ideas and comments. > There are a few comments which I may have missed, so please feel free to > reply to this email to start a discussion thread on the topic you are > interested in. > > Eugen >
Maybe you or someone else has already mentioned this. If so, sorry I missed it. How does this compare or contrast to VMCOREINFO? thanks. -- ~Randy
