On 06.10.25 18:25, Breno Leitao wrote:
On Mon, Oct 06, 2025 at 10:16:26AM +0200, David Hildenbrand wrote:
On 03.10.25 17:51, Breno Leitao wrote:
Hello Jiri,
On Thu, Jun 12, 2025 at 12:11:19PM +0200, Jiri Bohac wrote:
Currently this is only the case for memory ballooning and zswap. Such movable
memory will be missing from the vmcore. User data is typically not dumped by
makedumpfile.
For zswap and zsmalloc pages, I'm wondering whether these pages will be missing
from the vmcore, or if there's a possibility they might be present but
corrupted—especially since they could reside in the CMA region, which may be
overwritten by the kdump environment.
That's not different to ordinary user pages residing on these areas, right?
Will zsmalloc on CMA pages be marked as "userpages"?
No, but they should have the zsmalloc page type set.
makedump file iterates over the pfns and check for a few flags before
"copying" them to disk.
In makedumpfile, userpages are basically discarded if they are anonymous
pages:
#define isAnon(mapping, flags, _mapcount) \
(((unsigned long)mapping & PAGE_MAPPING_ANON) != 0 &&
!isSlab(flags,
_mapcount))
https://github.com/makedumpfile/makedumpfile/blob/master/makedumpfile.h#L164
called from:
https://github.com/makedumpfile/makedumpfile/blob/master/makedumpfile.c#L6671
For zsmalloc pages in the CMA, The page struct (pfn)) is marked with old
page struct (from the first kernel), but, the content has changed
(replaced by kdump environment - 2nd kernel).
So, whatever decision makedumpfile does based on the PFN, it will dump
incorrect data, given that the page content does not match the data
anymore.
Right.
If my understanding is valid, we don't want to dump any page that points
to the PFN, because they will probably have garbage.
My theory is that barely anybody will go ahead and check compressed page
content, but I agree. We should filter them out.
That said, I see two options:
1) Ignore the CMA area completely in makedump.
- I don't think there is any way to find that area today. The kernel
might need to print the CMA region somewhere (/proc/iomem?)
/proc/iomem in the newkernel should indicate the memory region as System
RAM (for the new kernel). That can just be filtered out in any case:
dumping memory of the new kernel does not make sense in any case.
2) Given that most of the memory in CMA will be anonymous memory, and
already discard by other rules, just add an additional entry for
zsmalloc pages.
Talking to Kirill offline, it seems we can piggy back on MovableOps
page flag.
We should likely check the page type instead if we go down that path.
--
Cheers
David / dhildenb
