- 23 5月, 2023 10 次提交
-
-
由 Junhao He 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA ---------------------------------------------------------------------- On HiSilicon Hip09 platform, there is a UC (unified cache) module on each chip SCCL (Super CPU Cluster). UC is a cache that provides coherence between NUMA and UMA domains. It is located between L2 and Memory System. While PA uncore PMU model is the same as other Hip09 PMU modules and many PMU events are supported. Let's support the PMU driver using the HiSilicon uncore PMU framework. * rd_req_en : rd_req_en is the abbreviation of read request tracetag enable and allows user to count only read operations. details are listed in the hisi-pmu document. * srcid_en & srcid: allows user to filter statistics that come from specific CPU/ICL by configuration source ID. * uring_channel: Allows users to filter statistical information based on the specified tx request uring channel. uring_channel only supported events: [0x47 ~ 0x59]. Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 Junhao He 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA ---------------------------------------------------------------------- Compared to the original PA device, H60PA offers higher bandwidth. The PA H60 is a new device and we use HID to differentiate them. The events supported by PAv3 and PAv2 are different. They use the same HID. The PMU version register is used in the driver to distinguish different versions. For each H60PA PMU, except for the overflow interrupt register, other functions of the H60PA PMU are the same as the original PA PMU module. It has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (64-bits) overflow. Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 Junhao He 提交于
mainline inclusion from mainline-v6.4-rc1 commit 257aedb7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=257aedb72e731082ab514058e57b132f0b29d707 ---------------------------------------------------------------------- When allocations fails that can be NULL now. If the name provided is NULL, then the initialization process of the PMU type and dev will be skipped in function perf_pmu_register(). Consequently, the PMU will not be able to register into the kernel. Moreover, in the case of unregister the PMU, the function device_del() will need to handle NULL pointers, which potentially can cause issues. So move this allocation above the cpuhp_state_add_instance() and directly return if it does fail. Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 Junhao He 提交于
mainline inclusion from mainline-v6.4-rc1 commit 25d8c250 category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=25d8c25025a46e7621edde2eb6d5f55c6d29ee86 ---------------------------------------------------------------------- "pmu->name" is initialized by perf_pmu_register() function, so remove the redundant initialized in hisi_pmu_init(). Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 Junhao He 提交于
mainline inclusion from mainline-v6.3-rc1 commit e126f6f4 category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e126f6f42f89baee09e088ab6bc48f83ac3a0eae ---------------------------------------------------------------------- Use hisi_pmu_init() function to simplify initialization of "cpa_pmu->pmu". Signed-off-by: NJunhao He <hejunhao3@huawei.com> Link: https://lore.kernel.org/r/20230119100307.3660-4-hejunhao3@huawei.comSigned-off-by: NWill Deacon <will@kernel.org>
-
由 Junhao He 提交于
mainline inclusion from mainline-v6.3-rc1 commit 053b5579 category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=053b5579dacfc5763dda0c073ee14147421d32d7 ---------------------------------------------------------------------- Use "hisi_pmu" to simplify the parameter list for the hisi_pmu_init() function. Signed-off-by: NJunhao He <hejunhao3@huawei.com> Link: https://lore.kernel.org/r/20230119100307.3660-3-hejunhao3@huawei.comSigned-off-by: NWill Deacon <will@kernel.org>
-
由 Junhao He 提交于
mainline inclusion from mainline-v6.3-rc1 commit 7f95da9d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7f95da9d2dc4c20bb374c281ceb8fa40b6208f4b ---------------------------------------------------------------------- Missed initialization the variable of pmu::capabilities when extract the initialization code of hisi_pmu->pmu into a function. HISI UNCORE PMU drivers counters that not support context exclusion. So we have to advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will prevent us from handling events where any exclusion flags are set. Signed-off-by: NJunhao He <hejunhao3@huawei.com> Link: https://lore.kernel.org/r/20230119100307.3660-2-hejunhao3@huawei.comSigned-off-by: NWill Deacon <will@kernel.org>
-
由 Chen Jun 提交于
mainline inclusion from mainline-v6.0-rc1 commit e500405d category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e500405dd15d956790859fa532c64d8186445372 ---------------------------------------------------------------------- Extract the initialization code of hisi_pmu->pmu into a function Signed-off-by: NChen Jun <chenjun102@huawei.com> Link: https://lore.kernel.org/r/20220516131601.48383-1-chenjun102@huawei.comSigned-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NJunhao He <hejunhao3@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @kwb0523 Right now there is no way to query whether BPF programs are attached to a sockmap or not. we can use the standard interface in libbpf to query, such as: bpf_prog_query(mapFd, BPF_SK_SKB_STREAM_PARSER, 0, NULL, ...); the mapFd is the fd of sockmap. Link:https://gitee.com/openeuler/kernel/pulls/798 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhangjialin11 Pull new CVEs: CVE-2023-32233 CVE-2023-2124 iommu bugfix from Zhen Lei Link:https://gitee.com/openeuler/kernel/pulls/802 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
- 22 5月, 2023 10 次提交
-
-
由 JofDiamonds 提交于
mainline inclusion from mainline-v6.4-rc3 commit 748cd572 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I776SR CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=748cd5729ac7421091316e32dcdffb0578563880 ---------------------------------------------------------------------- Right now there is no way to query whether BPF programs are attached to a sockmap or not. we can use the standard interface in libbpf to query, such as: bpf_prog_query(mapFd, BPF_SK_SKB_STREAM_PARSER, 0, NULL, ...); the mapFd is the fd of sockmap. Signed-off-by: NDi Zhu <zhudi2@huawei.com> Acked-by: NYonghong Song <yhs@fb.com> Reviewed-by: NJakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/r/20220119014005.1209-1-zhudi2@huawei.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org> Conflicts: net/core/sock_map.c include/linux/bpf.h Signed-off-by: NJofDiamonds <kwb0523@163.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @sanglipeng Backport 5.10.152 LTS patches from upstream. Conflicts: Already merged(6): 392536023da1 block: wbt: Remove unnecessary invoking of wbt_update_limits in wbt_init 910ba49b3345 blk-wbt: call rq_qos_add() after wb_normal is initialized 51b96ecaedc0 arm64: errata: Remove AES hwcap for COMPAT tasks 7aa3d623c11b net: sched: fix race condition in qdisc_graft() f687e2111b6f fcntl: fix potential deadlocks for &fown_struct.lock (merged mainline commit f671a691 fcntl: fix potential deadlocks for &fown_struct.lock) 31b1570677e8 blk-wbt: fix that 'rwb->wc' is always set to 1 in wbt_init() Context conflict(3): dea47fefa6aa perf pmu: Validate raw event with sysfs exported format bits b1efc196446a fcntl: make F_GETOWN(EX) return 0 on dead owner task Rejected(1): a6e770733dc4 arm64: topology: move store_cpu_topology() to shared code Total patches: 72 - 6 -1 = 65 Link:https://gitee.com/openeuler/kernel/pulls/780 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from stable-v5.10.180 commit e044a24447189419c3a7ccc5fa6da7516036dc55 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I71F49 CVE: CVE-2023-32233 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e044a24447189419c3a7ccc5fa6da7516036dc55 -------------------------------- commit c1592a89 upstream. Toggle deleted anonymous sets as inactive in the next generation, so users cannot perform any update on it. Clear the generation bitmask in case the transaction is aborted. The following KASAN splat shows a set element deletion for a bound anonymous set that has been already removed in the same transaction. [ 64.921510] ================================================================== [ 64.923123] BUG: KASAN: wild-memory-access in nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.924745] Write of size 8 at addr dead000000000122 by task test/890 [ 64.927903] CPU: 3 PID: 890 Comm: test Not tainted 6.3.0+ #253 [ 64.931120] Call Trace: [ 64.932699] <TASK> [ 64.934292] dump_stack_lvl+0x33/0x50 [ 64.935908] ? nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.937551] kasan_report+0xda/0x120 [ 64.939186] ? nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.940814] nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.942452] ? __kasan_slab_alloc+0x2d/0x60 [ 64.944070] ? nf_tables_setelem_notify+0x190/0x190 [nf_tables] [ 64.945710] ? kasan_set_track+0x21/0x30 [ 64.947323] nfnetlink_rcv_batch+0x709/0xd90 [nfnetlink] [ 64.948898] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink] Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLu Wei <luwei32@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Darrick J. Wong 提交于
mainline inclusion from mainline-v6.3-rc6 commit 22ed903e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6X4UN CVE: CVE-2023-2124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22ed903eee23a5b174e240f1cdfa9acf393a5210 -------------------------------- syzbot detected a crash during log recovery: XFS (loop0): Mounting V5 Filesystem bfdc47fc-10d8-4eed-a562-11a831b3f791 XFS (loop0): Torn write (CRC failure) detected at log block 0x180. Truncating head block from 0x200. XFS (loop0): Starting recovery (logdev: internal) ================================================================== BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup_get_block+0x15c/0x6d0 fs/xfs/libxfs/xfs_btree.c:1813 Read of size 8 at addr ffff88807e89f258 by task syz-executor132/5074 CPU: 0 PID: 5074 Comm: syz-executor132 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 xfs_btree_lookup_get_block+0x15c/0x6d0 fs/xfs/libxfs/xfs_btree.c:1813 xfs_btree_lookup+0x346/0x12c0 fs/xfs/libxfs/xfs_btree.c:1913 xfs_btree_simple_query_range+0xde/0x6a0 fs/xfs/libxfs/xfs_btree.c:4713 xfs_btree_query_range+0x2db/0x380 fs/xfs/libxfs/xfs_btree.c:4953 xfs_refcount_recover_cow_leftovers+0x2d1/0xa60 fs/xfs/libxfs/xfs_refcount.c:1946 xfs_reflink_recover_cow+0xab/0x1b0 fs/xfs/xfs_reflink.c:930 xlog_recover_finish+0x824/0x920 fs/xfs/xfs_log_recover.c:3493 xfs_log_mount_finish+0x1ec/0x3d0 fs/xfs/xfs_log.c:829 xfs_mountfs+0x146a/0x1ef0 fs/xfs/xfs_mount.c:933 xfs_fs_fill_super+0xf95/0x11f0 fs/xfs/xfs_super.c:1666 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f89fa3f4aca Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffd5fb5ef8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00646975756f6e2c RCX: 00007f89fa3f4aca RDX: 0000000020000100 RSI: 0000000020009640 RDI: 00007fffd5fb5f10 RBP: 00007fffd5fb5f10 R08: 00007fffd5fb5f50 R09: 000000000000970d R10: 0000000000200800 R11: 0000000000000206 R12: 0000000000000004 R13: 0000555556c6b2c0 R14: 0000000000200800 R15: 00007fffd5fb5f50 </TASK> The fuzzed image contains an AGF with an obviously garbage agf_refcount_level value of 32, and a dirty log with a buffer log item for that AGF. The ondisk AGF has a higher LSN than the recovered log item. xlog_recover_buf_commit_pass2 reads the buffer, compares the LSNs, and decides to skip replay because the ondisk buffer appears to be newer. Unfortunately, the ondisk buffer is corrupt, but recovery just read the buffer with no buffer ops specified: error = xfs_buf_read(mp->m_ddev_targp, buf_f->blf_blkno, buf_f->blf_len, buf_flags, &bp, NULL); Skipping the buffer leaves its contents in memory unverified. This sets us up for a kernel crash because xfs_refcount_recover_cow_leftovers reads the buffer (which is still around in XBF_DONE state, so no read verification) and creates a refcountbt cursor of height 32. This is impossible so we run off the end of the cursor object and crash. Fix this by invoking the verifier on all skipped buffers and aborting log recovery if the ondisk buffer is corrupt. It might be smarter to force replay the log item atop the buffer and then see if it'll pass the write verifier (like ext4 does) but for now let's go with the conservative option where we stop immediately. Link: https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994eSigned-off-by: NDarrick J. Wong <djwong@kernel.org> Reviewed-by: NDave Chinner <dchinner@redhat.com> Signed-off-by: NDave Chinner <david@fromorbit.com> Signed-off-by: NLong Li <leo.lilong@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Zhen Lei 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6WAZX -------------------------------- When the number of cores is greater than the number of ECMDQs, the number of ECMDQs occupied by each NUMA node is less than the number of cores of the node. Therefore, the first smmu->nr_ecmdq cores do not cover all ECMDQs. For example: --------------------------------------- | Node0 | Node1 | |---------------------------------------| | 0 1 2 3 | 4 5 6 7 | CPU ID |---------------------------------------| | 0 1 | 2 3 | ECMDQ ID --------------------------------------- Fixes: 3965519b ("iommu/arm-smmu-v3: Add support for less than one ECMDQ per core") Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xiao_jiang_shui Add debugfs 'dev_state' to query the status of the stop queue. And the root user can set 'dev_timeout', if task flow fails to be stopped, the driver waits dev_timeout * 20ms before releasing the queue. 关联issue:https://gitee.com/openeuler/kernel/issues/I76TVJ Link:https://gitee.com/openeuler/kernel/pulls/791 Reviewed-by: Yang Shen <shenyang39@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xia-bing1 1. Do not frequently enter the I/O exception handling process. Change the timeout interval of the DMA setup and data frame to 2.5s. 2. When multiple I/Os are delivered in the NCQ scenario and one of the I/Os is faulty, the group slow disk problem will occur. Add patch at the hisi_sas layer to ensure consistency between the Linux community and the openEuler solution. Link:https://gitee.com/openeuler/kernel/pulls/794 Reviewed-by: Yihang Li <liyihang9@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @steven-song3 The driver supports 3snic 3s9xx serial network cards (100GE (40GE compatible)-3S930 and 25GE (10GE compatible)-3S910/3S920). feature: 1. Support single-root I/O virtualization (SR-IOV) 2. Support virtual machine multi queue (VMMQ) 3. Support receive side scaling (RSS) 4. Support physical function (PF) passthrough VMs 5. Support the PF promiscuous mode,unicast or multicast MAC filtering, and all multicast mode 6. Support IPv4/IPv6, checksum offload,TCP Segmentation Offload (TSO), and Large Receive Offload (LRO) 7. Support in-band one-click logs collection 8. Support loopback tests 9. Support port location indicators ================================== Test: compille: pass insmod/rmmod: pass iperf: Pass Link:https://gitee.com/openeuler/kernel/pulls/608 Reviewed-by: Liu Chao <liuchao173@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Weili Qian 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I76TVJ CVE: NA ---------------------------------------------------------------------- The debugfs files 'dev_state' and 'dev_timeout' are added. dev_state: if dev_timeout is set, dev_state indicates the status of stopping the queue. 0 indicates that the queue is stopped successfully. Other values indicate that the queue stops fail. if dev_timeout is not set, the value of dev_state is 0; dev_timeout: If the queue fails to stop, the queue is released after waiting dev_timeout * 20ms. Signed-off-by: NWeili Qian <qianweili@huawei.com> Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
-
由 Weili Qian 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I76TVJ CVE: NA ---------------------------------------------------------------------- Debugfs for query the status of stopping queue, the root user can set the waiting time after the task flow fails to be stopped. Signed-off-by: NWeili Qian <qianweili@huawei.com> Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com>
-
- 20 5月, 2023 6 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @Tom_zc Fix issue https://gitee.com/openeuler/kernel/issues/I6N4EP, And solve the kabi change caused by enabling bcache in x86 platforms. Related PR: https://gitee.com/openeuler/kernel/pulls/757 https://gitee.com/openeuler/kernel/pulls/771 Link:https://gitee.com/openeuler/kernel/pulls/782 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Liu Chao <liuchao173@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @Hongchen_Zhang LoongArch: fix the following issues: - Modify loongson3_defconfig to support the cachefilesd service - Loongson: i2c fixes the issue of interrupt not freed after remove the module - Fix page table property operation issues - Fix kernel crash triggered by ltp io_uring02 testcase - Fix nvme timeout issue triggered by LTP cpuhotplug testcase - Fix double bridge machine boot failed Link:https://gitee.com/openeuler/kernel/pulls/765 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Xingui Yang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I76WNL 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: NXingui Yang <yangxingui@huawei.com> Signed-off-by: NYihang Li <liyihang9@huawei.com> Reviewed-by: NXiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Xingui Yang 提交于
mainline inclusion from mainline-v6.2-rc1 commit 4ef4f1a6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I76WNL CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ef4f1a6155571d3d53583a4e8e7ccbbec220b8a ---------------------------------------------------------------------- When an NCQ error occurs, the controller will abnormally complete the I/Os that are newly delivered to disk, and bit8 in CQ dw3 will be set which indicates that the SATA disk is in error state. The current processing flow is to set ts->stat to SAS_OPEN_REJECT and then sas_ata_task_done() will set FIS stat to ATA_ERR. After analyzing the I/O by ata_eh_analyze_tf(), err_mask will set to AC_ERR_HSM. If media error occurs for four times within 10 minutes and the chip rejects new I/Os for four times, NCQ will be disabled due to excessive errors, which is undesirable. Therefore, use sas_task_abort() to handle abnormally completed I/Os when SATA disk is in error state, as these abnormally completed I/Os are already processed by sas_ata_device_link_abort() and qc->flag are set to ATA_QCFLAG_FAILED. If sas_task_abort() is used, qc->err_mask will not be modified in EH. Unlike the current process flow, it will not increase the count of ECAT_TOUT_HSM and not turn off NCQ. Like other I/Os on the disk that do not have an error but do not return after the NCQ error, they are retried after the EH. Signed-off-by: NXingui Yang <yangxingui@huawei.com> Signed-off-by: NJohn Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1665998435-199946-5-git-send-email-john.garry@huawei.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @anred This patch series optimizes userswap mainly including swap-in and swap-out. We tested the concurrent scenario of multi-threaded page fault and multi-threaded swap-in in the uswap demo;and the remapping in the swap-out phase and the copy-free function in the swap-in phase were ok. During the test, related debugging functions including CONFIG_DEBUG_VM, lockdep, slub debug, kasan and kmemleak are enabled. Link:https://gitee.com/openeuler/kernel/pulls/786 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @sun_nanyong patch 1~6: backport mainline patchset(mm: process/cgroup ksm support)and patches it depends on. patch 7:Add control file "memory.ksm" to enable ksm per cgroup. Link:https://gitee.com/openeuler/kernel/pulls/790 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 19 5月, 2023 9 次提交
-
-
由 Nanyong Sun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA ---------------------------------------------------------------------- Add control file "memory.ksm" to enable ksm per cgroup. Echo to 1 will set all tasks currently in the cgroup to ksm merge any mode, which means ksm gets enabled for all vma's of a process. Meanwhile echo to 0 will disable ksm for them and unmerge the merged pages. Cat the file will show the above state and ksm related profits of this cgroup. Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 David Hildenbrand 提交于
mainline inclusion from mainline-v6.4-rc1 commit 24139c07 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24139c07f413ef4b555482c758343d71392a19bc ---------------------------------------------------------------------- Patch series "mm/ksm: improve PR_SET_MEMORY_MERGE=0 handling and cleanup disabling KSM", v2. (1) Make PR_SET_MEMORY_MERGE=0 unmerge pages like setting MADV_UNMERGEABLE does, (2) add a selftest for it and (3) factor out disabling of KSM from s390/gmap code. This patch (of 3): Let's unmerge any KSM pages when setting PR_SET_MEMORY_MERGE=0, and clear the VM_MERGEABLE flag from all VMAs -- just like KSM would. Of course, only do that if we previously set PR_SET_MEMORY_MERGE=1. Link: https://lkml.kernel.org/r/20230422205420.30372-1-david@redhat.com Link: https://lkml.kernel.org/r/20230422205420.30372-2-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com> Acked-by: NStefan Roesch <shr@devkernel.io> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Rik van Riel <riel@surriel.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: mm/ksm.c Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 Stefan Roesch 提交于
mainline inclusion from mainline-v6.4-rc1 commit d21077fb category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d21077fbc2fc987c2e593c34dc3b4d84e546dc9f ---------------------------------------------------------------------- This adds the general_profit KSM sysfs knob and the process profit metric knobs to ksm_stat. 1) expose general_profit metric The documentation mentions a general profit metric, however this metric is not calculated. In addition the formula depends on the size of internal structures, which makes it more difficult for an administrator to make the calculation. Adding the metric for a better user experience. 2) document general_profit sysfs knob 3) calculate ksm process profit metric The ksm documentation mentions the process profit metric and how to calculate it. This adds the calculation of the metric. 4) mm: expose ksm process profit metric in ksm_stat This exposes the ksm process profit metric in /proc/<pid>/ksm_stat. The documentation mentions the formula for the ksm process profit metric, however it does not calculate it. In addition the formula depends on the size of internal structures. So it makes sense to expose it. 5) document new procfs ksm knobs Link: https://lkml.kernel.org/r/20230418051342.1919757-3-shr@devkernel.ioSigned-off-by: NStefan Roesch <shr@devkernel.io> Reviewed-by: NBagas Sanjaya <bagasdotme@gmail.com> Acked-by: NDavid Hildenbrand <david@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Rik van Riel <riel@surriel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 Stefan Roesch 提交于
mainline inclusion from mainline-v6.4-rc1 commit d7597f59 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7597f59d1d33e9efbffa7060deb9ee5bd119e62 ---------------------------------------------------------------------- Patch series "mm: process/cgroup ksm support", v9. So far KSM can only be enabled by calling madvise for memory regions. To be able to use KSM for more workloads, KSM needs to have the ability to be enabled / disabled at the process / cgroup level. Use case 1: The madvise call is not available in the programming language. An example for this are programs with forked workloads using a garbage collected language without pointers. In such a language madvise cannot be made available. In addition the addresses of objects get moved around as they are garbage collected. KSM sharing needs to be enabled "from the outside" for these type of workloads. Use case 2: The same interpreter can also be used for workloads where KSM brings no benefit or even has overhead. We'd like to be able to enable KSM on a workload by workload basis. Use case 3: With the madvise call sharing opportunities are only enabled for the current process: it is a workload-local decision. A considerable number of sharing opportunities may exist across multiple workloads or jobs (if they are part of the same security domain). Only a higler level entity like a job scheduler or container can know for certain if its running one or more instances of a job. That job scheduler however doesn't have the necessary internal workload knowledge to make targeted madvise calls. Security concerns: In previous discussions security concerns have been brought up. The problem is that an individual workload does not have the knowledge about what else is running on a machine. Therefore it has to be very conservative in what memory areas can be shared or not. However, if the system is dedicated to running multiple jobs within the same security domain, its the job scheduler that has the knowledge that sharing can be safely enabled and is even desirable. Performance: Experiments with using UKSM have shown a capacity increase of around 20%. Here are the metrics from an instagram workload (taken from a machine with 64GB main memory): full_scans: 445 general_profit: 20158298048 max_page_sharing: 256 merge_across_nodes: 1 pages_shared: 129547 pages_sharing: 5119146 pages_to_scan: 4000 pages_unshared: 1760924 pages_volatile: 10761341 run: 1 sleep_millisecs: 20 stable_node_chains: 167 stable_node_chains_prune_millisecs: 2000 stable_node_dups: 2751 use_zero_pages: 0 zero_pages_sharing: 0 After the service is running for 30 minutes to an hour, 4 to 5 million shared pages are common for this workload when using KSM. Detailed changes: 1. New options for prctl system command This patch series adds two new options to the prctl system call. The first one allows to enable KSM at the process level and the second one to query the setting. The setting will be inherited by child processes. With the above setting, KSM can be enabled for the seed process of a cgroup and all processes in the cgroup will inherit the setting. 2. Changes to KSM processing When KSM is enabled at the process level, the KSM code will iterate over all the VMA's and enable KSM for the eligible VMA's. When forking a process that has KSM enabled, the setting will be inherited by the new child process. 3. Add general_profit metric The general_profit metric of KSM is specified in the documentation, but not calculated. This adds the general profit metric to /sys/kernel/debug/mm/ksm. 4. Add more metrics to ksm_stat This adds the process profit metric to /proc/<pid>/ksm_stat. 5. Add more tests to ksm_tests and ksm_functional_tests This adds an option to specify the merge type to the ksm_tests. This allows to test madvise and prctl KSM. It also adds a two new tests to ksm_functional_tests: one to test the new prctl options and the other one is a fork test to verify that the KSM process setting is inherited by client processes. This patch (of 3): So far KSM can only be enabled by calling madvise for memory regions. To be able to use KSM for more workloads, KSM needs to have the ability to be enabled / disabled at the process / cgroup level. 1. New options for prctl system command This patch series adds two new options to the prctl system call. The first one allows to enable KSM at the process level and the second one to query the setting. The setting will be inherited by child processes. With the above setting, KSM can be enabled for the seed process of a cgroup and all processes in the cgroup will inherit the setting. 2. Changes to KSM processing When KSM is enabled at the process level, the KSM code will iterate over all the VMA's and enable KSM for the eligible VMA's. When forking a process that has KSM enabled, the setting will be inherited by the new child process. 1) Introduce new MMF_VM_MERGE_ANY flag This introduces the new flag MMF_VM_MERGE_ANY flag. When this flag is set, kernel samepage merging (ksm) gets enabled for all vma's of a process. 2) Setting VM_MERGEABLE on VMA creation When a VMA is created, if the MMF_VM_MERGE_ANY flag is set, the VM_MERGEABLE flag will be set for this VMA. 3) support disabling of ksm for a process This adds the ability to disable ksm for a process if ksm has been enabled for the process with prctl. 4) add new prctl option to get and set ksm for a process This adds two new options to the prctl system call - enable ksm for all vmas of a process (if the vmas support it). - query if ksm has been enabled for a process. 3. Disabling MMF_VM_MERGE_ANY for storage keys in s390 In the s390 architecture when storage keys are used, the MMF_VM_MERGE_ANY will be disabled. Link: https://lkml.kernel.org/r/20230418051342.1919757-1-shr@devkernel.io Link: https://lkml.kernel.org/r/20230418051342.1919757-2-shr@devkernel.ioSigned-off-by: NStefan Roesch <shr@devkernel.io> Acked-by: NDavid Hildenbrand <david@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Rik van Riel <riel@surriel.com> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: kernel/sys.c mm/ksm.c mm/mmap.c Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 xu xin 提交于
mainline inclusion from mainline-v6.1-rc1 commit 21b7bdb5 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21b7bdb504ae6b0a795c8d63818611ce02b532c1 ---------------------------------------------------------------------- Add the description of KSM profit and how to determine it separately in system-wide range and inner a single process. Link: https://lkml.kernel.org/r/20220830144003.299870-1-xu.xin16@zte.com.cnSigned-off-by: Nxu xin <xu.xin16@zte.com.cn> Reviewed-by: NXiaokai Ran <ran.xiaokai@zte.com.cn> Reviewed-by: NYang Yang <yang.yang29@zte.com.cn> Reviewed-by: NBagas Sanjaya <bagasdotme@gmail.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Izik Eidus <izik.eidus@ravellosystems.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: Documentation/admin-guide/mm/ksm.rst Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 xu xin 提交于
mainline inclusion from mainline-v6.1-rc1 commit cb4df4ca category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb4df4cae4f2bd8cf7a32eff81178fce31600f7c ---------------------------------------------------------------------- Patch series "ksm: count allocated rmap_items and update documentation", v5. KSM can save memory by merging identical pages, but also can consume additional memory, because it needs to generate rmap_items to save each scanned page's brief rmap information. To determine how beneficial the ksm-policy (like madvise), they are using brings, so we add a new interface /proc/<pid>/ksm_stat for each process The value "ksm_rmap_items" in it indicates the total allocated ksm rmap_items of this process. The detailed description can be seen in the following patches' commit message. This patch (of 2): KSM can save memory by merging identical pages, but also can consume additional memory, because it needs to generate rmap_items to save each scanned page's brief rmap information. Some of these pages may be merged, but some may not be abled to be merged after being checked several times, which are unprofitable memory consumed. The information about whether KSM save memory or consume memory in system-wide range can be determined by the comprehensive calculation of pages_sharing, pages_shared, pages_unshared and pages_volatile. A simple approximate calculation: profit =~ pages_sharing * sizeof(page) - (all_rmap_items) * sizeof(rmap_item); where all_rmap_items equals to the sum of pages_sharing, pages_shared, pages_unshared and pages_volatile. But we cannot calculate this kind of ksm profit inner single-process wide because the information of ksm rmap_item's number of a process is lacked. For user applications, if this kind of information could be obtained, it helps upper users know how beneficial the ksm-policy (like madvise) they are using brings, and then optimize their app code. For example, one application madvise 1000 pages as MERGEABLE, while only a few pages are really merged, then it's not cost-efficient. So we add a new interface /proc/<pid>/ksm_stat for each process in which the value of ksm_rmap_itmes is only shown now and so more values can be added in future. So similarly, we can calculate the ksm profit approximately for a single process by: profit =~ ksm_merging_pages * sizeof(page) - ksm_rmap_items * sizeof(rmap_item); where ksm_merging_pages is shown at /proc/<pid>/ksm_merging_pages, and ksm_rmap_items is shown in /proc/<pid>/ksm_stat. Link: https://lkml.kernel.org/r/20220830143731.299702-1-xu.xin16@zte.com.cn Link: https://lkml.kernel.org/r/20220830143838.299758-1-xu.xin16@zte.com.cnSigned-off-by: Nxu xin <xu.xin16@zte.com.cn> Reviewed-by: NXiaokai Ran <ran.xiaokai@zte.com.cn> Reviewed-by: NYang Yang <yang.yang29@zte.com.cn> Signed-off-by: NCGEL ZTE <cgel.zte@gmail.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Izik Eidus <izik.eidus@ravellosystems.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: include/linux/mm_types.h Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 xu xin 提交于
mainline inclusion from mainline-v5.19-rc1 commit 76093853 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I72R0B CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7609385337a4feb6236e42dcd0df2185683ce839 ---------------------------------------------------------------------- Some applications or containers want to use KSM by calling madvise() to advise areas of address space to be MERGEABLE. But they may not know which applications are more likely to cause real merges in the deployment. If this patch is applied, it helps them know their corresponding number of merged pages, and then optimize their app code. As current KSM only counts the number of KSM merging pages(e.g. ksm_pages_sharing and ksm_pages_shared) of the whole system, we cannot see the more fine-grained KSM merging, for the upper application optimization, the merging area cannot be set easily according to the KSM page merging probability of each process. Therefore, it is necessary to add extra statistical means so that the upper level users can know the detailed KSM merging information of each process. We add a new proc file named as ksm_merging_pages under /proc/<pid>/ to indicate the involved ksm merging pages of this process. [akpm@linux-foundation.org: fix comment typo, remove BUG_ON()s] Link: https://lkml.kernel.org/r/20220325082318.2352853-1-xu.xin16@zte.com.cnSigned-off-by: Nxu xin <xu.xin16@zte.com.cn> Reported-by: Nkernel test robot <lkp@intel.com> Reviewed-by: NYang Yang <yang.yang29@zte.com.cn> Reviewed-by: NRan Xiaokai <ran.xiaokai@zte.com.cn> Reported-by: NZeal Robot <zealci@zte.com.cn> Cc: Kees Cook <keescook@chromium.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Ohhoon Kwon <ohoono.kwon@samsung.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Stephen Brennan <stephen.s.brennan@oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Feng Tang <feng.tang@intel.com> Cc: Yang Yang <yang.yang29@zte.com.cn> Cc: Ran Xiaokai <ran.xiaokai@zte.com.cn> Cc: Zeal Robot <zealci@zte.com.cn> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: include/linux/mm_types.h Signed-off-by: NNanyong Sun <sunnanyong@huawei.com>
-
由 Steven Song 提交于
3snic inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6TX4J CVE: NA -------------------------------- The driver supports 3snic 3s9xx serial network cards (100GE (40GE compatible)-3S930 and 25GE (10GE compatible)-3S910/3S920). Feature: 1. Support single-root I/O virtualization (SR-IOV) 2. Support virtual machine multi queue (VMMQ) 3. Support receive side scaling (RSS) 4. Support physical function (PF) passthrough VMs 5. Support the PF promiscuous mode,unicast or multicast MAC filtering, and all multicast mode 6. Support IPv4/IPv6, checksum offload,TCP Segmentation Offload (TSO), and Large Receive Offload (LRO) 7. Support in-band one-click logs collection 8. Support loopback tests 9. Support port location indicators Reviewed-by: NChen Mou <chenmou@3snic.com> Reviewed-by: NWan Renyong <wanry@3snic.com> Reviewed-by: NYang Gan <yanggan@3snic.com> Reviewed-by: NWen Liang <wenliang@3snic.com> Signed-off-by: NSteven Song <steven.song@3snic.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/774 Pull new CVEs: CVE-2023-32269 CVE-2023-2002 CVE-2023-26544 CVE-2023-0459 mm bugfixes from Yu Kuai fs bugfix from yangerkun fs perfs from Zhihao Cheng Link:https://gitee.com/openeuler/kernel/pulls/778 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
- 18 5月, 2023 5 次提交
-
-
由 ZhangPeng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- Add user mode check for swap-out VA to make sure that swap-out VA is user mode address. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- Check the VM_READ and VM_WRITE flags of vma->vm_flags to determine whether the read and write permissions of the swap-out page VA are consistent with those of the swap-out buffer VA. If they are inconsistent, the swap operation will fail. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- Add VMA checks for register address to make sure that register address has the corresponding VMA. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- Add checks for new_addr in uswap_mremap() and src_addr in uswap_check_copy_mode(), including user mode checks, overlapping checks, etc. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- As follows, fix some type and logical bugs. 1) The type of index variable is changed from int to unsigned long to support large memory registration. 2) Fix the bug that USWAP_PAGES_DIRTY does not take effect. 3) Take the mmap_read_lock() when using the VMA in uswap_adjust_uffd_range(). 4) Do some code refactoring and cleancode. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
-