mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	 Breno Leitao <leitao@debian.org>, Chris Mason <mason@kernel.org>,
	 Thomas Gleixner <tglx@kernel.org>,
	x86@kernel.org,  kexec@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-riscv@lists.infradead.org,  loongarch@lists.linux.dev,
	linux-mips@vger.kernel.org,  linux-sh@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	 David Hildenbrand <david@kernel.org>,
	 "Christian Brauner (Amutable)" <brauner@kernel.org>,
	stable@vger.kernel.org
Subject: [PATCH RFC 0/4] crash_dump: recover from machine checks in copy_oldmem_page()
Date: Thu, 12 Nov 2026 17:37:06 +0100	[thread overview]
Message-ID: <20261112-work-procfs-oldmem-v1-0-ecdcafd99265@kernel.org> (raw)

A capture kernel reads the memory of the crashed kernel. That memory
may have uncorrectable errors in it. Which is likely also what murdered
the first kernel.

On x86 a machine check in the copy that /proc/vmcore does out of an old
page panics the capture kernel. On book3s64 the read() comes up short
and splice() panics. Breno has observed that on a fleet iiuc. The first
kernel dies of a machine check and then there's no vmcore either.

I had the powerpc half of this as a fix in part 1 of the procfs series
because Chris ran into it there. Breno pointed out that x86 has the same
hole.

I think that likely makes this a kdump problem and not a procfs problem.
So I moved this out together with the ioremap_cache() fix.

The first two patches make powerpc's and sh's copy_oldmem_page() check
whether mapping the old page worked.

Every architecture that maps a page of the old kernel copies it out with
copy_to_iter(). The third patch puts that copy into a new
copy_oldmem_to_iter() helper. It's just copy_to_iter() with
_copy_mc_to_iter() underneath.

On x86_64 (and book3s64 - whatever that is) that's the machine check
safe copy and the machine check turns into a short read and -EFAULT.
Everywhere else it's copy_to_iter() under another name.

I then convert the remaining architectures so the copy lives in one
place and any new architecture with ARCH_HAS_COPY_MC later gets this for
free.

I reproduced the x86 panic in a kdump VM by injecting a machine check
into the copy. Without it the capture kernel is gone, with it the read()
fails with EFAULT and the kernel logs the event and keeps going.

The helper is a static inline in crash_dump.h and that pulls uio.h into
it. If people would rather have it out of line it can go into
kernel/crash_core.c, which builds for CRASH_DUMP just like the arch
crash_dump.c files do.

Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
Christian Brauner (4):
      powerpc/crash_dump: check ioremap_cache() in copy_oldmem_page()
      sh/crash_dump: check ioremap() in copy_oldmem_page()
      crash_dump: recover from a machine check in copy_oldmem_page()
      crash_dump: use copy_oldmem_to_iter() everywhere

 arch/arm/kernel/crash_dump.c       |  2 +-
 arch/arm64/kernel/crash_dump.c     |  2 +-
 arch/loongarch/kernel/crash_dump.c |  2 +-
 arch/mips/kernel/crash_dump.c      |  2 +-
 arch/powerpc/kernel/crash_dump.c   |  6 ++++--
 arch/riscv/kernel/crash_dump.c     |  2 +-
 arch/sh/kernel/crash_dump.c        |  5 ++++-
 arch/x86/kernel/crash_dump_32.c    |  2 +-
 arch/x86/kernel/crash_dump_64.c    |  2 +-
 include/linux/crash_dump.h         | 22 ++++++++++++++++++++++
 10 files changed, 37 insertions(+), 10 deletions(-)
---
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
change-id: 20261112-work-procfs-oldmem-9e80c2ebab7b


             reply	other threads:[~2026-11-12 16:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 16:37 Christian Brauner [this message]
2026-11-12 16:37 ` [PATCH RFC 1/4] powerpc/crash_dump: check ioremap_cache() " Christian Brauner
2026-11-12 16:37 ` [PATCH RFC 2/4] sh/crash_dump: check ioremap() " Christian Brauner
2026-11-12 16:37 ` [PATCH RFC 3/4] crash_dump: recover from a machine check " Christian Brauner
2026-11-12 16:37 ` [PATCH RFC 4/4] crash_dump: use copy_oldmem_to_iter() everywhere Christian Brauner
2026-11-12 16:40 ` [PATCH RFC 0/4] crash_dump: recover from machine checks in copy_oldmem_page() Christian Brauner

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=20261112-work-procfs-oldmem-v1-0-ecdcafd99265@kernel.org \
    --to=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=kexec@lists.infradead.org \
    --cc=leitao@debian.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=mason@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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

all inboxes | Powered by JetHome®