From: Baoquan He <bhe@redhat.com>
To: Jiri Bohac <jbohac@suse.cz>
Cc: Vivek Goyal <vgoyal@redhat.com>, Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org, Philipp Rudo <prudo@redhat.com>,
Donald Dutile <ddutile@redhat.com>,
Pingfan Liu <piliu@redhat.com>, Tao Liu <ltao@redhat.com>,
linux-kernel@vger.kernel.org,
David Hildenbrand <dhildenb@redhat.com>,
Michal Hocko <mhocko@suse.cz>
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
Date: Mon, 3 Mar 2025 10:08:33 +0800 [thread overview]
Message-ID: <Z8UPIYFqAgiH8s6R@MiWiFi-R3L-srv> (raw)
In-Reply-To: <Z7dc9Cd8KX3b_brB@dwarf.suse.cz>
On 02/20/25 at 05:48pm, Jiri Bohac wrote:
......snip...
> ---
> Changes since v1:
>
> The key concern raised in the v1 discussion was that pages in the
> CMA region may be pinned and used for a DMA transfer, potentially
> corrupting the new kernel's memory. When the cma suffix is used, kdump
> may be less reliable and the corruption hard to debug
>
> This v2 series addresses this concern in two ways:
>
> 1) Clearly stating the potential problem in the updated
> Documentation and setting the expectation (patch 3/5)
>
> Documentation now explicitly states that:
> - the risk of kdump failure is increased
> - the CMA reservation is intended for users who can not or don't
> want to sacrifice enough memory for a standard crashkernel reservation
> and who prefer less reliable kdump to no kdump at all
>
> This is consistent with the documentation of the
> crash_kexec_post_notifiers option, which can also increase the
> risk of kdump failure, yet may be the only way to use kdump on
> some systems. And just like the crash_kexec_post_notifiers
> option, the cma crashkernel suffix is completely optional:
> the series has zero effect when the suffix is not used.
Thanks for the effort to investigate and add clear note about the
potential risk in document. Except of the 1 second waiting for short
term pined page for DMA, the whole series looks good to me. Hope other
people can also give comment to evaluate the risk of waiting, I will
wait another week to add my personal ACK.
Thanks
Baoquan
>
> 2) Giving DMA time to finish before booting the kdump kernel
> (patch 4/5)
>
> Pages can be pinned for long term use using the FOLL_LONGTERM
> flag. Then they are migrated outside the CMA region. Pinning
> without this flag shows that the intent of their user is to only
> use them for short-lived DMA transfers.
>
> Delay the boot of the kdump kernel when the CMA reservation is
> used, giving potential pending DMA transfers time to finish.
>
> Other minor changes since v1:
> - updated for 6.14-rc2
> - moved #ifdefs and #defines to header files
> - added __always_unused in parse_crashkernel() to silence a false
> unused variable warning
>
>
> --
> Jiri Bohac <jbohac@suse.cz>
> SUSE Labs, Prague, Czechia
>
>
next prev parent reply other threads:[~2025-03-03 2:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 16:48 [PATCH v2 0/5] kdump: crashkernel reservation from CMA Jiri Bohac
2025-02-20 16:51 ` [PATCH v2 1/5] Add a new optional ",cma" suffix to the crashkernel= command line option Jiri Bohac
2025-03-03 1:51 ` Baoquan He
2025-02-20 16:52 ` [PATCH v2 2/5] kdump: implement reserve_crashkernel_cma Jiri Bohac
2025-02-20 16:54 ` [PATCH v2 3/5] kdump, documentation: describe craskernel CMA reservation Jiri Bohac
2025-03-03 1:54 ` Baoquan He
2025-02-20 16:55 ` [PATCH v2 4/5] kdump: wait for DMA to finish when using CMA Jiri Bohac
2025-03-03 2:02 ` Baoquan He
2025-03-11 12:00 ` Jiri Bohac
2025-02-20 16:57 ` [PATCH v2 5/5] x86: implement crashkernel cma reservation Jiri Bohac
2025-03-03 2:08 ` Baoquan He [this message]
2025-03-03 8:25 ` [PATCH v2 0/5] kdump: crashkernel reservation from CMA David Hildenbrand
2025-03-03 14:17 ` Donald Dutile
2025-03-04 4:20 ` Baoquan He
2025-05-28 21:01 ` David Hildenbrand
2025-05-29 7:46 ` Michal Hocko
2025-05-29 9:19 ` Michal Hocko
2025-05-30 8:06 ` David Hildenbrand
2025-05-30 8:28 ` Michal Hocko
2025-05-30 8:39 ` David Hildenbrand
2025-05-30 9:07 ` Michal Hocko
2025-05-30 9:11 ` David Hildenbrand
2025-05-30 9:26 ` Michal Hocko
2025-05-30 9:28 ` David Hildenbrand
2025-05-30 9:34 ` Jiri Bohac
2025-05-30 9:47 ` David Hildenbrand
2025-05-30 9:54 ` Michal Hocko
2025-05-30 10:06 ` Jiri Bohac
2025-05-29 16:22 ` Jiri Bohac
2025-03-12 15:36 ` Jiri Bohac
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=Z8UPIYFqAgiH8s6R@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=ddutile@redhat.com \
--cc=dhildenb@redhat.com \
--cc=dyoung@redhat.com \
--cc=jbohac@suse.cz \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltao@redhat.com \
--cc=mhocko@suse.cz \
--cc=piliu@redhat.com \
--cc=prudo@redhat.com \
--cc=vgoyal@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.