[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <vojlxf5pelxlr6omsfsccd4e4cdzn5qyxpgiqajorkgmgd7ruh@e5wwhkmvntpb>
Date: Fri, 3 Oct 2025 08:51:47 -0700
From: Breno Leitao <leitao@...ian.org>
To: Jiri Bohac <jbohac@...e.cz>
Cc: riel@...riel.com, vbabka@...e.cz, nphamcs@...il.com,
Baoquan He <bhe@...hat.com>, Vivek Goyal <vgoyal@...hat.com>, Dave Young <dyoung@...hat.com>,
kexec@...ts.infradead.org, akpm@...ux-foundation.org, Philipp Rudo <prudo@...hat.com>,
Donald Dutile <ddutile@...hat.com>, Pingfan Liu <piliu@...hat.com>, Tao Liu <ltao@...hat.com>,
linux-kernel@...r.kernel.org, David Hildenbrand <dhildenb@...hat.com>,
Michal Hocko <mhocko@...e.cz>
Subject: Re: [PATCH v5 0/5] kdump: crashkernel reservation from CMA
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.
My main question is: Do we need to explicitly teach makedumpfile to ignore the
CMA area in the vmcore, since it is already being overwritten and thus
unreliable? Or does makedumpfile already have mechanisms in place to
automatically ignore these special zswap/zsmalloc pages that may have been
overwritten if they were located in the CMA region?
Powered by blists - more mailing lists