Message-ID: <5903a8e1-71c6-4546-ac50-35effa078dda@infradead.org>
Date: Fri, 12 Dec 2025 22:57:02 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: Eugen Hristev <eugen.hristev@...aro.org>, linux-arm-msm@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, tglx@...utronix.de,
 andersson@...nel.org, pmladek@...e.com, corbet@....net, david@...hat.com,
 mhocko@...e.com
Cc: tudor.ambarus@...aro.org, mukesh.ojha@....qualcomm.com,
 linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org,
 jonechou@...gle.com, rostedt@...dmis.org, linux-doc@...r.kernel.org,
 devicetree@...r.kernel.org, linux-remoteproc@...r.kernel.org,
 linux-arch@...r.kernel.org, tony.luck@...el.com, kees@...nel.org,
 Trilok Soni <tsoni@...cinc.com>, Kaushal Kumar <kaushalk@....qualcomm.com>,
 Shiraz Hashim <shashim@....qualcomm.com>,
 Peter Griffin <peter.griffin@...aro.org>, stephen.s.brennan@...cle.com,
 Will McVicker <willmcvicker@...gle.com>,
 "stefan.schmidt@...aro.org" <stefan.schmidt@...aro.org>
Subject: Re: [PATCH 00/26] Introduce meminspect

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

Powered by blists - more mailing lists