Re: [PATCH 00/26] Introduce meminspect

Re: [PATCH 00/26] Introduce meminspect

[Randy Dunlap]

On 12/15/25 10:54 PM, Randy Dunlap wrote:
> 
> 
> 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.

Although you copied Stephen Brennan on this, I think it would be a good idea
to copy the linux-debuggers@vger.kernel.org mailing list also to see if
there are any other comments about it. [now done]

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

-- 
~Randy

Re: [PATCH 00/26] Introduce meminspect

[Eugen Hristev]

On 12/16/25 09:00, Randy Dunlap wrote:
> 
> 
> On 12/15/25 10:54 PM, Randy Dunlap wrote:
>>
>>
>> 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.
> 
> Although you copied Stephen Brennan on this, I think it would be a good idea
> to copy the linux-debuggers@vger.kernel.org mailing list also to see if
> there are any other comments about it. [now done]

Thanks . I copied Stephen because we had a discussion at LPC at his talk
and he also attended my talk.

I also had a nice talk with Kees Cook and he was very interested in
having pstore as a backend for meminspect. (copied now as well)

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