- 21 6月, 2023 18 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1196 PR sync from: Yang Yingliang <yangyingliang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ORBGDUHLI4PUVZY5HOH6SBYHKAHHCELI/ Link:https://gitee.com/openeuler/kernel/pulls/1213 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Tong Tiangen <tongtiangen@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HN73D6P4WBWXBAACVFHNFTWYJE3MK3V3/ Link:https://gitee.com/openeuler/kernel/pulls/1208 Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Yang Yingliang 提交于
hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I7F4XV -------------------------------- The tmp variable is used to copy_to_user(), it has better performance if the address accesseed by ldp instruction is 16 bytes aligned on arm64. The performance of nginx test is improved after this patch: http "Connection: close" 1.11% http "Connection: keep-alive" 2.11% https "Connection: close" 1.56% https "Connection: keep-alive" 0.18% Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> (cherry picked from commit 2b34be30)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Jialin Zhang <zhangjialin11@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JUPWG3W5DGJELIBPTSAG3AGKH2PPZ3N3/ Link:https://gitee.com/openeuler/kernel/pulls/1204 Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zheng Zengkai <zhengzengkai@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RDUNFZSP4CQYRI7TDPSAJZDZEHHQL3H3/ 2f06f702 ("locking/rwsem: Prevent potential lock starvation"): This patch may have some impact on reader performance as it reduces reader optimistic spinning especially if the lock critical sections are short the number of contending readers are small. This patch will lead to 30%+ performance degradation to fio write_iops_blocksize 4KB testcase, and we stress the system with mysql tpcc for 12 hours, no hungtask occur, So revert this patchset temporarily. Link:https://gitee.com/openeuler/kernel/pulls/1203 Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1190 PR sync from: Liu Shixin <liushixin2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/XR7NP7IV7MBMBYASGLC3ZEO7URQ2IHV7/ Link:https://gitee.com/openeuler/kernel/pulls/1200 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Tong Tiangen 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7F28R CVE: NA -------------------------------- On Hisilicon LINXICORE9100 cores, sharing tlb entries on two cores when TTBRx.CNP=1 differs from the standard ARM core. This causes issues when tlb entries sharing between CPU cores. Avoid these issues by disabling CNP feature for Hisilicon LINXICORE9100 cores. Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1178 PR sync from: Chen Zhongjin <chenzhongjin@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7SX6VMPGMA422BLUDHM6SXV5PQWXROF3/ Link:https://gitee.com/openeuler/kernel/pulls/1193 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1159 When the current HiSilicon USB xhci controller formats the faulty U disk, it will trigger a controller exception error. This will cause errors in the control logic of the xhci controller and driver software. In the end, all USB devices on the xhci controller cannot be used. By introducing a noop command operation, restore the logic of the xhci controller and driver software, and restore all USB devices on the xhci controller to normal. issue:https://gitee.com/openeuler/kernel/issues/I7DZ8S Link:https://gitee.com/openeuler/kernel/pulls/1195 Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Jian <liujian56@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/5JKP2KL26FXHAGD4SJXBYZ2YJPD4DYLT/ v1->v2: add bugzilla tag. Fix below warning messages: libbpf: Error in bpf_create_map_xattr(redissock_map):ERROR: strerror_r(-524)=22(-524). Retrying without BTF. rmmod: ERROR: Module localip is not currently loaded Hengqi Chen (1): libbpf: Support uniform BTF-defined key/value specification across all BPF maps Liu Jian (1): tools: ignore one warning message -- 2.34.1 Link:https://gitee.com/openeuler/kernel/pulls/1183 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Jialin Zhang 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I796HQ -------------------------------- The version information OPENEULER_MINOR is not right in SP2, update it's value to 2. Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F5L7 CVE: NA -------------------------------- Revert this patch due to fio performance degradation. This reverts commit 70e33bec. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F5L7 CVE: NA -------------------------------- Revert this patch due to fio performance degradation. This reverts commit fa59b0b0. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F5L7 CVE: NA -------------------------------- 2f06f702 ("locking/rwsem: Prevent potential lock starvation"): This patch may have some impact on reader performance as it reduces reader optimistic spinning especially if the lock critical sections are short the number of contending readers are small. This patch will lead to 30%+ performance degradation to fio write_iops_blocksize 4KB testcase, and we stress the system with mysql tpcc for 12 hours, no hungtask occur, So revert this patchset temporarily. This reverts commit f66f7f34. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NYW4 CVE: NA -------------------------------- Fix implicit declaration of function 'memcg_print_bad_task'. Fixes: 9cd6f55e ("mm: oom: move memcg_print_bad_task() out of mem_cgroup_scan_tasks()") Signed-off-by: NLiu Shixin <liushixin2@huawei.com> (cherry picked from commit c95fdec6)
-
由 Longfang Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DZ8S CVE: NA ---------------------------------------------------------------------- When the current HiSilicon USB xhci controller formats the faulty U disk, it will trigger a controller exception error. This will cause errors in the control logic of the xhci controller and driver software. In the end, all USB devices on the xhci controller cannot be used. By introducing a noop command operation, restore the logic of the xhci controller and driver software, and restore all USB devices on the xhci controller to normal. Signed-off-by: NLongfang Liu <liulongfang@huawei.com> (cherry picked from commit 1a869403)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Junhao He <hejunhao3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SFPID77Q7WRTZVPTFE5WSEDPJADFTQAY/ 1) Fix NULL pointer for hisi_ptt 2) Keep to advertise PERF_PMU_CAP_EXCLUSIVE. Such ptt pmus can only have one event scheduled at a time. Junhao He (2): hwtracing: hisi_ptt: Add dummy callback pmu::read() hwtracing: hisi_ptt: Keep to advertise PERF_PMU_CAP_EXCLUSIVE -- 2.33.0 Link:https://gitee.com/openeuler/kernel/pulls/1186 Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.4-rc1 commit 63264422 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7EK74 CVE: CVE-2023-3141 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=632644227850 -------------------------------- In r592_probe, dev->detect_timer was bound with r592_detect_timer. In r592_irq function, the timer function will be invoked by mod_timer. If we remove the module which will call hantro_release to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in r592_remove. CPU0 CPU1 |r592_detect_timer r592_remove | memstick_free_host| put_device; | kfree(host); | | | queue_work | &host->media_checker //use Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Link: https://lore.kernel.org/r/20230307164338.1246287-1-zyytlz.wz@163.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> (cherry picked from commit 24fbf41b)
-
- 20 6月, 2023 12 次提交
-
-
由 Junhao He 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F2F2 CVE: NA -------------------------------- Keep to advertise PERF_PMU_CAP_EXCLUSIVE. Such pmus can only have one event scheduled at a time, and the perf tool will report device busy. Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 Junhao He 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F2F2 CVE: NA -------------------------------- When the perf is tracing hisi_ptt pmu and then stopped immediately with "ctrl + c". the perf will call pmu::read() to updata trace data, but driver does not implement the callback pmu::read(). Will cause the following panic. root@localhost:/# perf record -m,16M -e hisi_ptt0_2/xxx/ -C 0 ^C [ perf record: Woken up 0 times to write data ] [ 3693.734230] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 3693.747212] Mem abort info: [ 3693.749991] ESR = 0x0000000086000006 [ 3693.753725] EC = 0x21: IABT (current EL), IL = 32 bits [ 3693.759022] SET = 0, FnV = 0 [ 3693.762062] EA = 0, S1PTW = 0 [ 3693.765188] FSC = 0x06: level 2 translation fault [ 3693.770051] user pgtable: 4k pages, 48-bit VAs, pgdp=000008302912e000 [ 3693.776477] [0000000000000000] pgd=0800083019fc2003, p4d=0800083019fc2003, pud=0800083019fca003, pmd=0000000000000000 [ 3693.787072] Internal error: Oops: 0000000086000006 [#1] PREEMPT SMP [ 3693.822414] pstate: 614008c9 (nZCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=-c) [ 3693.829361] pc : 0x0 [ 3693.831534] lr : __perf_event_read+0x110/0x208 [ 3693.835966] sp : ffff800008003eb0 [ 3693.839266] x29: ffff800008003eb0 x28: ffffa4f0d14f1100 x27: 0000000000000001 [ 3693.846388] x26: ffffa4f0d14f1100 x25: 0000000000000000 x24: 0000000000000000 [ 3693.853509] x23: ffff082197adf4f8 x22: 0000000000000000 x21: ffff80001f8ebc28 [ 3693.860630] x20: ffff08478be506c8 x19: ffff083028f22220 x18: 0000000000000000 [ 3693.867751] x17: ffff6356bb355000 x16: ffff800008000000 x15: 0000000000000000 [ 3693.874871] x14: 0000000000000002 x13: 0000000000000000 x12: 0000000000000040 [ 3693.881992] x11: ffff08300a915b40 x10: ffff08300a915b42 x9 : ffffa4f0ce6ee5a0 [ 3693.889113] x8 : ffff083000401268 x7 : 0000000000000000 x6 : 000000108dce8ee0 [ 3693.896234] x5 : 01ffffffffffffff x4 : 0000000000000000 x3 : 000000000112024a [ 3693.903355] x2 : 000000003cadb114 x1 : 0000000000000000 x0 : ffff083028f22220 [ 3693.910476] Call trace: [ 3693.912908] 0x0 [ 3693.914733] __flush_smp_call_function_queue+0x154/0x258 [ 3693.920032] generic_smp_call_function_single_interrupt+0x1c/0x30 [ 3693.926111] ipi_handler+0x90/0x2d0 [ 3693.929588] handle_percpu_devid_irq+0x90/0x250 [ 3693.934105] generic_handle_domain_irq+0x34/0x58 [ 3693.938708] gic_handle_irq+0x12c/0x270 [ 3693.942530] call_on_irq_stack+0x24/0x30 [ 3693.946439] do_interrupt_handler+0x88/0x98 [ 3693.950608] el1_interrupt+0x48/0xe8 [ 3693.954171] el1h_64_irq_handler+0x18/0x28 [ 3693.958253] el1h_64_irq+0x78/0x80 [ 3693.961641] default_idle_call+0x5c/0x180 [ 3693.965636] do_idle+0x25c/0x2d0 [ 3693.968851] cpu_startup_entry+0x2c/0x40 [ 3693.972760] rest_init+0xec/0xf8 [ 3693.975974] arch_call_rest_init+0x18/0x20 [ 3693.980057] start_kernel+0x41c/0x7f0 [ 3693.983705] __primary_switched+0xbc/0xd0 [ 3693.987702] Code: ???????? ???????? ???????? ???????? (????????) [ 3693.993781] ---[ end trace 0000000000000000 ]--- [ 3694.182495] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 3694.189354] SMP: stopping secondary CPUs [ 3694.193276] Kernel Offset: 0x24f0c6470000 from 0xffff800008000000 [ 3694.199354] PHYS_OFFSET: 0x0 [ 3694.202220] CPU features: 0x000000,00d005be,12affea7 [ 3694.207170] Memory Limit: none [ 3694.389463] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @stinft https://gitee.com/openeuler/kernel/issues/I7DCX0 Link:https://gitee.com/openeuler/kernel/pulls/1182 Reviewed-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Hengqi Chen 提交于
mainline inclusion from mainline-v5.16-rc1 commit f7310523 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DNAP CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f731052325efc3726577feb743c7495f880ae07d -------------------------------- A bunch of BPF maps do not support specifying BTF types for key and value. This is non-uniform and inconvenient[0]. Currently, libbpf uses a retry logic which removes BTF type IDs when BPF map creation failed. Instead of retrying, this commit recognizes those specialized maps and removes BTF type IDs when creating BPF map. [0] Closes: https://github.com/libbpf/libbpf/issues/355Signed-off-by: NHengqi Chen <hengqi.chen@gmail.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210930161456.3444544-2-hengqi.chen@gmail.com (cherry picked from commit f7310523) Signed-off-by: NLiu Jian <liujian56@huawei.com> Conflicts: tools/lib/bpf/libbpf.c
-
由 Liu Jian 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DNAP CVE: NA -------------------------------- Ignore one warning messages: rmmod: ERROR: Module localip is not currently loaded Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
由 Chengchang Tang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DCX0 --------------------------------------------------------------------------- Currently, the affinity between QP cache and CQ cache is not considered when assigning QPN, it will affect the message rate of HW. Allocate QPN from QP cache with better CQ affinity to get better performance. Fixes: c746005b ("RDMA/hns: Create QP with selected QPN for bank load balance") Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1150 EDAC/i10nm: Add Intel Emerald Rapids server support The Emerald Rapids CPU model uses similar memory controller registers as Sapphire Rapids server. Add Emerald Rapids CPU model number ID for EDAC support. bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7DZRN [Testing] dmesg - check i10nm_edac load Link:https://gitee.com/openeuler/kernel/pulls/1151 Reviewed-by: Jason Zeng <jason.zeng@intel.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1157 Add LoongArch maintainers to openEuler/MAINTAINERS. Reference: https://gitee.com/openeuler/kernel-docs/blob/master/Kernel%20SIG/Meeting%20Record/2023/2023-06-16.md Link:https://gitee.com/openeuler/kernel/pulls/1175 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1098 PR sync from: Li Nan <linan122@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/4EEIPQOJKUZAK6RIRH5RREOILH6ZD3EC/ Link:https://gitee.com/openeuler/kernel/pulls/1165 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 lixuefeng 提交于
LoongArch inclusion category: doc bugzilla: https://gitee.com/openeuler/kernel/issues/I7EKLJ -------------------------------- Add LoongArch maintainers to openEuler/MAINTAINERS. Signed-off-by: Nlixuefeng <lixuefeng@loongson.cn> (cherry picked from commit 34b773ec)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1162 PR sync from: Zhang Changzhong <zhangchangzhong@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RIOXNQNOVQ5DSEVFMIG6YBDCEKDWMBOS/ Link:https://gitee.com/openeuler/kernel/pulls/1169 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/582 #I6NYW4 Fix a type cast bug in mm/oom Link:https://gitee.com/openeuler/kernel/pulls/1156 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 19 6月, 2023 2 次提交
-
-
由 Samuel Thibault 提交于
mainline inclusion from mainline-v6.2-rc7 commit 2b09d5d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7C2TM CVE: CVE-2023-3161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b09d5d364986f724f17001ccfe4126b9b43a0be -------------------------------- blit_x and blit_y are u32, so fbcon currently cannot support fonts larger than 32x32. The 32x32 case also needs shifting an unsigned int, to properly set bit 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font", as reported on: http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com Kernel Branch: 6.2.0-rc5-next-20230124 Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharingReported-by: NSanan Hasanov <sanan.hasanov@Knights.ucf.edu> Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org> Fixes: 2d2699d9 ("fbcon: font setting should check limitation of driver") Cc: stable@vger.kernel.org Tested-by: NMiko Larsson <mikoxyzzz@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> (cherry picked from commit aa4e4b8d)
-
由 Stephen Brennan 提交于
mainline inclusion from mainline-v5.16-rc1 commit da4d6b9c category: bugfix bugzilla: 188892, https://gitee.com/openeuler/kernel/issues/I7CWJ7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=da4d6b9cf80ae5b0083f640133b85b68b53b6497 ---------------------------------------- Problem Description: When running running ~128 parallel instances of TZ=/etc/localtime ps -fe >/dev/null on a 128CPU machine, the %sys utilization reaches 97%, and perf shows the following code path as being responsible for heavy contention on the d_lockref spinlock: walk_component() lookup_fast() d_revalidate() pid_revalidate() // returns -ECHILD unlazy_child() lockref_get_not_dead(&nd->path.dentry->d_lockref) <-- contention The reason is that pid_revalidate() is triggering a drop from RCU to ref path walk mode. All concurrent path lookups thus try to grab a reference to the dentry for /proc/, before re-executing pid_revalidate() and then stepping into the /proc/$pid directory. Thus there is huge spinlock contention. This patch allows pid_revalidate() to execute in RCU mode, meaning that the path lookup can successfully enter the /proc/$pid directory while still in RCU mode. Later on, the path lookup may still drop into ref mode, but the contention will be much reduced at this point. By applying this patch, %sys utilization falls to around 85% under the same workload, and the number of ps processes executed per unit time increases by 3x-4x. Although this particular workload is a bit contrived, we have seen some large collections of eager monitoring scripts which produced similarly high %sys time due to contention in the /proc directory. As a result this patch, Al noted that several procfs methods which were only called in ref-walk mode could now be called from RCU mode. To ensure that this patch is safe, I audited all the inode get_link and permission() implementations, as well as dentry d_revalidate() implementations, in fs/proc. The purpose here is to ensure that they either are safe to call in RCU (i.e. don't sleep) or correctly bail out of RCU mode if they don't support it. My analysis shows that all at-risk procfs methods are safe to call under RCU, and thus this patch is safe. Procfs RCU-walk Analysis: This analysis is up-to-date with 5.15-rc3. When called under RCU mode, these functions have arguments as follows: * get_link() receives a NULL dentry pointer when called in RCU mode. * permission() receives MAY_NOT_BLOCK in the mode parameter when called from RCU. * d_revalidate() receives LOOKUP_RCU in flags. For the following functions, either they are trivially RCU safe, or they explicitly bail at the beginning of the function when they run: proc_ns_get_link (bails out) proc_get_link (RCU safe) proc_pid_get_link (bails out) map_files_d_revalidate (bails out) map_misc_d_revalidate (bails out) proc_net_d_revalidate (RCU safe) proc_sys_revalidate (bails out, also not under /proc/$pid) tid_fd_revalidate (bails out) proc_sys_permission (not under /proc/$pid) The remainder of the functions require a bit more detail: * proc_fd_permission: RCU safe. All of the body of this function is under rcu_read_lock(), except generic_permission() which declares itself RCU safe in its documentation string. * proc_self_get_link uses GFP_ATOMIC in the RCU case, so it is RCU aware and otherwise looks safe. The same is true of proc_thread_self_get_link. * proc_map_files_get_link: calls ns_capable, which calls capable(), and thus calls into the audit code (see note #1 below). The remainder is just a call to the trivially safe proc_pid_get_link(). * proc_pid_permission: calls ptrace_may_access(), which appears RCU safe, although it does call into the "security_ptrace_access_check()" hook, which looks safe under smack and selinux. Just the audit code is of concern. Also uses get_task_struct() and put_task_struct(), see note #2 below. * proc_tid_comm_permission: Appears safe, though calls put_task_struct (see note #2 below). Note #1: Most of the concern of RCU safety has centered around the audit code. However, since b17ec22f ("selinux: slow_avc_audit has become non-blocking"), it's safe to call this code under RCU. So all of the above are safe by my estimation. Note #2: get_task_struct() and put_task_struct(): The majority of get_task_struct() is under RCU read lock, and in any case it is a simple increment. But put_task_struct() is complex, given that it could at some point free the task struct, and this process has many steps which I couldn't manually verify. However, several other places call put_task_struct() under RCU, so it appears safe to use here too (see kernel/hung_task.c:165 or rcu/tree-stall.h:296) Patch description: pid_revalidate() drops from RCU into REF lookup mode. When many threads are resolving paths within /proc in parallel, this can result in heavy spinlock contention on d_lockref as each thread tries to grab a reference to the /proc dentry (and drop it shortly thereafter). Investigation indicates that it is not necessary to drop RCU in pid_revalidate(), as no RCU data is modified and the function never sleeps. So, remove the LOOKUP_RCU check. Link: https://lkml.kernel.org/r/20211004175629.292270-2-stephen.s.brennan@oracle.comSigned-off-by: NStephen Brennan <stephen.s.brennan@oracle.com> Cc: Konrad Wilk <konrad.wilk@oracle.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Matthew Wilcox <willy@infradead.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NLi Nan <linan122@huawei.com> (cherry picked from commit f2924f34)
-
- 16 6月, 2023 6 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/855 Remove the automatic loading of the hisi_trng driver issue:https://gitee.com/openeuler/kernel/issues/I79JTN Link:https://gitee.com/openeuler/kernel/pulls/882 Reviewed-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Kang Chen 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NYW4 CVE: NA -------------------------------- raw call flow: oom_kill_process -> mem_cgroup_scan_tasks(.., .., message) -> memcg_print_bad_task(message, ..) message is "const char*" type, and incorrectly cast to "oom_control*" type in memcg_print_bad_task. Fix it by moving memcg_print_bad_task out of mem_cgroup_scan_tasks and call it in select_bad_process and dump_tasks. Furthermore, use struct oom_control* directly and remove the useless parm `ret`. Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NKang Chen <void0red@hust.edu.cn> (cherry picked from commit 789038c7)
-
由 Qiuxu Zhuo 提交于
mainline inclusion from mainline-v6.3-rc1 commit e4b2bc66 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7DZRN CVE: NA Intel-SIG: commit e4b2bc66 EDAC/i10nm: Add Intel Emerald Rapids server support. Backport to decode memory error for Intel Emerald Rapids server. -------------------------------- The Emerald Rapids CPU model uses similar memory controller registers as Sapphire Rapids server. Add Emerald Rapids CPU model number ID for EDAC support. Tested-by: NLi Zhang <li4.zhang@intel.com> Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/all/20230113032802.41752-1-qiuxu.zhuo@intel.com [ Youquan Song: amend commit log ] Signed-off-by: NYouquan Song <youquan.song@intel.com> (cherry picked from commit 6b1c0854)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xiao_jiang_shui Loop branch using 'i++' as condition will cause the loop to not execute when 'i == 0', should use '++i', Fix it. issue: https://gitee.com/openeuler/kernel/issues/I7DUYJ Link:https://gitee.com/openeuler/kernel/pulls/1144 Reviewed-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1136 PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ID2Q7S2KSELYENBGS2BVZCEVGEP4WKO2/ Link:https://gitee.com/openeuler/kernel/pulls/1147 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Bob Peterson 提交于
mainline inclusion from mainline-v6.4-rc2 commit 504a10d9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7CXJL CVE: CVE-2023-3212 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=504a10d9e46bc37b23d0a1ae2f28973c8516e636 -------------------------------- On corrupt gfs2 file systems the evict code can try to reference the journal descriptor structure, jdesc, after it has been freed and set to NULL. The sequence of events is: init_journal() ... fail_jindex: gfs2_jindex_free(sdp); <------frees journals, sets jdesc = NULL if (gfs2_holder_initialized(&ji_gh)) gfs2_glock_dq_uninit(&ji_gh); fail: iput(sdp->sd_jindex); <--references jdesc in evict_linked_inode evict() gfs2_evict_inode() evict_linked_inode() ret = gfs2_trans_begin(sdp, 0, sdp->sd_jdesc->jd_blocks); <------references the now freed/zeroed sd_jdesc pointer. The call to gfs2_trans_begin is done because the truncate_inode_pages call can cause gfs2 events that require a transaction, such as removing journaled data (jdata) blocks from the journal. This patch fixes the problem by adding a check for sdp->sd_jdesc to function gfs2_evict_inode. In theory, this should only happen to corrupt gfs2 file systems, when gfs2 detects the problem, reports it, then tries to evict all the system inodes it has read in up to that point. Reported-by: NYang Lan <lanyang0908@gmail.com> Signed-off-by: NBob Peterson <rpeterso@redhat.com> Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com> Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Conflicts: fs/gfs2/super.c (cherry picked from commit a1816ee0)
-
- 15 6月, 2023 2 次提交
-
-
由 JiangShui Yang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DUYJ CVE: NA ---------------------------------------------------------------------- Loop branch using 'i++' as condition will cause the loop to not execute when 'i == 0', should use '++i', Fix it. Fixes: 26f2f10d ("crypto: hisilicon/qm - obtain the mailbox configuration at one time") Fixes: aabdf15d ("vfio/migration: obtain the mailbox configuration at one time") Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com> Signed-off-by: NWeili Qian <qianweili@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Jian <liujian56@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OU22IIXYWUCYAU6Z4EMLHBK3CNL4JAZK/ Link:https://gitee.com/openeuler/kernel/pulls/1140 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-