| Message ID | 20220406091311.3354723-1-tongtiangen@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: add machine check safe support | expand |
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
在 2022/4/6 18:04, Mark Rutland 写道: > 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? ok :) > > 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? First, explain why only pay attention to the errors that occur when reading memory and not when writing memory: 1. For Linux reading page, the Linux is consumer[*], the DDR controller is producer. if page with memory error, Linux consumes the error will receive an error signal than process the signal. 2. For Linux writing page, the Linux is producer, the DDR controller is consumer, the DDR controller will process the memory error. 3. From the perspective of Linux, here we only focus on his situation as a consumer. Focus on how Linux responds to errors when reading pages. [*]For definitions of producers and consumers, refer to the documentation: Reliability, Availability, and Serviceability (RAS) Architecture Extension Second, explain why writing to user memory don't matter. Don't matter means that we will not deal with it in this patchset, but follow the current strategy of the kernel(kernel panic). Take copy_from[to]_user/get[put]_user as an example: 1. In copy_to_user()/put_user(), it read the kernel page and write to user page, We cannot judge the importance of this kernel page that holds kernel data, if a memory error is encountered while reading, the normal operation of the system after recovery cannot be guaranteed，so the current processing strategy of the kernel is panic,we will not change this. 2. In copy_from_user()/get_user(), it read the user page and write to kernel page in user process context, this user data is only critical to this user process and does not affect the operation of the whole system. Therefore, if a memory error is encountered while reading, we can recover by killing this process and isolating the error user page without going to kernel panic, This patchset is aimed at this situation. > >> 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. Yes. The strategy is "try not to die" in some specific scene. In both cases(cow and pagecache reading), when the page with memory error is read in user process context, the result is not fatal, because the data of the error page is only critical to the user process. Killing the process and isolating the error page will not affect the normal operation of the system. I hope I can explain this clearly. Great thanks to mark and I hope James can help take a look at this idea. Thanks. Tong. > >> 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 > .
This patchset is based on[1]. 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. 3. cow(copy on write). 4. pagecache reading. 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