linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Tong Tiangen <tongtiangen@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	james.morse@arm.com
Subject: Re: [RFC PATCH -next V2 0/7]arm64: add machine check safe support
Date: Wed, 6 Apr 2022 11:04:41 +0100	[thread overview]
Message-ID: <Yk1luUxEIP3Dxt5c@FVFF77S0Q05N> (raw)
In-Reply-To: <20220406091311.3354723-1-tongtiangen@huawei.com>

Hi,

In future, for the arm64 uaccess stuff, could you please CC me, and for the
arm64 RAS bits (e.g. the SEA handling), could you please CC James Morse?

On Wed, Apr 06, 2022 at 09:13:04AM +0000, Tong Tiangen wrote:
> This patchset is based on[1].

That link below appears to be a single patch. Sending that separately makes
this harder to review, so in future could you please send this as a combined
series?

> With the increase of memory capacity and density, the probability of
> memory error increases. The increasing size and density of server RAM
> in the data center and cloud have shown increased uncorrectable memory
> errors.
> 
> Currently, the kernel has a mechanism to recover from hardware memory
> errors. This patchset provides an new recovery mechanism.
> 
> For ARM64, the hardware error handling is do_sea() which divided into
> two cases:
> 1. The user state consumed the memory errors, the solution is kill th
>      user process and isolate the error page.
> 2. The kernel state consumed the memory errors, the solution is panic.
> 
> For kernelspace, Undifferentiated panic maybe not the optimal choice,
> it can be handled better.
> 
> This patchset deals with four sscenarios of hardware memory error consumed
> in kernelspace:
> 1. copy_from_user.
> 2. get_user.

What about atomics to user memory? e.g. futexes, or the armv8_deprecated
emulations?

It seems the assumption is that writing to user memory (e.g. copy_to_user() and
put_user()) don't matter? Could you please mention why? e.g. do we never take
an exception for writes to memory with errors?

> 3. cow(copy on write).
> 4. pagecache reading.

There are a bunch of other places where we'll access user memory via the linear
map, so I assume this is just a best-effort "try not to die" rather than "never
die" ?

Are there other places we might need/want to expand this to in future?

Thanks,
Mark.

> These four scenarios have similarities. Although the error is consumed in
> the kernel state, but the consumed data belongs to the user state.
> 
> The processing scheme is based on CONFIG_ARCH_HAS_COPY_MC and uses the
> process killing plus isolate error page to replace kernel panic.
> 
> [1]https://lore.kernel.org/lkml/20220323033705.3966643-1-tongtiangen@huawei.com/
> 
> Since V2:
>  1.Consistent with PPC/x86, Using CONFIG_ARCH_HAS_COPY_MC instead of
>    ARM64_UCE_KERNEL_RECOVERY.
>  2.Add two new scenarios, cow and pagecache reading.
>  3.Fix two small bug(the first two patch).
> 
> Tong Tiangen (7):
>   x86: fix copy_mc_to_user compile error
>   arm64: fix page_address return value in copy_highpage
>   arm64: add support for machine check error safe
>   arm64: add copy_from_user to machine check safe
>   arm64: add get_user to machine check safe
>   arm64: add cow to machine check safe
>   arm64: add pagecache reading to machine check safe
> 
>  arch/arm64/Kconfig                   |  1 +
>  arch/arm64/include/asm/asm-extable.h | 25 +++++++
>  arch/arm64/include/asm/asm-uaccess.h | 16 +++++
>  arch/arm64/include/asm/esr.h         |  5 ++
>  arch/arm64/include/asm/extable.h     |  2 +-
>  arch/arm64/include/asm/page.h        | 10 +++
>  arch/arm64/include/asm/uaccess.h     | 17 ++++-
>  arch/arm64/kernel/probes/kprobes.c   |  2 +-
>  arch/arm64/lib/Makefile              |  2 +
>  arch/arm64/lib/copy_from_user.S      | 11 ++--
>  arch/arm64/lib/copy_page_mc.S        | 98 ++++++++++++++++++++++++++++
>  arch/arm64/lib/copy_to_user_mc.S     | 78 ++++++++++++++++++++++
>  arch/arm64/mm/copypage.c             | 36 ++++++++--
>  arch/arm64/mm/extable.c              | 21 +++++-
>  arch/arm64/mm/fault.c                | 30 ++++++++-
>  arch/x86/include/asm/uaccess.h       |  1 +
>  include/linux/highmem.h              |  8 +++
>  include/linux/uaccess.h              |  8 +++
>  include/linux/uio.h                  |  9 ++-
>  lib/iov_iter.c                       | 85 +++++++++++++++++++-----
>  mm/memory.c                          |  2 +-
>  21 files changed, 432 insertions(+), 35 deletions(-)
>  create mode 100644 arch/arm64/lib/copy_page_mc.S
>  create mode 100644 arch/arm64/lib/copy_to_user_mc.S
> 
> -- 
> 2.18.0.huawei.25
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-04-06 14:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06  9:13 [RFC PATCH -next V2 0/7]arm64: add machine check safe support Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 1/7] x86: fix copy_mc_to_user compile error Tong Tiangen
2022-04-06  9:22   ` Borislav Petkov
2022-04-06 10:02     ` Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 2/7] arm64: fix page_address return value in copy_highpage Tong Tiangen
2022-04-06 10:22   ` Mark Rutland
2022-04-06 12:47     ` Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 3/7] arm64: add support for machine check error safe Tong Tiangen
2022-04-06 10:58   ` Mark Rutland
2022-04-07 14:26     ` Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 4/7] arm64: add copy_from_user to machine check safe Tong Tiangen
2022-04-06 11:19   ` Mark Rutland
2022-04-07 14:28     ` Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 5/7] arm64: add get_user " Tong Tiangen
2022-04-06 11:22   ` Mark Rutland
2022-04-07 14:38     ` Tong Tiangen
2022-04-08 15:22       ` Mark Rutland
2022-04-09  9:17         ` Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 6/7] arm64: add cow " Tong Tiangen
2022-04-06  9:13 ` [RFC PATCH -next V2 7/7] arm64: add pagecache reading " Tong Tiangen
2022-04-06 11:27   ` Mark Rutland
2022-04-07 14:56     ` Tong Tiangen
2022-04-07 15:53       ` Robin Murphy
2022-04-08  2:43         ` Tong Tiangen
2022-04-08 11:11           ` Robin Murphy
2022-04-09  9:24             ` Tong Tiangen
2022-04-06 10:04 ` Mark Rutland [this message]
2022-04-07  4:21   ` [RFC PATCH -next V2 0/7]arm64: add machine check safe support Tong Tiangen

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=Yk1luUxEIP3Dxt5c@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tongtiangen@huawei.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).