Message-ID: <b74aef93-9138-413a-8327-36c746d67e10@infradead.org>
Date: Mon, 15 Dec 2025 22:54:24 -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



On 12/12/25 11:22 PM, Eugen Hristev wrote:
> 
> 
> On 12/13/25 08:57, Randy Dunlap wrote:
>> 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.
> 
> This inspection table could be created in an VMCOREINFO way, the patch
> series here[1] is something that would fit it best .
> 
> The drawbacks are :
> some static variables have to be registered to VMCOREINFO in their file
> of residence. This means including vmcoreinfo header and adding
> functions/code there, and everywhere that would be needed , or , the
> variables have to be un-static'ed , which is a no-go.
> This received more negative opinions on that particular patch series.
> The annotation idea seemed cleaner and simpler, and more generic.
> 
> We could add more and more entries to the vmcoreinfo table, but that
> would mean expanding it a lot, which it would maybe defy its purpose,
> and be getting too big, especially for the cases where custom drivers
> would like to register data.
> 
> How I see it, is that maybe the vmcoreinfo init function, could also
> parse the inspection table and create more entries if that is needed.
> So somehow memory inspection is a superset or generalization , while
> VMCOREINFO is a more particular use case that would fit here.
> 
> Do you think of some better way to integrate the meminspect table into
> VMCOREINFO ?

No, I just wanted to make sure that you or someone had looked into that.
Thanks for your summary.

> [1]
> https://lore.kernel.org/all/20250912150855.2901211-1-eugen.hristev@linaro.org/

-- 
~Randy

Powered by blists - more mailing lists