- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS 1/2] tmpfs: fix undefined-behaviour in shmem_reconfigure()
by Yongqiang Liu 12 Jul '22

12 Jul '22

From: Luo Meng <luomeng12(a)huawei.com> mainline inclusion from mainline-v5.19-rc3 commit d14f5efadd846dbde561bd734318de6a9e6b26e6 category: bugfix bugzilla: 186471 https://gitee.com/openeuler/kernel/issues/I5DRKR CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- When shmem_reconfigure() calls __percpu_counter_compare(), the second parameter is unsigned long long. But in the definition of __percpu_counter_compare(), the second parameter is s64. So when __percpu_counter_compare() executes abs(count - rhs), UBSAN shows the following warning: Reviewed-by: Zhang Yi <yi.zhang(a)huawei.com> ================================================================================ UBSAN: Undefined behaviour in lib/percpu_counter.c:209:6 signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long long int' CPU: 1 PID: 9636 Comm: syz-executor.2 Tainted: G ---------r- - 4.18.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack home/install/linux-rh-3-10/lib/dump_stack.c:77 [inline] dump_stack+0x125/0x1ae home/install/linux-rh-3-10/lib/dump_stack.c:117 ubsan_epilogue+0xe/0x81 home/install/linux-rh-3-10/lib/ubsan.c:159 handle_overflow+0x19d/0x1ec home/install/linux-rh-3-10/lib/ubsan.c:190 __percpu_counter_compare+0x124/0x140 home/install/linux-rh-3-10/lib/percpu_counter.c:209 percpu_counter_compare home/install/linux-rh-3-10/./include/linux/percpu_counter.h:50 [inline] shmem_remount_fs+0x1ce/0x6b0 home/install/linux-rh-3-10/mm/shmem.c:3530 do_remount_sb+0x11b/0x530 home/install/linux-rh-3-10/fs/super.c:888 do_remount home/install/linux-rh-3-10/fs/namespace.c:2344 [inline] do_mount+0xf8d/0x26b0 home/install/linux-rh-3-10/fs/namespace.c:2844 ksys_mount+0xad/0x120 home/install/linux-rh-3-10/fs/namespace.c:3075 __do_sys_mount home/install/linux-rh-3-10/fs/namespace.c:3089 [inline] __se_sys_mount home/install/linux-rh-3-10/fs/namespace.c:3086 [inline] __x64_sys_mount+0xbf/0x160 home/install/linux-rh-3-10/fs/namespace.c:3086 do_syscall_64+0xca/0x5c0 home/install/linux-rh-3-10/arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf RIP: 0033:0x46b5e9 Code: 5d db fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b db fa ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f54d5f22c68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 000000000077bf60 RCX: 000000000046b5e9 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000000 RBP: 000000000077bf60 R08: 0000000020000140 R09: 0000000000000000 R10: 00000000026740a4 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd1fb1592f R14: 00007f54d5f239c0 R15: 000000000077bf6c ================================================================================ [akpm(a)linux-foundation.org: tweak error message text] Link: https://lkml.kernel.org/r/20220513025225.2678727-1-luomeng12@huawei.com Signed-off-by: Luo Meng <luomeng12(a)huawei.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Yu Kuai <yukuai3(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/shmem.c Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- mm/shmem.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/shmem.c b/mm/shmem.c index 8915a5b9ad0a..be91fb743426 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -3605,6 +3605,10 @@ static int shmem_remount_fs(struct super_block *sb, int *flags, char *data) spin_lock(&sbinfo->stat_lock); inodes = sbinfo->max_inodes - sbinfo->free_inodes; + if (config.max_blocks > S64_MAX) { + pr_err("Number of blocks too large"); + goto out; + } if (percpu_counter_compare(&sbinfo->used_blocks, config.max_blocks) > 0) goto out; if (config.max_inodes < inodes) -- 2.25.1

1 1

[PATCH openEuler-1.0-LTS] mm/sharepool: Check sp_is_enabled() before show spa_stat
by Yongqiang Liu 12 Jul '22

12 Jul '22

From: Wang Wensheng <wangwensheng4(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5GO4E CVE: NA -------------------------------- When we read file /proc/sharepool/spa_stat, we use sp_mapping_normal to iterator all the normal sp_area. The global pointer sp_mapping_normal is NULL if the sharepool feature is not enabled via kernel bootarg. This leads to a null-pointer-dereference issue. Signed-off-by: Wang Wensheng <wangwensheng4(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- mm/share_pool.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/share_pool.c b/mm/share_pool.c index 893e5352bf01..661036a7df64 100644 --- a/mm/share_pool.c +++ b/mm/share_pool.c @@ -4365,6 +4365,9 @@ void spg_overview_show(struct seq_file *seq) static int spa_stat_show(struct seq_file *seq, void *offset) { + if (!sp_is_enabled()) + return 0; + spg_overview_show(seq); spa_overview_show(seq); /* print the file header */ @@ -4425,6 +4428,9 @@ static int idr_proc_stat_cb(int id, void *p, void *data) static int proc_stat_show(struct seq_file *seq, void *offset) { + if (!sp_is_enabled()) + return 0; + spg_overview_show(seq); spa_overview_show(seq); /* print the file header */ @@ -4474,6 +4480,9 @@ static int idr_proc_overview_cb(int id, void *p, void *data) static int proc_overview_show(struct seq_file *seq, void *offset) { + if (!sp_is_enabled()) + return 0; + seq_printf(seq, "%-8s %-16s %-9s %-9s %-9s %-10s %-10s %-8s\n", "PID", "COMM", "SP_ALLOC", "SP_K2U", "SP_RES", "Non-SP_RES", "Non-SP_Shm", "VIRT"); -- 2.25.1

1 0

[PATCH v1 OLK-5.10 51/71] sw64: iommu: fix iommu interrupt handler
by Gu Zitao 12 Jul '22

12 Jul '22

From: Zheng Chongzhen <zhengchongzhen(a)wxiat.com> Sunway inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I56OSP -------------------------------- When porting ZX200 chipset driver on SW64 platform, we meet an IOMMU exception show as follows: iommu_interrupt, iommu_status = 0xc8014000dffe0000, devid 0xa00, dva 0xdffe0000, 1Unable to handle kernel paging request at virtual address 0000000000000040 CPU 0 swapper/0(0): Oops 0 pc = [<ffffffff81424b80>] ra = [<ffffffff81424b24>] ps = 0001 Not tainted pc is at iommu_interrupt+0x140/0x3e0 ra is at iommu_interrupt+0xe4/0x3e0 v0 = 0000000000000051 t0 = c8014000dffe0000 t1 = 0000000000000000 t2 = 0000000000000000 t3 = 0000000000000000 t4 = 0000000000000001 t5 = 0000000000000001 t6 = 0000000000000000 t7 = ffffffff82948000 s0 = fff00003ffff0400 s1 = 0000000000000001 s2 = 0000000000000a00 s3 = 0000000000000a00 s4 = 00000000dffe0000 s5 = fff0000100680e80 s6 = ffffffff8294ba70 a0 = 0000000000000001 a1 = 0000000000000001 a2 = ffffffff8294b790 a3 = ffffffff8294b7a8 a4 = 0000000000000000 a5 = ffffffff82c5fb7a t8 = 0000000000000001 t9 = fffffffffffcac48 t10 = 0000000000000000 t11= 0000000000000000 pv = ffffffff809f4f10 at = ffffffff82bff6c0 gp = ffffffff82c1f510 sp = (____ptrval____) The root cause is that the device which raises iommu exception is not in the device list, then reference a null sdev will cause a page fualt. To work around this problem, we apply this patch by just clearing IOMMUEXCPT_STATUS and then go on. BTW, why the device raise IOMMU exception is not a valid device ID, it's a puzzling problem. Signed-off-by: Zheng Chongzhen <zhengchongzhen(a)wxiat.com> Signed-off-by: Gu Zitao <guzitao(a)wxiat.com> --- drivers/iommu/sw64/sunway_iommu.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/sw64/sunway_iommu.c b/drivers/iommu/sw64/sunway_iommu.c index 5797adf8fbc5..b6c8f1272d28 100644 --- a/drivers/iommu/sw64/sunway_iommu.c +++ b/drivers/iommu/sw64/sunway_iommu.c @@ -648,10 +648,21 @@ irqreturn_t iommu_interrupt(int irq, void *dev) type = (iommu_status >> 59) & 0x7; devid = (iommu_status >> 37) & 0xffff; dva = iommu_status & 0xffffffff; - sdev = search_dev_data(devid); - sdomain = sdev->domain; pr_info("%s, iommu_status = %#lx, devid %#lx, dva %#lx, ", __func__, iommu_status, devid, dva); + + sdev = search_dev_data(devid); + if (sdev == NULL) { + pr_info("no such dev!!!\n"); + + iommu_status &= ~(1UL << 62); + write_piu_ior0(hose->node, hose->index, + IOMMUEXCPT_STATUS, iommu_status); + + return IRQ_HANDLED; + } + + sdomain = sdev->domain; switch (type) { case DTE_LEVEL1: pr_info("invalid level1 dte, addr:%#lx, val:%#lx\n", @@ -674,7 +685,6 @@ irqreturn_t iommu_interrupt(int irq, void *dev) fetch_pte(sdomain, dva, PTE_LEVEL2_VAL)); iommu_status &= ~(1UL << 62); - iommu_status = iommu_status | (1UL << 63); write_piu_ior0(hose->node, hose->index, IOMMUEXCPT_STATUS, iommu_status); break; -- 2.17.1

1 20

[PATCH v1 OLK-5.10 00/71] sw64 update
by Gu Zitao 12 Jul '22

12 Jul '22

Gu Zitao (2): sw64: add ARCH_TRACEHOOK and regset support sw64: rename CONFIG_HAVE_GENERIC_GUP to CONFIG_HAVE_FAST_GUP Hang Xiaoqian (2): sw64: change the value of physical_id in /proc/cpuinfo sw64: remove unaligned count He Chuyue (6): sw64: simplify __phys_addr and __virt_addr_valid sw64: check integrity for dtb passed by BIOS sw64: fix some structs related to pt_regs sw64: perf: add exclude_user and exclude_kernel support sw64: perf: fix the number of supported raw events sw64: perf: fix raw event count He Sheng (36): sw64: remove unused header files sw64: uapi: generate some uapi headers from generic ones sw64: uapi: include generic param.h sw64: kapi: remove unused header-y from Kbuild sw64: kapi: generate some kapi headers from generic ones sw64: move ucontext.h to uapi sw64: kapi: remove redudant SMP_CACHE_BYTES sw64: kapi: remove unimplemented IPLs sw64: kapi: include generic modules.h sw64: remove VGA_HOSE things sw64: clean up unused pci iounmap operation sw64: kapi: use generic vga.h sw64: remove unused IO_CONCAT sw64: do not include sw64io.h in io.h sw64: read host IO registers with rdio64 hmcall sw64: map logical address with __va() sw64: access IO space with readX/writeX sw64: add fpu state save/restore interfaces sw64: switch to generic fork like system calls sw64: remove r9_r15 argument of dik_show_regs and die_if_kernel sw64: remove switch_stack from entMM and entSys sw64: remove switch_stack from signal handling sw64: dump callee-saved registers from pt_regs sw64: get blocked thread's frame pointer from thread_struct sw64: remove switch_stack and allregs from entUna sw64: remove switch_stack from __sw64_vcpu_run sw64: remove other struct switch_stack things sw64: access pt_regs with regoffsets where appropriate sw64: move struct pt_regs to kapi ptrace.h sw64: avoid copying thread_struct twice sw64: simplify pgtable helpers sw64: remove discontiguous memory support sw64: merge user_fpsimd_state into thread_struct sw64: fix ptrace.h with types.h and NOT __ASSEMBLY__ sw64: rewrite elf core copy interfaces sw64: rename debugfs dir sw_64 to sw64 Lu Feifei (2): sw64: add memhotplug support for guest os sw64: add a misc device to chip_vt.dts for memory-hotplug Mao Minkai (2): sw64: fix __csum_and_copy when dest is not 8-byte aligned sw64: fix simd version of memset Min Fanlei (1): sw64: kvm: fix incorrect page_ref_count() call Wang Yuanheng (1): sw64: kvm: enable binding_vcpu debug dynamically Wu Liliu (4): sw64: perf: add fp based stack trace support sw64: reimplement show_stack() method sw64: reimplement get_wchan() sw64: reimplement save_stack_trace() Xiong Aifei (2): sw64: gpu: correct low-level mmio memset/memcpy direct calls sw64: gpu: replace '_memset_c_io' by 'memset_io' Xu Chenjiao (2): sw64: fix compile errors for NOT chip3 sw64: pcie: fix lack of PME and AER interrupt service routines Yang Qiang (2): sw64: dtb: check address validity with physical address sw64: pci: fix maximum bus number for pci scan Zhao Yihan (1): sw64: map address by OR operation in __va() Zheng Chongzhen (2): sw64: fix dma features for zx200 sw64: iommu: fix iommu interrupt handler Zhou Qihang (1): sw64: iommu: work around iova mapping on pci bars Zhou Xuemei (1): sw64: fix floating point register corruption Zhu Donghong (4): irqchip: add sw64 chip3 builtin LPC interrupt controller driver sw64: add builtin LPC interrupt controller to chip3.dts drivers/irqchip: add sw64 interrupt controller support sw64: deliver a hot reset to Root Complex with plugin JMicron 585 card arch/sw_64/Kconfig | 28 +- arch/sw_64/boot/dts/chip3.dts | 16 +- arch/sw_64/boot/dts/chip_vt.dts | 12 + arch/sw_64/chip/chip3/Makefile | 1 - arch/sw_64/chip/chip3/chip.c | 66 ++- arch/sw_64/chip/chip3/i2c-lib.c | 41 +- arch/sw_64/include/asm/Kbuild | 26 +- arch/sw_64/include/asm/agp.h | 19 - arch/sw_64/include/asm/asm-prototypes.h | 1 - arch/sw_64/include/asm/cache.h | 4 +- arch/sw_64/include/asm/compiler.h | 7 - arch/sw_64/include/asm/console.h | 11 - arch/sw_64/include/asm/div64.h | 7 - arch/sw_64/include/asm/elf.h | 40 +- arch/sw_64/include/asm/emergency-restart.h | 7 - arch/sw_64/include/asm/exec.h | 7 - arch/sw_64/include/asm/extable.h | 4 + arch/sw_64/include/asm/floppy.h | 116 ----- arch/sw_64/include/asm/hcall.h | 1 + arch/sw_64/include/asm/io.h | 33 -- arch/sw_64/include/asm/irq_impl.h | 3 + arch/sw_64/include/asm/irq_regs.h | 7 - arch/sw_64/include/asm/irqflags.h | 8 - arch/sw_64/include/asm/kmap_types.h | 15 - arch/sw_64/include/asm/kvm_asm.h | 3 + arch/sw_64/include/asm/kvm_host.h | 11 +- arch/sw_64/include/asm/local.h | 125 ----- arch/sw_64/include/asm/local64.h | 7 - arch/sw_64/include/asm/memory.h | 1 + arch/sw_64/include/asm/mmu_context.h | 8 +- arch/sw_64/include/asm/mmzone.h | 30 -- arch/sw_64/include/asm/module.h | 10 +- arch/sw_64/include/asm/page.h | 5 +- arch/sw_64/include/asm/param.h | 11 - arch/sw_64/include/asm/parport.h | 19 - arch/sw_64/include/asm/pci.h | 4 +- arch/sw_64/include/asm/pgalloc.h | 2 +- arch/sw_64/include/asm/pgtable.h | 98 ++-- arch/sw_64/include/asm/preempt.h | 7 - arch/sw_64/include/asm/processor.h | 49 +- arch/sw_64/include/asm/ptrace.h | 54 +- arch/sw_64/include/asm/seccomp.h | 15 - arch/sw_64/include/asm/sections.h | 8 - arch/sw_64/include/asm/segment.h | 7 - arch/sw_64/include/asm/serial.h | 16 - arch/sw_64/include/asm/shmparam.h | 7 - arch/sw_64/include/asm/special_insns.h | 20 - arch/sw_64/include/asm/stacktrace.h | 72 +++ arch/sw_64/include/asm/sw64_init.h | 1 + arch/sw_64/include/asm/sw64io.h | 89 ++-- arch/sw_64/include/asm/switch_to.h | 37 +- arch/sw_64/include/asm/thread_info.h | 5 + arch/sw_64/include/asm/trace_clock.h | 10 - arch/sw_64/include/asm/types.h | 7 - arch/sw_64/include/asm/unaligned.h | 12 - arch/sw_64/include/asm/vga.h | 85 ---- arch/sw_64/include/asm/wrperfmon.h | 8 +- arch/sw_64/include/uapi/asm/Kbuild | 1 + arch/sw_64/include/uapi/asm/console.h | 51 -- arch/sw_64/include/uapi/asm/ipcbuf.h | 7 - arch/sw_64/include/uapi/asm/kvm_para.h | 7 - arch/sw_64/include/uapi/asm/msgbuf.h | 28 -- arch/sw_64/include/uapi/asm/param.h | 9 +- arch/sw_64/include/uapi/asm/perf_regs.h | 7 + arch/sw_64/include/uapi/asm/poll.h | 7 - arch/sw_64/include/uapi/asm/posix_types.h | 18 - arch/sw_64/include/uapi/asm/ptrace.h | 76 +-- arch/sw_64/include/uapi/asm/sembuf.h | 23 - arch/sw_64/include/uapi/asm/shmbuf.h | 39 -- arch/sw_64/include/uapi/asm/statfs.h | 9 - arch/sw_64/include/uapi/asm/types.h | 28 -- arch/sw_64/include/{ => uapi}/asm/ucontext.h | 8 +- arch/sw_64/kernel/Makefile | 7 +- arch/sw_64/kernel/asm-offsets.c | 136 ++--- arch/sw_64/kernel/bindvcpu.c | 29 ++ arch/sw_64/kernel/core.c | 35 -- arch/sw_64/kernel/dup_print.c | 10 +- arch/sw_64/kernel/entry.S | 467 +++++------------- arch/sw_64/kernel/fpu.S | 102 ++++ arch/sw_64/kernel/kgdb.c | 14 +- arch/sw_64/kernel/pci.c | 55 ++- arch/sw_64/kernel/pci_impl.h | 2 + arch/sw_64/kernel/perf_event.c | 100 +++- arch/sw_64/kernel/process.c | 156 ++---- arch/sw_64/kernel/proto.h | 5 +- arch/sw_64/kernel/ptrace.c | 245 ++++----- arch/sw_64/kernel/setup.c | 19 +- arch/sw_64/kernel/signal.c | 51 +- arch/sw_64/kernel/stacktrace.c | 212 +++++++- arch/sw_64/kernel/syscalls/syscall.tbl | 6 +- arch/sw_64/kernel/traps.c | 182 ++----- arch/sw_64/kernel/unaligned.c | 56 --- arch/sw_64/kvm/Kconfig | 7 + arch/sw_64/kvm/entry.S | 97 ++-- arch/sw_64/kvm/handle_exit.c | 5 + arch/sw_64/kvm/kvm-sw64.c | 137 ++++- arch/sw_64/lib/csum_partial_copy.c | 15 +- arch/sw_64/lib/deep-memset.S | 5 +- arch/sw_64/lib/iomap.c | 40 +- arch/sw_64/mm/fault.c | 20 +- arch/sw_64/mm/init.c | 25 +- arch/sw_64/mm/physaddr.c | 30 +- arch/sw_64/platform/platform_xuelang.c | 18 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12 + drivers/gpu/drm/radeon/radeon_vce.c | 2 +- drivers/gpu/drm/radeon/vce_v1_0.c | 5 + drivers/iommu/sw64/sunway_iommu.c | 21 +- drivers/irqchip/Kconfig | 26 +- drivers/irqchip/Makefile | 3 +- drivers/irqchip/irq-intc-v1.c | 104 ---- .../irqchip/irq-sw64-intc-v2.c | 64 ++- drivers/irqchip/irq-sw64-lpc-intc.c | 137 +++++ drivers/mfd/lpc_sunway_chip3.c | 130 ----- drivers/misc/Kconfig | 8 + drivers/misc/Makefile | 1 + drivers/misc/sunway-ged.c | 253 ++++++++++ 116 files changed, 2009 insertions(+), 2686 deletions(-) delete mode 100644 arch/sw_64/include/asm/agp.h delete mode 100644 arch/sw_64/include/asm/compiler.h delete mode 100644 arch/sw_64/include/asm/console.h delete mode 100644 arch/sw_64/include/asm/div64.h delete mode 100644 arch/sw_64/include/asm/emergency-restart.h delete mode 100644 arch/sw_64/include/asm/exec.h delete mode 100644 arch/sw_64/include/asm/floppy.h delete mode 100644 arch/sw_64/include/asm/irq_regs.h delete mode 100644 arch/sw_64/include/asm/kmap_types.h delete mode 100644 arch/sw_64/include/asm/local.h delete mode 100644 arch/sw_64/include/asm/local64.h delete mode 100644 arch/sw_64/include/asm/param.h delete mode 100644 arch/sw_64/include/asm/parport.h delete mode 100644 arch/sw_64/include/asm/preempt.h delete mode 100644 arch/sw_64/include/asm/seccomp.h delete mode 100644 arch/sw_64/include/asm/sections.h delete mode 100644 arch/sw_64/include/asm/segment.h delete mode 100644 arch/sw_64/include/asm/serial.h delete mode 100644 arch/sw_64/include/asm/shmparam.h delete mode 100644 arch/sw_64/include/asm/special_insns.h create mode 100644 arch/sw_64/include/asm/stacktrace.h delete mode 100644 arch/sw_64/include/asm/trace_clock.h delete mode 100644 arch/sw_64/include/asm/types.h delete mode 100644 arch/sw_64/include/asm/unaligned.h delete mode 100644 arch/sw_64/include/asm/vga.h delete mode 100644 arch/sw_64/include/uapi/asm/console.h delete mode 100644 arch/sw_64/include/uapi/asm/ipcbuf.h delete mode 100644 arch/sw_64/include/uapi/asm/kvm_para.h delete mode 100644 arch/sw_64/include/uapi/asm/msgbuf.h delete mode 100644 arch/sw_64/include/uapi/asm/poll.h delete mode 100644 arch/sw_64/include/uapi/asm/posix_types.h delete mode 100644 arch/sw_64/include/uapi/asm/sembuf.h delete mode 100644 arch/sw_64/include/uapi/asm/shmbuf.h delete mode 100644 arch/sw_64/include/uapi/asm/statfs.h delete mode 100644 arch/sw_64/include/uapi/asm/types.h rename arch/sw_64/include/{ => uapi}/asm/ucontext.h (56%) create mode 100644 arch/sw_64/kernel/bindvcpu.c delete mode 100644 arch/sw_64/kernel/core.c create mode 100644 arch/sw_64/kernel/fpu.S delete mode 100644 arch/sw_64/kernel/unaligned.c delete mode 100644 drivers/irqchip/irq-intc-v1.c rename arch/sw_64/chip/chip3/irq_chip.c => drivers/irqchip/irq-sw64-intc-v2.c (59%) create mode 100644 drivers/irqchip/irq-sw64-lpc-intc.c create mode 100644 drivers/misc/sunway-ged.c -- 2.17.1

1 50

[PATCH openEuler-5.10-LTS 1/7] arm64: Do not defer reserve_crashkernel() for platforms with no DMA memory zones
by Zheng Zengkai 11 Jul '22

11 Jul '22

From: Vijay Balakrishna <vijayb(a)linux.microsoft.com> stable inclusion from stable-v5.10.110 commit a25864c5bc20966cdc5ba5eb65b74b9b1e9ec8d2 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 031495635b4668f94e964e037ca93d0d38bfde58 upstream. The following patches resulted in deferring crash kernel reservation to mem_init(), mainly aimed at platforms with DMA memory zones (no IOMMU), in particular Raspberry Pi 4. commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32") commit 8424ecdde7df ("arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges") commit 0a30c53573b0 ("arm64: mm: Move reserve_crashkernel() into mem_init()") commit 2687275a5843 ("arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is required") Above changes introduced boot slowdown due to linear map creation for all the memory banks with NO_BLOCK_MAPPINGS, see discussion[1]. The proposed changes restore crash kernel reservation to earlier behavior thus avoids slow boot, particularly for platforms with IOMMU (no DMA memory zones). Tested changes to confirm no ~150ms boot slowdown on our SoC with IOMMU and 8GB memory. Also tested with ZONE_DMA and/or ZONE_DMA32 configs to confirm no regression to deferring scheme of crash kernel memory reservation. In both cases successfully collected kernel crash dump. [1] https://lore.kernel.org/all/9436d033-579b-55fa-9b00-6f4b661c2dd7@linux.micr… Signed-off-by: Vijay Balakrishna <vijayb(a)linux.microsoft.com> Cc: stable(a)vger.kernel.org Reviewed-by: Pasha Tatashin <pasha.tatashin(a)soleen.com> Link: https://lore.kernel.org/r/1646242689-20744-1-git-send-email-vijayb@linux.mi… [will: Add #ifdef CONFIG_KEXEC_CORE guards to fix 'crashk_res' references in allnoconfig build] Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> Conflicts: arch/arm64/mm/mmu.c Reviewed-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- arch/arm64/mm/init.c | 36 ++++++++++++++++++++++++++++++++---- arch/arm64/mm/mmu.c | 26 ++++++++++++++++---------- 2 files changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index f5bd046f9e19..5023c7e1f754 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -63,8 +63,34 @@ EXPORT_SYMBOL(memstart_addr); * unless restricted on specific platforms (e.g. 30-bit on Raspberry Pi 4). * In such case, ZONE_DMA32 covers the rest of the 32-bit addressable memory, * otherwise it is empty. + * + * Memory reservation for crash kernel either done early or deferred + * depending on DMA memory zones configs (ZONE_DMA) -- + * + * In absence of ZONE_DMA configs arm64_dma_phys_limit initialized + * here instead of max_zone_phys(). This lets early reservation of + * crash kernel memory which has a dependency on arm64_dma_phys_limit. + * Reserving memory early for crash kernel allows linear creation of block + * mappings (greater than page-granularity) for all the memory bank rangs. + * In this scheme a comparatively quicker boot is observed. + * + * If ZONE_DMA configs are defined, crash kernel memory reservation + * is delayed until DMA zone memory range size initilazation performed in + * zone_sizes_init(). The defer is necessary to steer clear of DMA zone + * memory range to avoid overlap allocation. So crash kernel memory boundaries + * are not known when mapping all bank memory ranges, which otherwise means + * not possible to exclude crash kernel range from creating block mappings + * so page-granularity mappings are created for the entire memory range. + * Hence a slightly slower boot is observed. + * + * Note: Page-granularity mapppings are necessary for crash kernel memory + * range for shrinking its size via /sys/kernel/kexec_crash_size interface. */ -phys_addr_t arm64_dma_phys_limit __ro_after_init; +#if IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32) +phys_addr_t __ro_after_init arm64_dma_phys_limit; +#else +phys_addr_t __ro_after_init arm64_dma_phys_limit = PHYS_MASK + 1; +#endif #ifndef CONFIG_KEXEC_CORE static void __init reserve_crashkernel(void) @@ -173,8 +199,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) if (!arm64_dma_phys_limit) arm64_dma_phys_limit = dma32_phys_limit; #endif - if (!arm64_dma_phys_limit) - arm64_dma_phys_limit = PHYS_MASK + 1; max_zone_pfns[ZONE_NORMAL] = max; free_area_init(max_zone_pfns); @@ -498,6 +522,9 @@ void __init arm64_memblock_init(void) reserve_elfcorehdr(); + if (!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) + reserve_crashkernel(); + high_memory = __va(memblock_end_of_DRAM() - 1) + 1; } @@ -553,7 +580,8 @@ void __init bootmem_init(void) * request_standard_resources() depends on crashkernel's memory being * reserved, so do it here. */ - reserve_crashkernel(); + if (IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32)) + reserve_crashkernel(); reserve_quick_kexec(); diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 00e89be15ad2..e76765354040 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -562,16 +562,6 @@ static void __init map_mem(pgd_t *pgdp) PAGE_KERNEL, NO_CONT_MAPPINGS); memblock_clear_nomap(kernel_start, kernel_end - kernel_start); -#ifdef CONFIG_KEXEC_CORE - if (crashk_res.end) { - __map_memblock(pgdp, crashk_res.start, - crashk_res.end + 1, - PAGE_KERNEL, - NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); - memblock_clear_nomap(crashk_res.start, - resource_size(&crashk_res)); - } -#endif #ifdef CONFIG_KFENCE /* * Map the __kfence_pool at page granularity now. @@ -584,6 +574,22 @@ static void __init map_mem(pgd_t *pgdp) memblock_clear_nomap(__pa(__kfence_pool), KFENCE_POOL_SIZE); } #endif + + /* + * Use page-level mappings here so that we can shrink the region + * in page granularity and put back unused memory to buddy system + * through /sys/kernel/kexec_crash_size interface. + */ +#ifdef CONFIG_KEXEC_CORE + if (crashk_res.end) { + __map_memblock(pgdp, crashk_res.start, + crashk_res.end + 1, + PAGE_KERNEL, + NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); + memblock_clear_nomap(crashk_res.start, + resource_size(&crashk_res)); + } +#endif } void mark_rodata_ro(void) -- 2.20.1

1 6

[PATCH 01/34] ARM: 9196/1: spectre-bhb: enable for Cortex-A15
by Laibin Qiu 08 Jul '22

08 Jul '22

From: Ard Biesheuvel <ardb(a)kernel.org> stable inclusion from stable-4.19.245 commit 0569702c238290924fc1c7c6954258aa4a5fd649 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5FNPY CVE: NA -------------------------------- [ Upstream commit 0dc14aa94ccd8ba35eb17a0f9b123d1566efd39e ] The Spectre-BHB mitigations were inadvertently left disabled for Cortex-A15, due to the fact that cpu_v7_bugs_init() is not called in that case. So fix that. Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> --- arch/arm/mm/proc-v7-bugs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c index 87a93b76e148..8c7d00cb63ef 100644 --- a/arch/arm/mm/proc-v7-bugs.c +++ b/arch/arm/mm/proc-v7-bugs.c @@ -299,6 +299,7 @@ void cpu_v7_ca15_ibe(void) { if (check_spectre_auxcr(this_cpu_ptr(&spectre_warned), BIT(0))) cpu_v7_spectre_v2_init(); + cpu_v7_spectre_bhb_init(); } void cpu_v7_bugs_init(void) -- 2.25.1

1 33

[PATCH openEuler-1.0-LTS 1/4] block: rename bd_invalidated
by Laibin Qiu 08 Jul '22

08 Jul '22

From: Christoph Hellwig <hch(a)lst.de> mainline inclusion from mainline-v5.10-rc1 commit f4ad06f2bb8476548b08f89919ee65abc4e40212 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA ------------------------------------------------- Replace bd_invalidate with a new BDEV_NEED_PART_SCAN flag in a bd_flags variable to better describe the condition. Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: fs/block_dev.c include/linux/blk_types.h Signed-off-by: Luo Meng <luomeng12(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> --- block/genhd.c | 2 +- block/partition-generic.c | 6 +++--- drivers/block/nbd.c | 8 ++++---- fs/block_dev.c | 12 ++++++------ include/linux/fs.h | 4 +++- 5 files changed, 17 insertions(+), 15 deletions(-) diff --git a/block/genhd.c b/block/genhd.c index fc24384e2c85..afa3cf525f43 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -646,7 +646,7 @@ static void register_disk(struct device *parent, struct gendisk *disk) if (!bdev) goto exit; - bdev->bd_invalidated = 1; + set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); err = blkdev_get(bdev, FMODE_READ, NULL); if (err < 0) goto exit; diff --git a/block/partition-generic.c b/block/partition-generic.c index 2261566741f4..ae3761fed854 100644 --- a/block/partition-generic.c +++ b/block/partition-generic.c @@ -546,7 +546,7 @@ int rescan_partitions(struct gendisk *disk, struct block_device *bdev) if (disk->fops->revalidate_disk) disk->fops->revalidate_disk(disk); check_disk_size_change(disk, bdev, true); - bdev->bd_invalidated = 0; + clear_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); if (!get_capacity(disk) || !(state = check_partition(disk, bdev))) return 0; if (IS_ERR(state)) { @@ -662,7 +662,7 @@ int invalidate_partitions(struct gendisk *disk, struct block_device *bdev) { int res; - if (!bdev->bd_invalidated) + if (!test_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags)) return 0; res = drop_partitions(disk, bdev); @@ -671,7 +671,7 @@ int invalidate_partitions(struct gendisk *disk, struct block_device *bdev) set_capacity(disk, 0); check_disk_size_change(disk, bdev, false); - bdev->bd_invalidated = 0; + clear_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); /* tell userspace that the media / partition table may have changed */ kobject_uevent(&disk_to_dev(disk)->kobj, KOBJ_CHANGE); diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index c2e5ba599418..f1986d8bb47c 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -317,7 +317,7 @@ static void nbd_size_update(struct nbd_device *nbd, bool start) if (start) set_blocksize(bdev, config->blksize); } else - bdev->bd_invalidated = 1; + set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); bdput(bdev); } kobject_uevent(&nbd_to_dev(nbd)->kobj, KOBJ_CHANGE); @@ -1343,7 +1343,7 @@ static int nbd_start_device_ioctl(struct nbd_device *nbd, struct block_device *b return ret; if (max_part) - bdev->bd_invalidated = 1; + set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); mutex_unlock(&nbd->config_lock); ret = wait_event_interruptible(config->recv_wq, atomic_read(&config->recv_threads) == 0); @@ -1518,9 +1518,9 @@ static int nbd_open(struct block_device *bdev, fmode_t mode) refcount_set(&nbd->config_refs, 1); refcount_inc(&nbd->refs); mutex_unlock(&nbd->config_lock); - bdev->bd_invalidated = 1; + set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); } else if (nbd_disconnected(nbd->config)) { - bdev->bd_invalidated = 1; + set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); } out: mutex_unlock(&nbd_index_mutex); diff --git a/fs/block_dev.c b/fs/block_dev.c index 9868b21b8ef9..f521b7cf907f 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -922,7 +922,7 @@ struct block_device *bdget(dev_t dev) bdev->bd_inode = inode; bdev->bd_block_size = i_blocksize(inode); bdev->bd_part_count = 0; - bdev->bd_invalidated = 0; + bdev->bd_flags = 0; inode->i_mode = S_IFBLK; inode->i_rdev = dev; inode->i_bdev = bdev; @@ -1404,7 +1404,7 @@ static void flush_disk(struct block_device *bdev, bool kill_dirty) "resized disk %s\n", bdev->bd_disk ? bdev->bd_disk->disk_name : ""); } - bdev->bd_invalidated = 1; + set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); } /** @@ -1457,7 +1457,7 @@ int revalidate_disk(struct gendisk *disk) mutex_lock(&bdev->bd_mutex); check_disk_size_change(disk, bdev, ret == 0); - bdev->bd_invalidated = 0; + clear_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); mutex_unlock(&bdev->bd_mutex); bdput(bdev); return ret; @@ -1520,7 +1520,7 @@ static void bdev_disk_changed(struct block_device *bdev, bool invalidate) up_read(&disk->lookup_sem); } else { check_disk_size_change(bdev->bd_disk, bdev, !invalidate); - bdev->bd_invalidated = 0; + clear_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags); } } @@ -1605,7 +1605,7 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part) * The latter is necessary to prevent ghost * partitions on a removed medium. */ - if (bdev->bd_invalidated && + if (test_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags) && (!ret || ret == -ENOMEDIUM)) bdev_disk_changed(bdev, ret == -ENOMEDIUM); @@ -1642,7 +1642,7 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part) if (bdev->bd_disk->fops->open) ret = bdev->bd_disk->fops->open(bdev, mode); /* the same as first opener case, read comment there */ - if (bdev->bd_invalidated && + if (test_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags) && (!ret || ret == -ENOMEDIUM)) bdev_disk_changed(bdev, ret == -ENOMEDIUM); if (ret) diff --git a/include/linux/fs.h b/include/linux/fs.h index bcd2131ca06c..480936c2d938 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -459,6 +459,8 @@ struct address_space { */ struct request_queue; +#define BDEV_NEED_PART_SCAN 0 + struct block_device { dev_t bd_dev; /* not a kdev_t - it's a search key */ int bd_openers; @@ -479,7 +481,7 @@ struct block_device { struct hd_struct * bd_part; /* number of times partitions within this device have been opened. */ unsigned bd_part_count; - int bd_invalidated; + unsigned long bd_flags; struct gendisk * bd_disk; struct request_queue * bd_queue; struct backing_dev_info *bd_bdi; -- 2.25.1

1 3

[PATCH openEuler-1.0-LTS 1/3] scsi: hisi_sas: Change DMA setup lock timeout to 2.5s
by Laibin Qiu 07 Jul '22

07 Jul '22

From: Xingui Yang <yangxingui(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5BXH1 CVE: NA ------------------------------------------------------------------- DMA setup lock timeout protection is added when DMA setup frames are received, it's a function outside the protocol and used to prevent SATA disk I/Os from being delivered for a long time. The default value is 100ms , it's too strict and easily triggered timeout when the disk is overloaded or faulty. Based on the average I/O latency of 300 disks, we adjust the value to 2.5s. Signed-off-by: Xingui Yang <yangxingui(a)huawei.com> Reviewed-by: kang fenglong <kangfenglong(a)huawei.com> Acked-by: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Laibin Qiu <qiulaibin(a)huawei.com> --- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index baae04adc8e4..91f02357d5b4 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -35,6 +35,7 @@ #define SATA_INITI_D2H_STORE_ADDR_HI 0x64 #define CFG_MAX_TAG 0x68 #define SAS_DMAC_OUTSTAND 0x6c +#define TRANS_LOCK_ICT_TIME 0X70 #define HGC_SAS_TX_OPEN_FAIL_RETRY_CTRL 0x84 #define HGC_SAS_TXFAIL_RETRY_CTRL 0x88 #define HGC_GET_ITV_TIME 0x90 @@ -596,6 +597,8 @@ static void init_reg_v3_hw(struct hisi_hba *hisi_hba) (u32)((1ULL << hisi_hba->queue_count) - 1)); hisi_sas_write32(hisi_hba, SAS_AXI_USER3, 0); hisi_sas_write32(hisi_hba, CFG_MAX_TAG, 0xfff0400); + /* time / CLK_AHB = 2.5s / 2ns = 0x4A817C80 */ + hisi_sas_write32(hisi_hba, TRANS_LOCK_ICT_TIME, 0x4A817C80); hisi_sas_write32(hisi_hba, HGC_SAS_TXFAIL_RETRY_CTRL, 0x108); hisi_sas_write32(hisi_hba, CFG_AGING_TIME, 0x1); hisi_sas_write32(hisi_hba, INT_COAL_EN, 0x1); @@ -3061,6 +3064,7 @@ static const struct hisi_sas_debugfs_reg_lu debugfs_global_reg_lu[] = { HISI_SAS_DEBUGFS_REG(SATA_INITI_D2H_STORE_ADDR_LO), HISI_SAS_DEBUGFS_REG(SATA_INITI_D2H_STORE_ADDR_HI), HISI_SAS_DEBUGFS_REG(CFG_MAX_TAG), + HISI_SAS_DEBUGFS_REG(TRANS_LOCK_ICT_TIME), HISI_SAS_DEBUGFS_REG(HGC_SAS_TX_OPEN_FAIL_RETRY_CTRL), HISI_SAS_DEBUGFS_REG(HGC_SAS_TXFAIL_RETRY_CTRL), HISI_SAS_DEBUGFS_REG(HGC_GET_ITV_TIME), -- 2.25.1

1 2

[PATCH openEuler-5.10 01/40] mm,hwpoison: drain pcplists before bailing out for non-buddy zero-refcount page
by Zheng Zengkai 06 Jul '22

06 Jul '22

From: Oscar Salvador <osalvador(a)suse.de> mainline inclusion from mainline-v5.11-rc1 commit 17e395b60f5b3dea204fcae60c7b38e84a00d87a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5E2IG CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Patch series "HWpoison: further fixes and cleanups", v5. This patchset includes some more fixes and a cleanup. Patch#2 and patch#3 are both fixes for taking a HWpoison page off a buddy freelist, since having them there has proved to be bad (see [1] and pathch#2's commit log). Patch#3 does the same for hugetlb pages. [1] https://lkml.org/lkml/2020/9/22/565 This patch (of 4): A page with 0-refcount and !PageBuddy could perfectly be a pcppage. Currently, we bail out with an error if we encounter such a page, meaning that we do not handle pcppages neither from hard-offline nor from soft-offline path. Fix this by draining pcplists whenever we find this kind of page and retry the check again. It might be that pcplists have been spilled into the buddy allocator and so we can handle it. Link: https://lkml.kernel.org/r/20201013144447.6706-1-osalvador@suse.de Link: https://lkml.kernel.org/r/20201013144447.6706-2-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador(a)suse.de> Acked-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- mm/memory-failure.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 63bacfcca122..de36b4aa4b6f 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -947,13 +947,13 @@ static int page_action(struct page_state *ps, struct page *p, } /** - * get_hwpoison_page() - Get refcount for memory error handling: + * __get_hwpoison_page() - Get refcount for memory error handling: * @page: raw error page (hit by memory error) * * Return: return 0 if failed to grab the refcount, otherwise true (some * non-zero value.) */ -static int get_hwpoison_page(struct page *page) +static int __get_hwpoison_page(struct page *page) { struct page *head = compound_head(page); @@ -983,6 +983,26 @@ static int get_hwpoison_page(struct page *page) return 0; } +static int get_hwpoison_page(struct page *p) +{ + int ret; + bool drained = false; + +retry: + ret = __get_hwpoison_page(p); + if (!ret && !is_free_buddy_page(p) && !page_count(p) && !drained) { + /* + * The page might be in a pcplist, so try to drain those + * and see if we are lucky. + */ + drain_all_pages(page_zone(p)); + drained = true; + goto retry; + } + + return ret; +} + /* * Do all that is necessary to remove user space mappings. Unmap * the pages and send SIGBUS to the processes if the data was dirty. -- 2.20.1

1 38

[PATCH openEuler-5.10 01/30] Documentation: Add documentation for Processor MMIO Stale Data
by Zheng Zengkai 06 Jul '22

06 Jul '22

From: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> stable inclusion from stable-v5.10.123 commit f8a85334a57e7842320476ff27be3a5f151da364 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5D5RS CVE: CVE-2022-21123,CVE-2022-21125,CVE-2022-21166 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- commit 4419470191386456e0b8ed4eb06a70b0021798a6 upstream Add the admin guide for Processor MMIO stale data vulnerabilities. Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> Reviewed-by: Zhang Jianhua <chris.zjh(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Liao Chang <liaochang1(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++++++++++ 2 files changed, 247 insertions(+) create mode 100644 Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index ca4dbdd9016d..2adec1e6520a 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -15,3 +15,4 @@ are configurable at compile, boot or run time. tsx_async_abort multihit.rst special-register-buffer-data-sampling.rst + processor_mmio_stale_data.rst diff --git a/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst new file mode 100644 index 000000000000..9393c50b5afc --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst @@ -0,0 +1,246 @@ +========================================= +Processor MMIO Stale Data Vulnerabilities +========================================= + +Processor MMIO Stale Data Vulnerabilities are a class of memory-mapped I/O +(MMIO) vulnerabilities that can expose data. The sequences of operations for +exposing data range from simple to very complex. Because most of the +vulnerabilities require the attacker to have access to MMIO, many environments +are not affected. System environments using virtualization where MMIO access is +provided to untrusted guests may need mitigation. These vulnerabilities are +not transient execution attacks. However, these vulnerabilities may propagate +stale data into core fill buffers where the data can subsequently be inferred +by an unmitigated transient execution attack. Mitigation for these +vulnerabilities includes a combination of microcode update and software +changes, depending on the platform and usage model. Some of these mitigations +are similar to those used to mitigate Microarchitectural Data Sampling (MDS) or +those used to mitigate Special Register Buffer Data Sampling (SRBDS). + +Data Propagators +================ +Propagators are operations that result in stale data being copied or moved from +one microarchitectural buffer or register to another. Processor MMIO Stale Data +Vulnerabilities are operations that may result in stale data being directly +read into an architectural, software-visible state or sampled from a buffer or +register. + +Fill Buffer Stale Data Propagator (FBSDP) +----------------------------------------- +Stale data may propagate from fill buffers (FB) into the non-coherent portion +of the uncore on some non-coherent writes. Fill buffer propagation by itself +does not make stale data architecturally visible. Stale data must be propagated +to a location where it is subject to reading or sampling. + +Sideband Stale Data Propagator (SSDP) +------------------------------------- +The sideband stale data propagator (SSDP) is limited to the client (including +Intel Xeon server E3) uncore implementation. The sideband response buffer is +shared by all client cores. For non-coherent reads that go to sideband +destinations, the uncore logic returns 64 bytes of data to the core, including +both requested data and unrequested stale data, from a transaction buffer and +the sideband response buffer. As a result, stale data from the sideband +response and transaction buffers may now reside in a core fill buffer. + +Primary Stale Data Propagator (PSDP) +------------------------------------ +The primary stale data propagator (PSDP) is limited to the client (including +Intel Xeon server E3) uncore implementation. Similar to the sideband response +buffer, the primary response buffer is shared by all client cores. For some +processors, MMIO primary reads will return 64 bytes of data to the core fill +buffer including both requested data and unrequested stale data. This is +similar to the sideband stale data propagator. + +Vulnerabilities +=============== +Device Register Partial Write (DRPW) (CVE-2022-21166) +----------------------------------------------------- +Some endpoint MMIO registers incorrectly handle writes that are smaller than +the register size. Instead of aborting the write or only copying the correct +subset of bytes (for example, 2 bytes for a 2-byte write), more bytes than +specified by the write transaction may be written to the register. On +processors affected by FBSDP, this may expose stale data from the fill buffers +of the core that created the write transaction. + +Shared Buffers Data Sampling (SBDS) (CVE-2022-21125) +---------------------------------------------------- +After propagators may have moved data around the uncore and copied stale data +into client core fill buffers, processors affected by MFBDS can leak data from +the fill buffer. It is limited to the client (including Intel Xeon server E3) +uncore implementation. + +Shared Buffers Data Read (SBDR) (CVE-2022-21123) +------------------------------------------------ +It is similar to Shared Buffer Data Sampling (SBDS) except that the data is +directly read into the architectural software-visible state. It is limited to +the client (including Intel Xeon server E3) uncore implementation. + +Affected Processors +=================== +Not all the CPUs are affected by all the variants. For instance, most +processors for the server market (excluding Intel Xeon E3 processors) are +impacted by only Device Register Partial Write (DRPW). + +Below is the list of affected Intel processors [#f1]_: + + =================== ============ ========= + Common name Family_Model Steppings + =================== ============ ========= + HASWELL_X 06_3FH 2,4 + SKYLAKE_L 06_4EH 3 + BROADWELL_X 06_4FH All + SKYLAKE_X 06_55H 3,4,6,7,11 + BROADWELL_D 06_56H 3,4,5 + SKYLAKE 06_5EH 3 + ICELAKE_X 06_6AH 4,5,6 + ICELAKE_D 06_6CH 1 + ICELAKE_L 06_7EH 5 + ATOM_TREMONT_D 06_86H All + LAKEFIELD 06_8AH 1 + KABYLAKE_L 06_8EH 9 to 12 + ATOM_TREMONT 06_96H 1 + ATOM_TREMONT_L 06_9CH 0 + KABYLAKE 06_9EH 9 to 13 + COMETLAKE 06_A5H 2,3,5 + COMETLAKE_L 06_A6H 0,1 + ROCKETLAKE 06_A7H 1 + =================== ============ ========= + +If a CPU is in the affected processor list, but not affected by a variant, it +is indicated by new bits in MSR IA32_ARCH_CAPABILITIES. As described in a later +section, mitigation largely remains the same for all the variants, i.e. to +clear the CPU fill buffers via VERW instruction. + +New bits in MSRs +================ +Newer processors and microcode update on existing affected processors added new +bits to IA32_ARCH_CAPABILITIES MSR. These bits can be used to enumerate +specific variants of Processor MMIO Stale Data vulnerabilities and mitigation +capability. + +MSR IA32_ARCH_CAPABILITIES +-------------------------- +Bit 13 - SBDR_SSDP_NO - When set, processor is not affected by either the + Shared Buffers Data Read (SBDR) vulnerability or the sideband stale + data propagator (SSDP). +Bit 14 - FBSDP_NO - When set, processor is not affected by the Fill Buffer + Stale Data Propagator (FBSDP). +Bit 15 - PSDP_NO - When set, processor is not affected by Primary Stale Data + Propagator (PSDP). +Bit 17 - FB_CLEAR - When set, VERW instruction will overwrite CPU fill buffer + values as part of MD_CLEAR operations. Processors that do not + enumerate MDS_NO (meaning they are affected by MDS) but that do + enumerate support for both L1D_FLUSH and MD_CLEAR implicitly enumerate + FB_CLEAR as part of their MD_CLEAR support. +Bit 18 - FB_CLEAR_CTRL - Processor supports read and write to MSR + IA32_MCU_OPT_CTRL[FB_CLEAR_DIS]. On such processors, the FB_CLEAR_DIS + bit can be set to cause the VERW instruction to not perform the + FB_CLEAR action. Not all processors that support FB_CLEAR will support + FB_CLEAR_CTRL. + +MSR IA32_MCU_OPT_CTRL +--------------------- +Bit 3 - FB_CLEAR_DIS - When set, VERW instruction does not perform the FB_CLEAR +action. This may be useful to reduce the performance impact of FB_CLEAR in +cases where system software deems it warranted (for example, when performance +is more critical, or the untrusted software has no MMIO access). Note that +FB_CLEAR_DIS has no impact on enumeration (for example, it does not change +FB_CLEAR or MD_CLEAR enumeration) and it may not be supported on all processors +that enumerate FB_CLEAR. + +Mitigation +========== +Like MDS, all variants of Processor MMIO Stale Data vulnerabilities have the +same mitigation strategy to force the CPU to clear the affected buffers before +an attacker can extract the secrets. + +This is achieved by using the otherwise unused and obsolete VERW instruction in +combination with a microcode update. The microcode clears the affected CPU +buffers when the VERW instruction is executed. + +Kernel reuses the MDS function to invoke the buffer clearing: + + mds_clear_cpu_buffers() + +On MDS affected CPUs, the kernel already invokes CPU buffer clear on +kernel/userspace, hypervisor/guest and C-state (idle) transitions. No +additional mitigation is needed on such CPUs. + +For CPUs not affected by MDS or TAA, mitigation is needed only for the attacker +with MMIO capability. Therefore, VERW is not required for kernel/userspace. For +virtualization case, VERW is only needed at VMENTER for a guest with MMIO +capability. + +Mitigation points +----------------- +Return to user space +^^^^^^^^^^^^^^^^^^^^ +Same mitigation as MDS when affected by MDS/TAA, otherwise no mitigation +needed. + +C-State transition +^^^^^^^^^^^^^^^^^^ +Control register writes by CPU during C-state transition can propagate data +from fill buffer to uncore buffers. Execute VERW before C-state transition to +clear CPU fill buffers. + +Guest entry point +^^^^^^^^^^^^^^^^^ +Same mitigation as MDS when processor is also affected by MDS/TAA, otherwise +execute VERW at VMENTER only for MMIO capable guests. On CPUs not affected by +MDS/TAA, guest without MMIO access cannot extract secrets using Processor MMIO +Stale Data vulnerabilities, so there is no need to execute VERW for such guests. + +Mitigation control on the kernel command line +--------------------------------------------- +The kernel command line allows to control the Processor MMIO Stale Data +mitigations at boot time with the option "mmio_stale_data=". The valid +arguments for this option are: + + ========== ================================================================= + full If the CPU is vulnerable, enable mitigation; CPU buffer clearing + on exit to userspace and when entering a VM. Idle transitions are + protected as well. It does not automatically disable SMT. + full,nosmt Same as full, with SMT disabled on vulnerable CPUs. This is the + complete mitigation. + off Disables mitigation completely. + ========== ================================================================= + +If the CPU is affected and mmio_stale_data=off is not supplied on the kernel +command line, then the kernel selects the appropriate mitigation. + +Mitigation status information +----------------------------- +The Linux kernel provides a sysfs interface to enumerate the current +vulnerability status of the system: whether the system is vulnerable, and +which mitigations are active. The relevant sysfs file is: + + /sys/devices/system/cpu/vulnerabilities/mmio_stale_data + +The possible values in this file are: + + .. list-table:: + + * - 'Not affected' + - The processor is not vulnerable + * - 'Vulnerable' + - The processor is vulnerable, but no mitigation enabled + * - 'Vulnerable: Clear CPU buffers attempted, no microcode' + - The processor is vulnerable, but microcode is not updated. The + mitigation is enabled on a best effort basis. + * - 'Mitigation: Clear CPU buffers' + - The processor is vulnerable and the CPU buffer clearing mitigation is + enabled. + +If the processor is vulnerable then the following information is appended to +the above information: + + ======================== =========================================== + 'SMT vulnerable' SMT is enabled + 'SMT disabled' SMT is disabled + 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown + ======================== =========================================== + +References +---------- +.. [#f1] Affected Processors + https://www.intel.com/content/www/us/en/developer/topic-technology/software… -- 2.20.1

1 29