In this patchset, we remove the unused macro EX_TYPE_COPY and centralize
the processing of memory-failure to do_machine_check() to avoid calling
memory_failure_queue() separately for different MC-Safe scenarios. In
addition, MCE_IN_KERNEL_COPYIN is renamed MCE_IN_KERNEL_COPY_MC to expand
its usage scope.
[1]https://lore.kernel.org/linux-mm/[email protected]/
since v3:
1. Rebased on linux-next tag next-20240111.
2. Delete duplicate commit references on patch 3.
since v2:
1. remove redundant fixup type EX_TYPE_COPY.
2. rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC.
3. update patch3's commit message and the processing logic of
EX_TYPE_DEFAULT_MCE_SAFE based on the discussion of [1].
Kefeng Wang (1):
x86/mce: set MCE_IN_KERNEL_COPY_MC for DEFAULT_MCE_SAFE exception
Tong Tiangen (2):
x86/mce: remove redundant fixup type EX_TYPE_COPY
x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC
arch/x86/include/asm/asm.h | 3 ---
arch/x86/include/asm/extable_fixup_types.h | 23 +++++++++++-----------
arch/x86/include/asm/mce.h | 8 ++++----
arch/x86/kernel/cpu/mce/core.c | 2 +-
arch/x86/kernel/cpu/mce/severity.c | 7 +++----
arch/x86/mm/extable.c | 9 ---------
mm/ksm.c | 1 -
mm/memory.c | 13 ++++--------
8 files changed, 23 insertions(+), 43 deletions(-)
--
2.25.1
From: Kefeng Wang <[email protected]>
If an MCE has happened in kernel space and the kernel can recover,
mce.kflags MCE_IN_KERNEL_RECOV will set in error_context().
With the setting of MCE_IN_KERNEL_RECOV, the MCE is handled in
do_machine_check(). But due to lack of MCE_IN_KERNEL_COPY_MC, although the
kernel won't panic, the corrupted page don't be isolated, new one maybe
consume it again, which is not what we expected.
In order to avoid above issue, some hwpoison recover process[1][2][3],
memory_failure_queue() is called to cope with such unhandled corrupted
pages, also there are some other already existed MC-safe copy scenarios,
eg, nvdimm, dm-writecache, dax, which don't isolate corrupted pages.
The best way to fix them is set MCE_IN_KERNEL_COPY_MC for MC-Safe Copy,
then let the core do_machine_check() to isolate corrupted page instead
of doing it one-by-one.
EX_TYPE_FAULT_MCE_SAFE is used for the FPU. Here, we do not touch the logic
of FPU. We only modify the logic of EX_TYPE_DEFAULT_MCE_SAFE which is used
in the scenarios described above.
[1] commit d302c2398ba2 ("mm, hwpoison: when copy-on-write hits poison, take page offline")
[2] commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults")
[3] commit 6b970599e807 ("mm: hwpoison: support recovery from ksm_might_need_to_copy()")
Reviewed-by: Naoya Horiguchi <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Tong Tiangen <[email protected]>
---
arch/x86/kernel/cpu/mce/severity.c | 4 ++--
mm/ksm.c | 1 -
mm/memory.c | 13 ++++---------
3 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/severity.c b/arch/x86/kernel/cpu/mce/severity.c
index df67a7a13034..b4b1d028cbb3 100644
--- a/arch/x86/kernel/cpu/mce/severity.c
+++ b/arch/x86/kernel/cpu/mce/severity.c
@@ -292,11 +292,11 @@ static noinstr int error_context(struct mce *m, struct pt_regs *regs)
case EX_TYPE_UACCESS:
if (!copy_user)
return IN_KERNEL;
+ fallthrough;
+ case EX_TYPE_DEFAULT_MCE_SAFE:
m->kflags |= MCE_IN_KERNEL_COPY_MC;
fallthrough;
-
case EX_TYPE_FAULT_MCE_SAFE:
- case EX_TYPE_DEFAULT_MCE_SAFE:
m->kflags |= MCE_IN_KERNEL_RECOV;
return IN_KERNEL_RECOV;
diff --git a/mm/ksm.c b/mm/ksm.c
index 8c001819cf10..ba9d324ea1c6 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -3084,7 +3084,6 @@ struct folio *ksm_might_need_to_copy(struct folio *folio,
if (copy_mc_user_highpage(folio_page(new_folio, 0), page,
addr, vma)) {
folio_put(new_folio);
- memory_failure_queue(folio_pfn(folio), 0);
return ERR_PTR(-EHWPOISON);
}
folio_set_dirty(new_folio);
diff --git a/mm/memory.c b/mm/memory.c
index c66af4520958..33d8903ab2af 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2843,10 +2843,8 @@ static inline int __wp_page_copy_user(struct page *dst, struct page *src,
unsigned long addr = vmf->address;
if (likely(src)) {
- if (copy_mc_user_highpage(dst, src, addr, vma)) {
- memory_failure_queue(page_to_pfn(src), 0);
+ if (copy_mc_user_highpage(dst, src, addr, vma))
return -EHWPOISON;
- }
return 0;
}
@@ -6176,10 +6174,8 @@ static int copy_user_gigantic_page(struct folio *dst, struct folio *src,
cond_resched();
if (copy_mc_user_highpage(dst_page, src_page,
- addr + i*PAGE_SIZE, vma)) {
- memory_failure_queue(page_to_pfn(src_page), 0);
+ addr + i*PAGE_SIZE, vma))
return -EHWPOISON;
- }
}
return 0;
}
@@ -6196,10 +6192,9 @@ static int copy_subpage(unsigned long addr, int idx, void *arg)
struct page *dst = nth_page(copy_arg->dst, idx);
struct page *src = nth_page(copy_arg->src, idx);
- if (copy_mc_user_highpage(dst, src, addr, copy_arg->vma)) {
- memory_failure_queue(page_to_pfn(src), 0);
+ if (copy_mc_user_highpage(dst, src, addr, copy_arg->vma))
return -EHWPOISON;
- }
+
return 0;
}
--
2.25.1
Hi Borislav and Tony，
On 2024/1/11 21:55, Tong Tiangen wrote:
> In this patchset, we remove the unused macro EX_TYPE_COPY and centralize
> the processing of memory-failure to do_machine_check() to avoid calling
> memory_failure_queue() separately for different MC-Safe scenarios. In
> addition, MCE_IN_KERNEL_COPYIN is renamed MCE_IN_KERNEL_COPY_MC to expand
> its usage scope.
The patchset is a followup[1], as Borislav suggested[2], we firstly
cleanup unused EX_TYPE_COPY, then rename MCE_IN_KERNEL_COPYIN to
reduce confusion, could you give us some comments about it,
many thanks.
>
> [1]https://lore.kernel.org/linux-mm/[email protected]/
>
[2]
https://lore.kernel.org/linux-edac/20230602160138.GDZHoSYsWoPAinMszk@fat_crate.local/
> since v3:
> 1. Rebased on linux-next tag next-20240111.
> 2. Delete duplicate commit references on patch 3.
>
> since v2:
> 1. remove redundant fixup type EX_TYPE_COPY.
> 2. rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC.
> 3. update patch3's commit message and the processing logic of
> EX_TYPE_DEFAULT_MCE_SAFE based on the discussion of [1].
>
> Kefeng Wang (1):
> x86/mce: set MCE_IN_KERNEL_COPY_MC for DEFAULT_MCE_SAFE exception
>
> Tong Tiangen (2):
> x86/mce: remove redundant fixup type EX_TYPE_COPY
> x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC
>
> arch/x86/include/asm/asm.h | 3 ---
> arch/x86/include/asm/extable_fixup_types.h | 23 +++++++++++-----------
> arch/x86/include/asm/mce.h | 8 ++++----
> arch/x86/kernel/cpu/mce/core.c | 2 +-
> arch/x86/kernel/cpu/mce/severity.c | 7 +++----
> arch/x86/mm/extable.c | 9 ---------
> mm/ksm.c | 1 -
> mm/memory.c | 13 ++++--------
> 8 files changed, 23 insertions(+), 43 deletions(-)
>
On Mon, Jan 15, 2024 at 09:25:57PM +0800, Kefeng Wang wrote:
> could you give us some comments about it, many thanks.
Since we have a (suspended¹) merge window currently:
From: Documentation/process/maintainer-tip.rst
Merge window
^^^^^^^^^^^^
Please do not expect large patch series to be handled during the merge
window or even during the week before. Such patches should be submitted in
mergeable state *at* *least* a week before the merge window opens.
Exceptions are made for bug fixes and *sometimes* for small standalone
drivers for new hardware or minimally invasive patches for hardware
enablement.
During the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.
The release candidate -rc1 is the starting point for new patches to be
applied which are targeted for the next merge window.
¹ https://lore.kernel.org/r/CAHk-=wjMWpmXtKeiN__vnNO4TcttZR-8dVvd_oBq%[email protected]
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2024/1/15 21:33, Borislav Petkov wrote:
> On Mon, Jan 15, 2024 at 09:25:57PM +0800, Kefeng Wang wrote:
>> could you give us some comments about it, many thanks.
>
> Since we have a (suspended¹) merge window currently:
>
> From: Documentation/process/maintainer-tip.rst
>
> Merge window
> ^^^^^^^^^^^^
>
> Please do not expect large patch series to be handled during the merge
> window or even during the week before. Such patches should be submitted in
> mergeable state *at* *least* a week before the merge window opens.
> Exceptions are made for bug fixes and *sometimes* for small standalone
> drivers for new hardware or minimally invasive patches for hardware
> enablement.
>
> During the merge window, the maintainers instead focus on following the
> upstream changes, fixing merge window fallout, collecting bug fixes, and
> allowing themselves a breath. Please respect that.
>
> The release candidate -rc1 is the starting point for new patches to be
> applied which are targeted for the next merge window.
Oh, sure, we could resend after -rc1, thanks.
>
> ¹ https://lore.kernel.org/r/CAHk-=wjMWpmXtKeiN__vnNO4TcttZR-8dVvd_oBq%[email protected]
>
Hope everything is OK!
On Tue, Jan 16, 2024 at 09:14:56AM +0800, Kefeng Wang wrote:
> Oh, sure, we could resend after -rc1, thanks.
No, no need to resend after -rc1.
What you should do, instead, is take the time to read the text I pasted
more carefully and get acquainted with the development process:
https://kernel.org/doc/html/latest/process/development-process.html
and especially this:
https://kernel.org/doc/html/latest/process/submitting-patches.html#don-t-get-discouraged-or-impatient
In those pages is a wealth of useful information.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette