Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@redhat.com>
To: Pingfan Liu <kernelfans@gmail.com>
Cc: kexec@lists.infradead.org, Pingfan Liu <piliu@redhat.com>,
	Jiri Bohac <jbohac@suse.cz>, Michal Hocko <mhocko@suse.com>,
	Baoquan He <bhe@redhat.com>, Dave Young <dyoung@redhat.com>
Subject: Re: [RFC 0/3] kdump: Check mem_map of CMA area in kdump
Date: Tue, 19 Dec 2023 16:20:16 +0100	[thread overview]
Message-ID: <20231219162016.451bd2fa@rotkaeppchen> (raw)
In-Reply-To: <20231218052325.20982-1-kernelfans@gmail.com>

Hi Pingfan,

On Mon, 18 Dec 2023 13:23:22 +0800
Pingfan Liu <kernelfans@gmail.com> wrote:

> From: Pingfan Liu <piliu@redhat.com>
> 
> 
> First of all, this series is only for proof of concept. It only passes compilation.
> 
> For years, CMA is proposed to be used as crashkernel reserved memory.
> But DIO prevent us to follow it since DMA may be in-flight and ruin the
> kdump kernel.
> 
> This series exports the crash kernel's CMA area information through
> device-tree, and kdump kernel skips any page, which refcnt!=mapcount and
> has a potential DMA activity.
> 
> The exported information include:
> 	u64 kdump_cma_pfn;
> 	u64 kdump_cma_pg_cnt;
> 	u64 kdump_cma_pg_paddr;
> 
> And they should be filled with Jiri's series "[PATCH 0/4] kdump:
> crashkernel reservation from CMA"
> 
> After the conjunction of two series, the CMA used for kdump has only the
> following risk, where the following conditions:
> 	-1.a wrong code forges _refcnt and mapcount to the same value
> 	-2.the page is also used by DIO
> 
> 
> Is it acceptable, or any rescue e.g. CRC on page?
> 
> Please share your thoughts.

I don't think your approach will work as intended. The problem is that
we are dealing with two separate kernels and there is no guarantee that
both kernels are identical. So you cannot rely on the definition of
struct page in the crash kernel to be identical to the one in the
panicked kernel. Meaning check_poison_page from the crash kernel cannot
simply operate on the struct pages from the panicked kernel.

To get this approach to work I see three possible "fixes"

1) enforce in kexec that only the currently running kernel can be
loaded as crash kernel.

2) pass all required "debuginfo" to the crash kernel so it can parse
the required data reliably from the dump. This also requires to have
all the mm helper functions to be reimplemented to work in
check_poison_page.

3) the required information is passed via a new data structure which
is designed in a way that it can easily be passed in between different
kernels. But this would require the mm subsystem to maintain the page
states in the CMA in two separate data structures.

Personally I don't think that any of the three "fixes" is desirable.

Thanks
Philipp

> Thanks,
> 
> Pingfan
> 
> 
> Cc: Jiri Bohac <jbohac@suse.cz>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Philipp Rudo <prudo@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> To: kexec@lists.infradead.org
> ---
> Pingfan Liu (3):
>   crash_dump: Parse the CMA's mem_map in kdump
>   of: kexec: Set up properties for reusing CMA in kdump
>   of: fdt: Parse properties of reusing CMA in kdump
> 
>  drivers/of/fdt.c      | 43 +++++++++++++++++++++++
>  drivers/of/kexec.c    | 14 ++++++++
>  include/linux/kexec.h |  5 +++
>  init/main.c           |  4 +++
>  kernel/crash_dump.c   | 80 +++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 146 insertions(+)
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

      parent reply	other threads:[~2023-12-19 15:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-18  5:23 [RFC 0/3] kdump: Check mem_map of CMA area in kdump Pingfan Liu
2023-12-18  5:23 ` [RFC 1/3] crash_dump: Parse the CMA's mem_map " Pingfan Liu
2023-12-18  5:23 ` [RFC 2/3] of: kexec: Set up properties for reusing CMA " Pingfan Liu
2023-12-18  5:23 ` [RFC 3/3] of: fdt: Parse properties of " Pingfan Liu
2023-12-18 15:19 ` [RFC 0/3] kdump: Check mem_map of CMA area " Michal Hocko
2023-12-19 15:20 ` Philipp Rudo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231219162016.451bd2fa@rotkaeppchen \
    --to=prudo@redhat.com \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=jbohac@suse.cz \
    --cc=kernelfans@gmail.com \
    --cc=kexec@lists.infradead.org \
    --cc=mhocko@suse.com \
    --cc=piliu@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox