From: Jiri Bohac <jbohac@suse.cz>
To: Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
kexec@lists.infradead.org, akpm@linux-foundation.org
Cc: 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: [PATCH v5 4/5] kdump: wait for DMA to finish when using CMA
Date: Thu, 12 Jun 2025 12:18:40 +0200 [thread overview]
Message-ID: <aEqpgDIBndZ5LXSo@dwarf.suse.cz> (raw)
In-Reply-To: <aEqnxxfLZMllMC8I@dwarf.suse.cz>
When re-using the CMA area for kdump there is a risk of pending DMA
into pinned user pages in the CMA area.
Pages residing in CMA areas can usually not get long-term pinned and
are instead migrated away from the CMA area, so long-term pinning is
typically not a concern. (BUGs in the kernel might still lead to
long-term pinning of such pages if everything goes wrong.)
Pages pinned without FOLL_LONGTERM remain in the CMA and may possibly
be the source or destination of a pending DMA transfer.
Although there is no clear specification how long a page may be pinned
without FOLL_LONGTERM, pinning without the flag shows an intent of the
caller to only use the memory for short-lived DMA transfers, not a transfer
initiated by a device asynchronously at a random time in the future.
Add a delay of CMA_DMA_TIMEOUT_SEC seconds before starting the kdump
kernel, giving such short-lived DMA transfers time to finish before
the CMA memory is re-used by the kdump kernel.
Set CMA_DMA_TIMEOUT_SEC to 10 seconds - chosen arbitrarily as both
a huge margin for a DMA transfer, yet not increasing the kdump time
too significantly.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Acked-by: David Hildenbrand <david@redhat.com>
---
Changes since v4:
- reworded the paragraph about long-term pinning
- simplified crash_cma_clear_pending_dma()
- dropped cma_dma_timeout_sec variable
---
Changes since v3:
- renamed CMA_DMA_TIMEOUT_SEC to CMA_DMA_TIMEOUT_MSEC, change delay to 10 seconds
- introduce a cma_dma_timeout_sec initialized to CMA_DMA_TIMEOUT_SEC
to make the timeout trivially tunable if needed in the future
---
kernel/crash_core.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 335b8425dd4b..a4ef79591eb2 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -21,6 +21,7 @@
#include <linux/reboot.h>
#include <linux/btf.h>
#include <linux/objtool.h>
+#include <linux/delay.h>
#include <asm/page.h>
#include <asm/sections.h>
@@ -33,6 +34,11 @@
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
+/* time to wait for possible DMA to finish before starting the kdump kernel
+ * when a CMA reservation is used
+ */
+#define CMA_DMA_TIMEOUT_SEC 10
+
#ifdef CONFIG_CRASH_DUMP
int kimage_crash_copy_vmcoreinfo(struct kimage *image)
@@ -97,6 +103,14 @@ int kexec_crash_loaded(void)
}
EXPORT_SYMBOL_GPL(kexec_crash_loaded);
+static void crash_cma_clear_pending_dma(void)
+{
+ if (!crashk_cma_cnt)
+ return;
+
+ mdelay(CMA_DMA_TIMEOUT_SEC * 1000);
+}
+
/*
* No panic_cpu check version of crash_kexec(). This function is called
* only when panic_cpu holds the current CPU number; this is the only CPU
@@ -119,6 +133,7 @@ void __noclone __crash_kexec(struct pt_regs *regs)
crash_setup_regs(&fixed_regs, regs);
crash_save_vmcoreinfo();
machine_crash_shutdown(&fixed_regs);
+ crash_cma_clear_pending_dma();
machine_kexec(kexec_crash_image);
}
kexec_unlock();
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, Prague, Czechia
next prev parent reply other threads:[~2025-06-12 13:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 10:11 [PATCH v5 0/5] kdump: crashkernel reservation from CMA Jiri Bohac
2025-06-12 10:13 ` [PATCH v5 1/5] Add a new optional ",cma" suffix to the crashkernel= command line option Jiri Bohac
2025-06-12 10:16 ` [PATCH v5 2/5] kdump: implement reserve_crashkernel_cma Jiri Bohac
2025-06-12 10:17 ` [PATCH v5 3/5] kdump, documentation: describe craskernel CMA reservation Jiri Bohac
2025-06-12 10:18 ` Jiri Bohac [this message]
2025-06-12 23:47 ` [PATCH v5 4/5] kdump: wait for DMA to finish when using CMA Andrew Morton
2025-06-13 9:19 ` David Hildenbrand
2025-06-14 2:41 ` Baoquan He
2025-06-19 12:46 ` Jiri Bohac
2025-06-12 10:20 ` [PATCH v5 5/5] x86: implement crashkernel cma reservation Jiri Bohac
2025-08-20 15:46 ` [PATCH v5 0/5] kdump: crashkernel reservation from CMA Breno Leitao
2025-08-20 16:20 ` Jiri Bohac
2025-08-21 8:35 ` Breno Leitao
2025-08-22 19:45 ` Jiri Bohac
2025-10-03 15:51 ` Breno Leitao
2025-10-06 8:16 ` David Hildenbrand
2025-10-06 16:25 ` Breno Leitao
2025-10-06 16:45 ` David Hildenbrand
2025-10-06 23:34 ` Tao Liu
2025-10-07 3:55 ` Baoquan He
2025-10-07 9:11 ` Jiri Bohac
2025-10-08 10:42 ` Breno Leitao
2025-10-13 4:03 ` [External] " Zhongkun He
2025-10-13 8:00 ` David Hildenbrand
2025-10-14 7:36 ` Zhongkun He
-- strict thread matches above, loose matches on Subject: below --
2025-05-30 20:23 [PATCH v4 " Jiri Bohac
2025-05-30 20:29 ` [PATCH v4 4/5] kdump: wait for DMA to finish when using CMA Jiri Bohac
2025-06-03 13:15 ` David Hildenbrand
2025-06-03 15:59 ` Jiri Bohac
2025-06-03 16:25 ` David Hildenbrand
2025-06-04 7:40 ` Jiri Bohac
2025-06-04 7:42 ` David Hildenbrand
2025-06-04 8:15 ` [PATCH v5 " 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=aEqpgDIBndZ5LXSo@dwarf.suse.cz \
--to=jbohac@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=ddutile@redhat.com \
--cc=dhildenb@redhat.com \
--cc=dyoung@redhat.com \
--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.