June 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs
by Liu Shixin 04 Jun '24

04 Jun '24

From: Yihang Li <liyihang9(a)huawei.com> mainline inclusion from mainline-v6.7-rc1 commit 6de426f9276c448e2db7238911c97fb157cb23be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RE7B CVE: CVE-2023-52808 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- If init debugfs failed during device registration due to memory allocation failure, debugfs_remove_recursive() is called, after which debugfs_dir is not set to NULL. debugfs_remove_recursive() will be called again during device removal. As a result, illegal pointer is accessed. [ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs! ... [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 1669.872669] pc : down_write+0x24/0x70 [ 1669.876315] lr : down_write+0x1c/0x70 [ 1669.879961] sp : ffff000036f53a30 [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8 [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000 [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270 [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8 [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310 [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10 [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000 [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870 [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228 [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0 [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10 [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00 [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000 [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001 [ 1669.962563] Call trace: [ 1669.965000] down_write+0x24/0x70 [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0 [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main] [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw] [ 1669.984175] pci_device_remove+0x48/0xd8 [ 1669.988082] device_release_driver_internal+0x1b4/0x250 [ 1669.993282] device_release_driver+0x28/0x38 [ 1669.997534] pci_stop_bus_device+0x84/0xb8 [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40 [ 1670.007244] remove_store+0xfc/0x140 [ 1670.010802] dev_attr_store+0x44/0x60 [ 1670.014448] sysfs_kf_write+0x58/0x80 [ 1670.018095] kernfs_fop_write+0xe8/0x1f0 [ 1670.022000] __vfs_write+0x60/0x190 [ 1670.025472] vfs_write+0xac/0x1c0 [ 1670.028771] ksys_write+0x6c/0xd8 [ 1670.032071] __arm64_sys_write+0x24/0x30 [ 1670.035977] el0_svc_common+0x78/0x130 [ 1670.039710] el0_svc_handler+0x38/0x78 [ 1670.043442] el0_svc+0x8/0xc To fix this, set debugfs_dir to NULL after debugfs_remove_recursive(). Signed-off-by: Yihang Li <liyihang9(a)huawei.com> Signed-off-by: Xingui Yang <yangxingui(a)huawei.com> Signed-off-by: Xiang Chen <chenxiang66(a)hisilicon.com> Link: https://lore.kernel.org/r/1694571327-78697-2-git-send-email-chenxiang66@his… Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: xiabing <xiabing12(a)h-partners.com> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index 4a2ed1a74ef9..3ae5c11aaf40 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -4716,6 +4716,12 @@ static void debugfs_bist_init_v3_hw(struct hisi_hba *hisi_hba) hisi_hba->debugfs_bist_linkrate = SAS_LINK_RATE_1_5_GBPS; } +static void debugfs_exit_v3_hw(struct hisi_hba *hisi_hba) +{ + debugfs_remove_recursive(hisi_hba->debugfs_dir); + hisi_hba->debugfs_dir = NULL; +} + static void debugfs_init_v3_hw(struct hisi_hba *hisi_hba) { struct device *dev = hisi_hba->dev; @@ -4739,18 +4745,13 @@ static void debugfs_init_v3_hw(struct hisi_hba *hisi_hba) for (i = 0; i < hisi_sas_debugfs_dump_count; i++) { if (debugfs_alloc_v3_hw(hisi_hba, i)) { - debugfs_remove_recursive(hisi_hba->debugfs_dir); + debugfs_exit_v3_hw(hisi_hba); dev_dbg(dev, "failed to init debugfs!\n"); break; } } } -static void debugfs_exit_v3_hw(struct hisi_hba *hisi_hba) -{ - debugfs_remove_recursive(hisi_hba->debugfs_dir); -} - static int hisi_sas_v3_probe(struct pci_dev *pdev, const struct pci_device_id *id) { -- 2.25.1

2 1

[PATCH OLK-5.10] bcache: avoid oversized read request in cache missing code path
by Xiang Yang 04 Jun '24

04 Jun '24

From: Coly Li <colyli(a)suse.de> mainline inclusion from mainline-v5.13-rc6 commit 41fe8d088e96472f63164e213de44ec77be69478 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4I7 CVE: CVE-2021-47275 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another kernel panic is from code block 6, is by the bvecs number oversized value s->insert_bio_sectors from code block 4, min(sectors, bio_sectors(bio) + reada) There are two possibility for oversized reresult, - bio_sectors(bio) is valid, but bio_sectors(bio) + reada is oversized. - sectors < bio_sectors(bio) + reada, but sectors is oversized. From a bug report the result of "DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS)" from code block 6 can be 344, 282, 946, 342 and many other values which larther than BIO_MAX_VECS (a.k.a 256). When calling bio_alloc_bioset() with such larger-than-256 value as the 2nd parameter, this value will eventually be sent to biovec_slab() as parameter 'nr_vecs' in following code path, bio_alloc_bioset() ==> bvec_alloc() ==> biovec_slab() Because parameter 'nr_vecs' is larger-than-256 value, the panic by BUG() in code block 3 is triggered inside biovec_slab(). From the above analysis, we know that the 4th parameter 'sector' sent into cached_dev_cache_miss() may cause overflow in code block 5 and 6, and finally cause kernel panic in code block 2 and 3. And if result of bio_sectors(bio) + reada exceeds valid bvecs number, it may also trigger kernel panic in code block 3 from code block 6. Now the almost-useless readahead size for cache missing request back to backing device is removed, this patch can fix the oversized issue with more simpler method. - add a local variable size_limit, set it by the minimum value from the max bkey size and max bio bvecs number. - set s->insert_bio_sectors by the minimum value from size_limit, sectors, and the sectors size of bio. - replace sectors by s->insert_bio_sectors to do bio_next_split. By the above method with size_limit, s->insert_bio_sectors will never result oversized replace_key size or bio bvecs number. And split bio 'miss' from bio_next_split() will always match the size of 'cache_bio', that is the current maximum bio size we can sent to backing device for fetching the cache missing data. Current problmatic code can be partially found since Linux v3.13-rc1, therefore all maintained stable kernels should try to apply this fix. Reported-by: Alexander Ullrich <ealex1979(a)gmail.com> Reported-by: Diego Ercolani <diego.ercolani(a)gmail.com> Reported-by: Jan Szubiak <jan.szubiak(a)linuxpolska.pl> Reported-by: Marco Rebhan <me(a)dblsaiko.net> Reported-by: Matthias Ferdinand <bcache(a)mfedv.net> Reported-by: Victor Westerhuis <victor(a)westerhu.is> Reported-by: Vojtech Pavlik <vojtech(a)suse.cz> Reported-and-tested-by: Rolf Fokkens <rolf(a)rolffokkens.nl> Reported-and-tested-by: Thorsten Knabe <linux(a)thorsten-knabe.de> Signed-off-by: Coly Li <colyli(a)suse.de> Cc: stable(a)vger.kernel.org Cc: Christoph Hellwig <hch(a)lst.de> Cc: Kent Overstreet <kent.overstreet(a)gmail.com> Cc: Nix <nix(a)esperi.org.uk> Cc: Takashi Iwai <tiwai(a)suse.com> Link: https://lore.kernel.org/r/20210607125052.21277-3-colyli@suse.de Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: drivers/md/bcache/request.c [Fix context conflict] Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- drivers/md/bcache/request.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index 5933ba353409..87d51389a72a 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -917,6 +917,7 @@ static int cached_dev_cache_miss(struct btree *b, struct search *s, unsigned int reada = 0; struct cached_dev *dc = container_of(s->d, struct cached_dev, disk); struct bio *miss, *cache_bio; + unsigned int size_limit; s->cache_missed = 1; @@ -935,7 +936,10 @@ static int cached_dev_cache_miss(struct btree *b, struct search *s, reada = min_t(sector_t, dc->readahead >> 9, get_capacity(bio->bi_disk) - bio_end_sector(bio)); - s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); + /* Limitation for valid replace key size and cache_bio bvecs number */ + size_limit = min_t(unsigned int, BIO_MAX_VECS * PAGE_SECTORS, + (1 << KEY_SIZE_BITS) - 1); + s->insert_bio_sectors = min3(size_limit, sectors, bio_sectors(bio)); s->iop.replace_key = KEY(s->iop.inode, bio->bi_iter.bi_sector + s->insert_bio_sectors, @@ -947,7 +951,8 @@ static int cached_dev_cache_miss(struct btree *b, struct search *s, s->iop.replace = true; - miss = bio_next_split(bio, sectors, GFP_NOIO, &s->d->bio_split); + miss = bio_next_split(bio, s->insert_bio_sectors, GFP_NOIO, + &s->d->bio_split); /* btree_search_recurse()'s btree iterator is no good anymore */ ret = miss == bio ? MAP_DONE : -EINTR; -- 2.34.1

2 1

[PATCH OLK-5.10] livepatch: Fix find wrong ftrace entry
by Zheng Yejian 04 Jun '24

04 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9UQ7I -------------------------------- There is case that 'kernel_kexec' has multiple fentrys, and when CONFIG_LIVEPATCH_ISOLATE_KPROBE enable, livepatch want to find the fentry at function start, however it actually find a wrong fentry due to binary search in ftrace_location_range() through the whole function range. # grep kernel_kexec /sys/kernel/tracing/available_filter_functions kernel_kexec <-- kernel_kexec+0x4/0xf8 kernel_kexec <-- kernel_kexec+0xdc/0xf8 kernel_kexec <-- kernel_kexec+0xdc/0xf8 To solve the issue, shrink the search range in first several instructions. Fixes: fe25ad14ec35 ("livepatch: Avoid patching conflicts with kprobes") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- arch/arm64/kernel/livepatch.c | 11 +++++++++ arch/x86/kernel/livepatch.c | 18 +++++++++++++++ kernel/livepatch/core.c | 42 +++++++++++++++++++++++++++++------ 3 files changed, 64 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/livepatch.c b/arch/arm64/kernel/livepatch.c index 363fb8e41c49..86832f274f12 100644 --- a/arch/arm64/kernel/livepatch.c +++ b/arch/arm64/kernel/livepatch.c @@ -330,3 +330,14 @@ void arch_klp_unpatch_func(struct klp_func *func) do_patch(pc, (unsigned long)next_func->new_func); } } + +#ifdef CONFIG_LIVEPATCH_ISOLATE_KPROBE +unsigned long arch_klp_fentry_range_size(void) +{ + /* + * If first instruction is not 'bti', expect fentry exists + * at second instruction otherwise third instruction. + */ + return 3 * AARCH64_INSN_SIZE; +} +#endif /* CONFIG_LIVEPATCH_ISOLATE_KPROBE */ diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c index 99b72629637d..fdc864ec4963 100644 --- a/arch/x86/kernel/livepatch.c +++ b/arch/x86/kernel/livepatch.c @@ -386,4 +386,22 @@ void arch_klp_unpatch_func(struct klp_func *func) /* replace the text with the new text */ klp_patch_text((void *)ip, (const void *)new, JMP_E9_INSN_SIZE); } + +#ifdef CONFIG_LIVEPATCH_ISOLATE_KPROBE +unsigned long arch_klp_fentry_range_size(void) +{ + /* + * If CONFIG_X86_KERNEL_IBT enabled, there would be an 'endbr64' + * at function start, then it should be consider into the range + * size. But since CONFIG_X86_KERNEL_IBT is not introduced in this + * version, add a check here avoid this patch being port to later + * version but this case not being handled. + */ +#ifdef CONFIG_X86_KERNEL_IBT + BUILD_BUG_ON(1); +#endif + /* Expect fentry exists at first instruction. */ + return MCOUNT_INSN_SIZE; +} +#endif /* CONFIG_LIVEPATCH_ISOLATE_KPROBE */ #endif diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c index 3f3fa1c3c80c..92120e165bb6 100644 --- a/kernel/livepatch/core.c +++ b/kernel/livepatch/core.c @@ -984,6 +984,33 @@ int __weak arch_klp_init_func(struct klp_object *obj, struct klp_func *func) { return 0; } + +#ifdef CONFIG_LIVEPATCH_ISOLATE_KPROBE +unsigned long __weak arch_klp_fentry_range_size(void) +{ + return 0; +} + +static unsigned long klp_ftrace_location(unsigned long func_addr, + unsigned long func_size) +{ + unsigned long loc; + unsigned long range_size = arch_klp_fentry_range_size(); + + /* + * When some arch not need to modify codes after fentry, they are no + * need to override the weak arch_klp_fentry_range_size() which return + * 0, so just return here. + */ + if (range_size == 0 || range_size > func_size) + return 0; + loc = ftrace_location_range(func_addr, func_addr + range_size); + if (WARN_ON(loc && (loc < func_addr || loc >= func_addr + range_size))) + loc = 0; + return loc; +} +#endif /* CONFIG_LIVEPATCH_ISOLATE_KPROBE */ + #endif static int klp_init_func(struct klp_object *obj, struct klp_func *func) @@ -1089,15 +1116,16 @@ static int klp_init_object_loaded(struct klp_patch *patch, } #ifdef CONFIG_LIVEPATCH_ISOLATE_KPROBE old_func = (unsigned long)func->old_func; - ftrace_loc = ftrace_location_range(old_func, old_func + func->old_size - 1); + ftrace_loc = klp_ftrace_location(old_func, func->old_size); if (ftrace_loc) { - if (WARN_ON(ftrace_loc < old_func || - ftrace_loc >= old_func + func->old_size - MCOUNT_INSN_SIZE)) { - pr_err("ftrace location for '%s' invalid", func->old_name); - return -EINVAL; + if (ftrace_loc >= old_func && + ftrace_loc < old_func + func->old_size - MCOUNT_INSN_SIZE) { + func->old_func = (void *)(ftrace_loc + MCOUNT_INSN_SIZE); + func->old_size -= ((unsigned long)func->old_func - old_func); + } else { + pr_warn("space not enough after ftrace location in '%s'\n", + func->old_name); } - func->old_func = (void *)(ftrace_loc + MCOUNT_INSN_SIZE); - func->old_size -= ((unsigned long)func->old_func - old_func); } #endif -- 2.25.1

2 1

[PATCH v4 OLK-5.10 0/2] Fix soft lockup in stress test
by Zhang Zekun 04 Jun '24

04 Jun '24

speed up the speed of freeing iova and add a cond_resched(). v4: Add fix tags. v3: Fix check format warning. v2: add a cover letter to generate a pr. Zhang Zekun (2): iommu/iova: free iovas on each cpu in flush queue iommu/iova: Try to schedule out when free iova too long drivers/iommu/iova.c | 41 +++++++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 16 deletions(-) -- 2.17.1

2 3

[PATCH OLK-5.10] riscv: process: Fix kernel gp leakage
by Guo Mengqi 04 Jun '24

04 Jun '24

From: Stefan O'Rear <sorear(a)fastmail.com> stable inclusion from stable-v5.10.216 commit 9abc3e6f1116adb7a2d4fbb8ce20c37916976bf5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QG6A CVE: CVE-2024-35871 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d14fa1fcf69db9d070e75f1c4425211fa619dfc8 ] childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec. childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec completes, but gp is not one of the registers it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers. Fixes: 7db91e57a0ac ("RISC-V: Task implementation") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan O'Rear <sorear(a)fastmail.com> Reviewed-by: Alexandre Ghiti <alexghiti(a)rivosinc.com> Link: https://lore.kernel.org/r/20240327061258.2370291-1-sorear@fastmail.com Signed-off-by: Palmer Dabbelt <palmer(a)rivosinc.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/riscv/kernel/process.c drivers/xen/events/events_base.c [Fix context conflict] Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- arch/riscv/kernel/process.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index 7868050ff426..efa86ea707d6 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -22,8 +22,6 @@ #include <asm/switch_to.h> #include <asm/thread_info.h> -register unsigned long gp_in_global __asm__("gp"); - #ifdef CONFIG_STACKPROTECTOR #include <linux/stackprotector.h> unsigned long __stack_chk_guard __read_mostly; @@ -117,7 +115,6 @@ int copy_thread(unsigned long clone_flags, unsigned long usp, unsigned long arg, if (unlikely(p->flags & (PF_KTHREAD | PF_IO_WORKER))) { /* Kernel thread */ memset(childregs, 0, sizeof(struct pt_regs)); - childregs->gp = gp_in_global; /* Supervisor/Machine, irqs on: */ childregs->status = SR_PP | SR_PIE; -- 2.17.1

2 1

[PATCH OLK-5.10] iommu/arm-smmu-v3: Reducing the CMD_SYNC times
by Zhang Zekun 04 Jun '24

04 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9G9TI ---------------------------------------- Benifiting from the hardware same address blocking mechanism. We only need to send the CMD_SYNC when creating pte entry other than lvl 3, this can reduce the amounts of CMD_SYNC times sent to avoiding the errata. Detecting the hardware ability by read the SMMU_USER_CONFIG1. Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 57 +++++++++++++++++++-- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 ++ drivers/iommu/io-pgtable-arm.c | 4 ++ 3 files changed, 59 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 423a54b7611d..7c818a17ca11 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -2309,6 +2309,14 @@ static void arm_smmu_tlb_inv_page_nosync(struct iommu_iotlb_gather *gather, static void arm_smmu_tlb_inv_walk(unsigned long iova, size_t size, size_t granule, void *cookie) { +#ifdef CONFIG_HISILICON_ERRATUM_162100602 + struct arm_smmu_domain *smmu_domain = cookie; + + if (!size && smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_BATCH) { + arm_smmu_tlb_inv_range_domain(iova, granule, granule, true, cookie); + return; + } +#endif arm_smmu_tlb_inv_range_domain(iova, size, granule, false, cookie); } @@ -2951,6 +2959,9 @@ static void arm_smmu_iotlb_sync_map(struct iommu_domain *domain, if (!(smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_MAP)) return; + if (smmu_domain->smmu->options & ARM_SMMU_OPT_SYNC_BATCH) + return; + granule_size = 1 << __ffs(smmu_domain->domain.pgsize_bitmap); /* Add a SYNC command to sync io-pgtale to avoid errors in pgtable prefetch*/ @@ -4932,6 +4943,46 @@ static void arm_smmu_get_httu(struct arm_smmu_device *smmu, u32 reg) fw_features); } +#ifdef CONFIG_HISILICON_ERRATUM_162100602 +static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) +{ + u32 reg, i; + + /* IIDR */ + reg = readl_relaxed(smmu->base + ARM_SMMU_IIDR); + if (!(FIELD_GET(IIDR_VARIANT, reg) == 0x3) || + !(FIELD_GET(IIDR_REVISON, reg) == 0x2)) + return; + + smmu->options |= ARM_SMMU_OPT_SYNC_MAP; + + reg = readl_relaxed(smmu->base + ARM_SMMU_USER_CFG1); + reg = reg & GENMASK(15, 0); + for (i = 0; i < 8; i++) { + unsigned long val; + + val = (reg >> 2 * i) & GENMASK(1, 0); + switch (PAGE_SIZE) { + case SZ_4K: + if (!val) + return; + break; + case SZ_16K: + if (!val || val == 0x1) + return; + break; + case SZ_64K: + if (!val || val == 0x1 || val == 0x3) + return; + break; + default: + return; + } + } + smmu->options |= ARM_SMMU_OPT_SYNC_BATCH; +} +#endif + static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) { u32 reg; @@ -5163,11 +5214,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_HISILICON_ERRATUM_162100602 - /* IIDR */ - reg = readl_relaxed(smmu->base + ARM_SMMU_IIDR); - if (FIELD_GET(IIDR_VARIANT, reg) == 0x3 && - FIELD_GET(IIDR_REVISON, reg) == 0x2) - smmu->options |= ARM_SMMU_OPT_SYNC_MAP; + hisi_smmu_check_errata(smmu); #endif if (arm_smmu_ops.pgsize_bitmap == -1UL) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 776d326de105..ece2904fd728 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -175,6 +175,8 @@ #define ARM_SMMU_USER_CFG0 0xe00 #define ARM_SMMU_USER_MPAM_EN (1UL << 30) +#define ARM_SMMU_USER_CFG1 0xe04 + #define ARM_SMMU_IDR6 0x190 #define IDR6_LOG2NUMP GENMASK(27, 24) #define IDR6_LOG2NUMQ GENMASK(19, 16) @@ -717,6 +719,7 @@ struct arm_smmu_device { #define ARM_SMMU_OPT_PAGE0_REGS_ONLY (1 << 1) #define ARM_SMMU_OPT_MSIPOLL (1 << 2) #define ARM_SMMU_OPT_SYNC_MAP (1 << 3) +#define ARM_SMMU_OPT_SYNC_BATCH (1 << 4) u32 options; union { diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index 3fc6ae00dc96..dc80f2661ff7 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -364,6 +364,10 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova, pte = arm_lpae_install_table(cptep, ptep, 0, data); if (pte) __arm_lpae_free_pages(cptep, tblsz, cfg); +#ifdef CONFIG_HISILICON_ERRATUM_162100602 + if (lvl <= 2) + io_pgtable_tlb_flush_walk(&data->iop, iova, 0, ARM_LPAE_GRANULE(data)); +#endif } else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) { __arm_lpae_sync_pte(ptep, cfg); } -- 2.17.1

2 1

[PATCH OLK-5.10] iommu/iova: move depot up to avoid cache conflict
by Zhang Zekun 04 Jun '24

04 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9TIC6 ------------------------------------------ The first four params in struct iova_rcache will share the same cache line. The depot related parameter which will be upated each time the depot has been changed, and it should not influence the field "cpu_rcache". Moving the delayed_work up to avoid cache false-sharing, because it has 192 Bytes, which should be enough for sperating a cache line. The optimization can be reflected by perf top: Before: 31.13% [kernel] [k] queue_iova 23.02% [kernel] [k] __iova_rcache_get 7.78% [kernel] [k] __arm_lpae_unmap 6.18% [kernel] [k] arm_lpae_map 3.91% [kernel] [k] sch_direct_xmit 3.19% [kernel] [k] __arm_lpae_map 1.50% [kernel] [k] __dev_queue_xmit After: 15.88% [kernel] [k] __arm_lpae_unmap 11.33% [kernel] [k] arm_lpae_map 7.98% [kernel] [k] sch_direct_xmit 6.71% [kernel] [k] __arm_lpae_map 5.35% [kernel] [k] queue_iova 3.09% [kernel] [k] __dev_queue_xmit 2.83% [kernel] [k] ip_finish_output2 Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- include/linux/iova.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iova.h b/include/linux/iova.h index ccc59e4b6c54..32996e73ce19 100644 --- a/include/linux/iova.h +++ b/include/linux/iova.h @@ -31,9 +31,9 @@ struct iova_rcache { spinlock_t lock; unsigned int depot_size; struct iova_magazine *depot; + struct delayed_work work; struct iova_cpu_rcache __percpu *cpu_rcaches; struct iova_domain *iovad; - struct delayed_work work; KABI_RESERVE(1) KABI_RESERVE(2) }; -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] gpiolib: cdev: fix uninitialised kfifo
by Luo Gengkun 04 Jun '24

04 Jun '24

From: Kent Gibson <warthog618(a)gmail.com> mainline inclusion from mainline-v6.9 commit ee0166b637a5e376118e9659e5b4148080f1d27e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U7YV CVE: CVE-2024-36898 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active. Fixes: 65cff7046406 ("gpiolib: cdev: support setting debounce") Signed-off-by: Kent Gibson <warthog618(a)gmail.com> Link: https://lore.kernel.org/r/20240510065342.36191-1-warthog618@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Conflicts: drivers/gpio/gpiolib-cdev.c [The original patch defines eflags instead of errflags, but eflags is already a parameter of the function, so rename to errflags.] Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/gpio/gpiolib-cdev.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index 381cfa26a4a1..0f98a07efcd6 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -816,6 +816,8 @@ static int edge_detector_update(struct line *line, unsigned int line_idx, u64 eflags, bool polarity_change) { + u64 errflags; + int ret; unsigned int debounce_period_us = gpio_v2_line_config_debounce_period(lc, line_idx); @@ -827,6 +829,18 @@ static int edge_detector_update(struct line *line, if (debounce_period_us && READ_ONCE(line->sw_debounced)) { line->eflags = eflags; WRITE_ONCE(line->desc->debounce_period_us, debounce_period_us); + /* + * ensure event fifo is initialised if edge detection + * is now enabled. + */ + errflags = eflags & GPIO_V2_LINE_EDGE_FLAGS; + if (errflags && !kfifo_initialized(&line->req->events)) { + ret = kfifo_alloc(&line->req->events, + line->req->event_buffer_size, + GFP_KERNEL); + if (ret) + return ret; + } return 0; } -- 2.34.1

2 1

[PATCH OLK-5.10 v5 00/11] Memory access profiler(SPE) driven NUMA balancing
by Ze Zuo 04 Jun '24

04 Jun '24

Hi, In Arm processors, there is a hardware PMU (Performance Monitoring Unit) facility called Statistical Profiling Extension (SPE) that can gather memory access metrics. In this patchset, SPE is exploited as an access information sampling approach to drive NUMA balancing. This sampling approach is introducedto replace the method based on address space scanning and hint faults with the access information provided by the hardware. With this, it is no longer necessary for NUMA balancing to scan over the address space periodically and rely on task-to-page association built by NUMA hint faults. Instead, the access samples obtained from hardware PMU are fed to NUMA balancing as equivalents to page fault. Except for the replaced sampling approach, the rest of the NUMA balancing policy is retained to do pages and tasks migrations according to the samples. Profiling based on SPE is an valid alternative sampling approach in NUMA balancing for the optimal page and task placement. This can be also extended to other architectures as long as there is a hardware PMU that supports memory access profiling. An abstract layer mem_sampling is introduced to reserve support for other kernel features and different types of hardware PMU. To help evaluate performance of this approach in system, syctl interfaces are added to enable/disable hardware mem sampling. NUMA balancing sampling approach can be also switched back to hint-faults- based approach dynamically. TODOs Currently, SPE for NUMA balance does not support PMD-level page migration, but it will be supported in later version. Changes since v4: -- some patch check warning fixs, no functional change. Changes since v3: -- some clean code, no functional change. Changes since v2: -- clean code and commit fixs, no functional change. Changes since v1: -- clean code, no functional change. Ze Zuo (11): drivers/arm/spe: In-kernel SPE driver for page access profiling mm: Add PMU based memory sampling abstract layer mm/mem_sampling.c: Add controlling interface for mem_sampling sched: Enable per-process mem_sampling from sched switch path mm/mem_sampling.c: Drive NUMA balancing via mem_sampling access data mm/mem_sampling.c: Add controlling interface for mem_sampling on numa balance tracing, numa balance: add trace events for numa data caused by mem_sampling driver/arm/spe: make mem_sampling and perf reuse arm spe driver tracing, mem-sampling-sample: Adding tracking events to hardware-sampled page access samples/bpf: Add program for memory access by spe config: Enable memory sampling based pmu for numa balance by default arch/arm64/configs/openeuler_defconfig | 3 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/arm/Kconfig | 2 + drivers/arm/spe/Kconfig | 11 + drivers/arm/spe/Makefile | 2 + drivers/arm/spe/spe-decoder/Makefile | 2 + drivers/arm/spe/spe-decoder/arm-spe-decoder.c | 213 +++++ drivers/arm/spe/spe-decoder/arm-spe-decoder.h | 74 ++ .../arm/spe/spe-decoder/arm-spe-pkt-decoder.c | 227 +++++ .../arm/spe/spe-decoder/arm-spe-pkt-decoder.h | 153 ++++ drivers/arm/spe/spe.c | 854 ++++++++++++++++++ drivers/arm/spe/spe.h | 130 +++ drivers/perf/Kconfig | 2 +- drivers/perf/arm_pmu_acpi.c | 30 +- drivers/perf/arm_spe_pmu.c | 371 ++------ include/linux/mem_sampling.h | 109 +++ include/linux/perf/arm_pmu.h | 8 + include/trace/events/kmem.h | 80 ++ kernel/sched/core.c | 2 + kernel/sched/fair.c | 12 + mm/Kconfig | 24 + mm/Makefile | 1 + mm/mem_sampling.c | 514 +++++++++++ samples/bpf/spe/Makefile | 26 + samples/bpf/spe/Makefile.arch | 47 + samples/bpf/spe/README.md | 0 samples/bpf/spe/spe-record.bpf.c | 40 + samples/bpf/spe/spe-record.h | 47 + samples/bpf/spe/spe-record.user.c | 116 +++ 30 files changed, 2791 insertions(+), 312 deletions(-) create mode 100644 drivers/arm/Kconfig create mode 100644 drivers/arm/spe/Kconfig create mode 100644 drivers/arm/spe/Makefile create mode 100644 drivers/arm/spe/spe-decoder/Makefile create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-decoder.c create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-decoder.h create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-pkt-decoder.c create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-pkt-decoder.h create mode 100644 drivers/arm/spe/spe.c create mode 100644 drivers/arm/spe/spe.h create mode 100644 include/linux/mem_sampling.h create mode 100644 mm/mem_sampling.c create mode 100644 samples/bpf/spe/Makefile create mode 100644 samples/bpf/spe/Makefile.arch create mode 100644 samples/bpf/spe/README.md create mode 100644 samples/bpf/spe/spe-record.bpf.c create mode 100644 samples/bpf/spe/spe-record.h create mode 100644 samples/bpf/spe/spe-record.user.c -- 2.33.0

2 12

[PATCH V3 OLK-5.10 0/2] Fix soft lockup in stress test
by Zhang Zekun 04 Jun '24

04 Jun '24

speed up the speed of freeing iova and add a cond_resched(). v3: Fix check format warning. v2: add a cover letter to generate a pr. Zhang Zekun (2): iommu/iova: free iovas on each cpu in flush queue iommu/iova: Try to schedule out when free iova too long drivers/iommu/iova.c | 41 +++++++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 16 deletions(-) -- 2.17.1

2 3

2024

2023

2022

2021

2020

2019

Kernel June 2024