- 09 11月, 2022 8 次提交
-
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Support RDMA_CM in ROH mode Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- ROH MAC do not support ROCEv1 and ROCEv2@IPv6. ROCE driver adapts to these limiations. Signed-off-by: NLang Cheng <chenglang@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Add ROH device ID. Signed-off-by: NLang Cheng <chenglang@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: featur bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- This patch provides the basic dfx information query method of ROH through the kernel debufs system. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Hook up the reset notify interface to adapt to the ROH reset process. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Changing the IP address will generate a network event. We register and capture the inetaddr notifier and use the changed IP address to configure the roh eid. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- This patch adds initialization and deinitialization for roh interrupt. This interrupt will be used to handle link event reporting. The ROH core provides a mechanism for processing ROH event notifications, which is used by the driver to report link events to roh core. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Provide roh device sysfs file operation node, include querying the EID, GUID, link status and roh mib statistics. The hns dirver provides some verbs for the roh core to set or query the hardware information. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>
-
- 08 11月, 2022 1 次提交
-
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Each ROH device has its own cmdq interface, which includes send queue CSQ and receive queue CRQ. These commands are used to obtain the resources of the ROH device from IMP and implement related configurations. This patch adds the support of IMP command interface to the ROH driver, include: 1. initialize the roh command queue resource 2. manage the roh command queue descriptors 3. provide the cmdq send operation APIs Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
- 07 11月, 2022 6 次提交
-
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- These are the source code files for the Hisilicon ROH driver for ARM, include: 1. hns3_roh_device instance initialization and uninitialization. 2. apply for a ROH device to register with the ROH core, deregister and release the ROH device from ROH Core. Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Adds ROH reset support for HNS3 ethernet driver. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- Add HCLGE_RAS_REG_ROH_ERR_MASK to support the error recovery of the ROH ras. Add HCLGE_RAS_REG_ERR_MASK to define the combination of the nfe_mask, the rocee_err_mask and the roh_err_mask. Add new module error types for ROH, adjust the order of these types according to the design of firmware. Signed-off-by: Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- In ROH mode, MAC address is related to the EID. If an invalid MAC address is set, the mapping between MAC and EID cannot be ensured, and communication may be abnormal. Therefore, firmware verification is required to intercept invalid MAC address set by user. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- HNAE3 framework add MAC type definitions for NIC or RoCE or ROH clients. There are two types of MAC in Hip09, ethernet and ROH. In ROH type, some operations are different, such as setting MAC address. This type will be used as the judgment condition in subsequent patches. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
由 Ke Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW ----------------------------------------------------------------------- HNAE3 framework supports ROH clients to register with HNAE3 devices and their associated operations. The ROH driver works as a client at the HNAE layer. The NIC driver needs to provide some necessary information, such as the vector base address, and suppor the registration of the ROH client. This patch also supports roh device IDs in the hns3 and hclge modules. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NKe Chen <chenke54@huawei.com> Reviewed-by: NGang Zhang <gang.zhang@huawei.com> Reviewed-by: NYefeng Yan <yanyefeng@huawei.com> Reviewed-by: NJingchao Dai <daijingchao1@huawei.com> Reviewed-by: NJian Shen <shenjian15@huawei.com>
-
- 04 11月, 2022 5 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @leoliu-oc The patch is to add Zhaoxin feature bits on Zhaoxin CPUs. ### Issue [#I5NYQF](https://gitee.com/openeuler/kernel/issues/I5NYQF) ### Test Build and boot kernel with this patch. Check various features in `lscpu` or `/proc/cpuinfo`. ```shell # cat /proc/cpuinfo | grep flags # or # lscpu | grep flags # you will see new Zhaoxin feature flags # for example, rng2/rng2_en/phe2/phe2_en/... # +#define X86_FEATURE_RNG2 (5*32+22) /* 2nd generation of RNG present */ # +#define X86_FEATURE_RNG2_EN (5*32+23) /* 2nd generation of RNG enabled */ # +#define X86_FEATURE_PHE2 (5*32+25) /* SHA384 and SHA 512 present */ # +#define X86_FEATURE_PHE2_EN (5*32+26) /* SHA384 and SHA 512 enabled */ Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq monitor vmx smx est tm2 ssse3 cx16 xtpr pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand rng rng_en ccs ccs_en ace ace_en ace2 phe phe_en pmm pmm_en parallax parallax_en rng2 rng2_en phe2 phe2_en xmodx xmodx_en lahf_lm abm 3dnowprefetch invpcid_single tpr_shadow vnmi ept vpid fsgsbase tsc_adjust bmi1 smep bmi2 invpcid rdseed adx xsaveopt dtherm umip arch_capabilities ``` ### Known Issue N/A ### Default config change N/A Link:https://gitee.com/openeuler/kernel/pulls/85 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
!166 SPR: KVM: Add new instructions, Bus Lock Debug Exception, Bus Lock VM exit and Notify VM exit support Merge Pull Request from: @allen-shi This PR is to add new instructions(AVX_VNNI and AVX512_FP16), Bus Lock Debug Exception, Bus Lock VM exit and Notify VM exit support, and kabi is not changed based on OpenEuler-22.03-LTS kabi whitelist. **Intel-Kernel Issue** [#I5O6WB](https://gitee.com/openeuler/intel-kernel/issues/I5O6WB) [#I5RJCB](https://gitee.com/openeuler/intel-kernel/issues/I5RJCB) [#I5PAJ5](https://gitee.com/openeuler/intel-kernel/issues/I5PAJ5) [#I5RHW7](https://gitee.com/openeuler/intel-kernel/issues/I5RHW7) **Test** 1. Built and run the kernel successfully on OpenEuler 22.03 LTS. 2. SPR new instructions feature(AVX_VNNI and AVX512_FP16) is supported on guests. 3. Bus Lock Debug Exception feature is supported on guests. 4. Bus Lock VM Exit feature is supported. 5. Notify VM Exit feature is supported. **Known Issue** N/A **Default config change** N/A Link:https://gitee.com/openeuler/kernel/pulls/166 Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Jason Zeng <jason.zeng@intel.com> Reviewed-by: Chen Wei <chenwei@xfusion.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 LeoLiu-oc 提交于
zhaoxin inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5NYQF CVE: NA -------------------------------------------- Add Zhaoxin feature bits on Zhaoxin CPUs. Signed-off-by: NLeoLiu-oc <LeoLiu-oc@zhaoxin.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @youquan_song [Description] https://gitee.com/openeuler/intel-kernel/issues/I5V3SJ An HBM memory channel is divided into two pseudo channels. Each pseudo channel has its own retry_rd_err_log registers. Retrieve and print retry_rd_err_log registers of the HBM pseudo channel if the memory error is from HBM. 14646de4 EDAC/skx_common: Add ChipSelect ADXL component acd4cf68 EDAC/i10nm: Retrieve and print retry_rd_err_log registers for HBM d5f5e499 EDAC/i10nm: Print an extra register set of retry_rd_err_log [Testing] 1.Add kernel options in grub: efi=nosoftreserve i10nm_edac.retry_rd_err_log=1 2.numactl -H node distances: node 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0: 10 12 12 12 21 21 21 21 13 14 14 14 23 23 23 23 1: 12 10 12 12 21 21 21 21 14 13 14 14 23 23 23 23 2: 12 12 10 12 21 21 21 21 14 14 13 14 23 23 23 23 3: 12 12 12 10 21 21 21 21 14 14 14 13 23 23 23 23 4: 21 21 21 21 10 12 12 12 23 23 23 23 13 14 14 14 5: 21 21 21 21 12 10 12 12 23 23 23 23 14 13 14 14 6: 21 21 21 21 12 12 10 12 23 23 23 23 14 14 13 14 7: 21 21 21 21 12 12 12 10 23 23 23 23 14 14 14 13 8: 13 14 14 14 23 23 23 23 10 14 14 14 23 23 23 23 9: 14 13 14 14 23 23 23 23 14 10 14 14 23 23 23 23 10: 14 14 13 14 23 23 23 23 14 14 10 14 23 23 23 23 11: 14 14 14 13 23 23 23 23 14 14 14 10 23 23 23 23 12: 23 23 23 23 13 14 14 14 23 23 23 23 10 14 14 14 13: 23 23 23 23 14 13 14 14 23 23 23 23 14 10 14 14 14: 23 23 23 23 14 14 13 14 23 23 23 23 14 14 10 14 15: 23 23 23 23 14 14 14 13 23 23 23 23 14 14 14 10 3. #modprobe einj 4. git clone https://git.kernel.org/pub/scm/linux/kernel/git/aegl/ras-tools.git, build it 5. # numactl --cpunodebind=0 --membind=13 /home/ras-tools/cmcistorm 1 0: vaddr = 0x130d490 paddr = d87ff42490 6. #dmesg: output retry_rd_err_log registers value. [83086.997090] EDAC MC29: 0 CE memory read error on CPU_SrcID#1_HBMC#9_Chan#1 (channel:1 page:0xd87ff42 offset:0x480 grain:32 syndrome:0x0 - err_code:0x0000:0x009f SystemAddress:0xd87ff42480 ProcessorSocketId:0x1 MemoryControllerId:0x9 ChannelAddress:0x7ffe8480 ChannelId:0x1 RankAddress:0x3fff4240 PhysicalRankId:0x0 Row:0x7ffe Column:0x14 Bank:0x0 BankGroup:0x0 ChipSelect:0x2 ChipId:0x1 retry_rd_err_log[08928208 00000000 0000000000010000 00500081 80007ffe 000000d87ff42480] correrrcnt[0001 0000 0001 0000 0000 0000 0000 0000]) Link:https://gitee.com/openeuler/kernel/pulls/171 Reviewed-by: Chen Wei <chenwei@xfusion.com> Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Jun Tian <jun.j.tian@intel.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @juntianlinux [Description] Temporary fix for #I5U037 Occasionally TSC clocksource is wrongly judged as unstable watchdog like 'jiffies', HPET on some platforms like Skylake 4S. For normal cases, we can use nr_online_nodes <= 4 as a quick workaround for this issue. However, there are many cases that 'nr_online_nodes' could have issue. Intel is still working on a formal fix, the patch in this PR is a more general fix but still have open under discussion. Generally, there are some corner cases, but we can use this for a temporary fix to this issue. In next step, we need to update this fix after upstream merging the final solution. Link:https://gitee.com/openeuler/kernel/pulls/210 Reviewed-by: Jiao Fenfang <jiaofenfang@uniontech.com> Reviewed-by: Chen Wei <chenwei@xfusion.com> Reviewed-by: Xibo.Wang <wangxb12@chinatelecom.cn> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 03 11月, 2022 20 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @guzitao These patches generally cover the following tasks: 1.optimize kernel cores, remove unused codes, simplify interfaces, fix compile errors 2.fixes for perf, fix perf_get_regs_user, uretprobe, uprobe 3.add support, add ebpf-jit compiler support, add guest live migration support, add support for S3 sleep option 4.modify interface, reimplement die_if_kernel, fix sys_rt_sigaction, 5.fixes for kvm, expand the number of SWVM_IRQS, fix wrong info print of KVM_MEMHOTPLUG, turn off the clock timer of guest os 6.fix dynamic CPUfreq scaling bugs Link:https://gitee.com/openeuler/kernel/pulls/198 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Xiang Chen 提交于
mainline inclusion from mainline-v5.19-rc7 commit 1e82e462 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5M9GC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e82e4627a795 ---------------------------------------------------------------------- Currently if a phy reset or enable phy is issued via sysfs when controller is suspended, those operations will be ignored as SAS_HA_REGISTERED is cleared. If RPM is enabled then we may aggressively suspend automatically. In this case it may be difficult to enable or reset a phy via sysfs, so resume the host in these scenarios. Link: https://lore.kernel.org/r/1657823002-139010-6-git-send-email-john.garry@huawei.comSigned-off-by: NXiang Chen <chenxiang66@hisilicon.com> Signed-off-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yixing Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5YZ0Q ---------------------------------------------------------- When the driver does not have an ex_cmd flag, related ioctl() or syscall() will fail to execute. for example, if the modify_qp flag is missing, the following error will appear when running perftest: Failed to modify QP to INIT, ret=95 Failed to modify QP to INIT Failed to modify QP 24 to RTR Failed to modify QP 25 to RTR Unable to Connect the HCA's through the link Unable to Connect the HCA's through the link So add query_device、create_cq、modify_qp and create_qp flag. Fixes: df065107 ("RDMA/hns: Enable modify_cq for uverbs.") Signed-off-by: NYixing Liu <liuyixing1@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lang Cheng 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Z2DS ---------------------------------------------------------- When the netdev port status changes, the roce driver sends a port down event by parsing the netdev event dispatched by IB_CORE, which takes about a few hundred milliseconds. But,it is not fast enough for ULP sometimes. The HNS NIC driver can directly notify the ROCE driver send port event via callback function, this takes only a few milliseconds. This patch implements this callback function. Signed-off-by: NLang Cheng <chenglang@huawei.com> Signed-off-by: NChengchang Tang <tangchengchang@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lang Cheng 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Z2DS ---------------------------------------------------------- Driver can notify ulp with IB event when net link down/up. Signed-off-by: NLang Cheng <chenglang@huawei.com> Signed-off-by: NChengchang Tang <tangchengchang@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Chengchang Tang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Z2HJ ---------------------------------------------------------- Currently, we have dumped some fields in the QP/CQ/MR resource. This information is not enough. It is very inconvenient to continue to expand on the current field, and it will also introduce some trouble to parse this raw data. This patch dump whole resource in raw to avoid the above problems. Signed-off-by: NChengchang Tang <tangchengchang@huawei.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiangshui Yang 提交于
yangjiangshui inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5XYPG CVE: NA ---------------------------------------------------------------------- The sm4-ccm and sm4-gcm algorithms of the sec module depend on the fallback TFM function. Therefore, the sm4_generic module of the crypto subsystem needs to be loaded. Signed-off-by: NJiangshui Yang <yangjiangshui@h-partners.com> Reviewed-by: NKai Ye <yekai13@huawei.com> Reviewed-by: NChao Liu <liuchao173@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Shixin 提交于
maillist inclusion category: bugfix bugzilla: 187198, https://gitee.com/openeuler/kernel/issues/I5NX1S Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20220823&id=f5606044e659f8fa754fa692e2fa5aea1ec7f2f6 -------------------------------- The vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reuse the page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: Link: https://lkml.kernel.org/r/20220819094005.2928241-1-liushixin2@huawei.com Fixes: f41f2ed4 (mm: hugetlb: free the vmemmap pages associated with each HugeTLB page) Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NMuchun Song <songmuchun@bytedance.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kefeng Wang 提交于
hulk inclusion category: bugfix bugzilla: 187483, https://gitee.com/openeuler/kernel/issues/I5MH9N CVE: NA -------------------------------- When support memmap=nn[KMG]$ss[KMG], it will request resource to show reserved memory in iomem, but with memblock_setclr_flag() called memblock_mark_memmap() leads to split memblock region and then request_resource() could return -EBUSY when passed unaligned address. Let's directly use memblock_reserve() and drop membloc_setclr_flag() and show error if request_resource() in request_memmap_resource() return error code. Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Duoming Zhou 提交于
stable inclusion from stable-v5.10.138 commit a0ae122e9aeccbff75014c4d36d11a9d32e7fb5e category: bugfix bugzilla: 187909, https://gitee.com/src-openeuler/kernel/issues/I5X3ML CVE: CVE-2022-3635 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a0ae122e9aeccbff75014c4d36d11a9d32e7fb5e -------------------------------- commit 3f4093e2 upstream. There are use-after-free bugs caused by tst_timer. The root cause is that there are no functions to stop tst_timer in idt77252_exit(). One of the possible race conditions is shown below: (thread 1) | (thread 2) | idt77252_init_one | init_card | fill_tst | mod_timer(&card->tst_timer, ...) idt77252_exit | (wait a time) | tst_timer | | ... kfree(card) // FREE | | card->soft_tst[e] // USE The idt77252_dev is deallocated in idt77252_exit() and used in timer handler. This patch adds del_timer_sync() in idt77252_exit() in order that the timer handler could be stopped before the idt77252_dev is deallocated. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by: NDuoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220805070008.18007-1-duoming@zju.edu.cnSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dongliang Mu 提交于
mainline inclusion from mainline-v6.1-rc1 commit 2e488f13 category: bugfix bugzilla: 187543, https://gitee.com/src-openeuler/kernel/issues/I5NZ98 CVE: CVE-2022-2978 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1-rc3&id=2e488f13755ffbb60f307e991b27024716a33b29 ------------------------------- In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) Link: https://lkml.kernel.org/r/CAFcO6XOcf1Jj2SeGt=jJV59wmhESeSKpfR0omdFRq+J9nD1vfQ@mail.gmail.comReported-by: Nbutt3rflyh4ck <butterflyhuangxx@gmail.com> Reported-by: NHao Sun <sunhao.th@gmail.com> Reported-by: NJiacheng Xu <stitch@zju.edu.cn> Reviewed-by: NChristian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: NDongliang Mu <mudongliangabcd@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: stable@vger.kernel.org Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dokyung Song 提交于
maillist inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5YGD6 CVE: CVE-2022-3628 Reference: https://patchwork.kernel.org/project/linux-wireless/patch/20221021061359.GA550858@laguna/ -------------------------------- This patch fixes an intra-object buffer overflow in brcmfmac that occurs when the device provides a 'bsscfgidx' equal to or greater than the buffer size. The patch adds a check that leads to a safe failure if that is the case. This fixes CVE-2022-3628. UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c index 52 is out of range for type 'brcmf_if *[16]' CPU: 0 PID: 1898 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: events brcmf_fweh_event_worker Call Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds+0x69/0x80 ? memcpy+0x39/0x60 brcmf_fweh_event_worker+0xae1/0xc00 ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? process_one_work+0x13e0/0x13e0 kthread+0x379/0x450 ? _raw_spin_unlock_irq+0x24/0x30 ? set_kthread_struct+0x100/0x100 ret_from_fork+0x1f/0x30 ================================================================================ general protection fault, probably for non-canonical address 0xe5601c0020023fff: 0000 [#1] SMP KASAN KASAN: maybe wild-memory-access in range [0x2b0100010011fff8-0x2b0100010011ffff] CPU: 0 PID: 1898 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: events brcmf_fweh_event_worker RIP: 0010:brcmf_fweh_call_event_handler.isra.0+0x42/0x100 Code: 89 f5 53 48 89 fb 48 83 ec 08 e8 79 0b 38 fe 48 85 ed 74 7e e8 6f 0b 38 fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 8b 00 00 00 4c 8b 7d 00 44 89 e0 48 ba 00 00 00 RSP: 0018:ffffc9000259fbd8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: ffff888115d8cd50 RCX: 0000000000000000 RDX: 0560200020023fff RSI: ffffffff8304bc91 RDI: ffff888115d8cd50 RBP: 2b0100010011ffff R08: ffff888112340050 R09: ffffed1023549809 R10: ffff88811aa4c047 R11: ffffed1023549808 R12: 0000000000000045 R13: ffffc9000259fca0 R14: ffff888112340050 R15: ffff888112340000 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004053ccc0 CR3: 0000000112740000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: brcmf_fweh_event_worker+0x117/0xc00 ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? process_one_work+0x13e0/0x13e0 kthread+0x379/0x450 ? _raw_spin_unlock_irq+0x24/0x30 ? set_kthread_struct+0x100/0x100 ret_from_fork+0x1f/0x30 Modules linked in: 88XXau(O) 88x2bu(O) ---[ end trace 41d302138f3ff55a ]--- RIP: 0010:brcmf_fweh_call_event_handler.isra.0+0x42/0x100 Code: 89 f5 53 48 89 fb 48 83 ec 08 e8 79 0b 38 fe 48 85 ed 74 7e e8 6f 0b 38 fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 8b 00 00 00 4c 8b 7d 00 44 89 e0 48 ba 00 00 00 RSP: 0018:ffffc9000259fbd8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: ffff888115d8cd50 RCX: 0000000000000000 RDX: 0560200020023fff RSI: ffffffff8304bc91 RDI: ffff888115d8cd50 RBP: 2b0100010011ffff R08: ffff888112340050 R09: ffffed1023549809 R10: ffff88811aa4c047 R11: ffffed1023549808 R12: 0000000000000045 R13: ffffc9000259fca0 R14: ffff888112340050 R15: ffff888112340000 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004053ccc0 CR3: 0000000112740000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Reported-by: NDokyung Song <dokyungs@yonsei.ac.kr> Reported-by: NJisoo Jang <jisoo.jang@yonsei.ac.kr> Reported-by: NMinsuk Kang <linuxlovemin@yonsei.ac.kr> Reviewed-by: NArend van Spriel <aspriel@gmail.com> Signed-off-by: NDokyung Song <dokyung.song@gmail.com> Signed-off-by: NLiu Jian <liujian56@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ryusuke Konishi 提交于
mainline inclusion from mainline-v6.0-rc3 commit 21a87d88 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5X1Z4 CVE: CVE-2022-3621 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=21a87d88c2253350e115029f14fe2a10a7e6c856 -------------------------------- If the i_mode field in inode of metadata files is corrupted on disk, it can cause the initialization of bmap structure, which should have been called from nilfs_read_inode_common(), not to be called. This causes a lockdep warning followed by a NULL pointer dereference at nilfs_bmap_lookup_at_level(). This patch fixes these issues by adding a missing sanitiy check for the i_mode field of metadata file's inode. Link: https://lkml.kernel.org/r/20221002030804.29978-1-konishi.ryusuke@gmail.comSigned-off-by: NRyusuke Konishi <konishi.ryusuke@gmail.com> Reported-by: syzbot+2b32eb36c1a825b7a74c@syzkaller.appspotmail.com Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: NRyusuke Konishi <konishi.ryusuke@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> 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: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Baolin Wang 提交于
mainline inclusion from mainline-v6.1-rc1 commit fac35ba7 category: bugfix bugzilla: 187864, https://gitee.com/src-openeuler/kernel/issues/I5X1Z9 CVE: CVE-2022-3623 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f -------------------------------- On some architectures (like ARM64), it can support CONT-PTE/PMD size hugetlb, which means it can support not only PMD/PUD size hugetlb (2M and 1G), but also CONT-PTE/PMD size(64K and 32M) if a 4K page size specified. So when looking up a CONT-PTE size hugetlb page by follow_page(), it will use pte_offset_map_lock() to get the pte entry lock for the CONT-PTE size hugetlb in follow_page_pte(). However this pte entry lock is incorrect for the CONT-PTE size hugetlb, since we should use huge_pte_lock() to get the correct lock, which is mm->page_table_lock. That means the pte entry of the CONT-PTE size hugetlb under current pte lock is unstable in follow_page_pte(), we can continue to migrate or poison the pte entry of the CONT-PTE size hugetlb, which can cause some potential race issues, even though they are under the 'pte lock'. For example, suppose thread A is trying to look up a CONT-PTE size hugetlb page by move_pages() syscall under the lock, however antoher thread B can migrate the CONT-PTE hugetlb page at the same time, which will cause thread A to get an incorrect page, if thread A also wants to do page migration, then data inconsistency error occurs. Moreover we have the same issue for CONT-PMD size hugetlb in follow_huge_pmd(). To fix above issues, rename the follow_huge_pmd() as follow_huge_pmd_pte() to handle PMD and PTE level size hugetlb, which uses huge_pte_lock() to get the correct pte entry lock to make the pte entry stable. Mike said: Support for CONT_PMD/_PTE was added with bb9dd3df ("arm64: hugetlb: refactor find_num_contig()"). Patch series "Support for contiguous pte hugepages", v4. However, I do not believe these code paths were executed until migration support was added with 5480280d ("arm64/mm: enable HugeTLB migration for contiguous bit HugeTLB pages") I would go with 5480280d for the Fixes: targe. Link: https://lkml.kernel.org/r/635f43bdd85ac2615a58405da82b4d33c6e5eb05.1662017562.git.baolin.wang@linux.alibaba.com Fixes: 5480280d ("arm64/mm: enable HugeTLB migration for contiguous bit HugeTLB pages") Signed-off-by: NBaolin Wang <baolin.wang@linux.alibaba.com> Suggested-by: NMike Kravetz <mike.kravetz@oracle.com> Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com> Cc: David Hildenbrand <david@redhat.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: mm/hugetlb.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tadeusz Struk 提交于
stable inclusion from stable-v5.10.148 commit 1b257f97fec43d7a8a4c9ada8538d14421861b0a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5XTU4 CVE: CVE-2022-43750 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1b257f97fec43d7a8a4c9ada8538d14421861b0a -------------------------------- commit a659daf6 upstream. Syzbot found an issue in usbmon module, where the user space client can corrupt the monitor's internal memory, causing the usbmon module to crash the kernel with segfault, UAF, etc. The reproducer mmaps the /dev/usbmon memory to user space, and overwrites it with arbitrary data, which causes all kinds of issues. Return an -EPERM error from mon_bin_mmap() if the flag VM_WRTIE is set. Also clear VM_MAYWRITE to make it impossible to change it to writable later. Cc: "Dmitry Vyukov" <dvyukov@google.com> Cc: stable <stable@kernel.org> Fixes: 6f23ee1f ("USB: add binary API to usbmon") Suggested-by: PaX Team <pageexec@freemail.hu> # for the VM_MAYRITE portion Link: https://syzkaller.appspot.com/bug?id=2eb1f35d6525fa4a74d75b4244971e5b1411c95a Reported-by: syzbot+23f57c5ae902429285d7@syzkaller.appspotmail.com Signed-off-by: NTadeusz Struk <tadeusz.struk@linaro.org> Link: https://lore.kernel.org/r/20220919215957.205681-1-tadeusz.struk@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com> Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 David Jeffery 提交于
mainline inclusion from mainline-v5.18-rc1 commit 8f5fea65 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5YREM CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?8f5fea65b06de1cc51d4fc23fb4d378d1abd6ed7 -------------------------------- When blk_mq_delay_run_hw_queues sets an hctx to run in the future, it can reset the delay length for an already pending delayed work run_work. This creates a scenario where multiple hctx may have their queues set to run, but if one runs first and finds nothing to do, it can reset the delay of another hctx and stall the other hctx's ability to run requests. To avoid this I/O stall when an hctx's run_work is already pending, leave it untouched to run at its current designated time rather than extending its delay. The work will still run which keeps closed the race calling blk_mq_delay_run_hw_queues is needed for while also avoiding the I/O stall. Signed-off-by: NDavid Jeffery <djeffery@redhat.com> Reviewed-by: NMing Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20220131203337.GA17666@redhatSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5YRAC CVE: NA -------------------------------- This reverts commit 84f7a9de. Because it introduces a problem that rq->__data_len is set to the wrong value. before the patch: 1) nr_bytes = rq->__data_len 2) rq->__data_len = sdp->sector_size 3) scsi_init_io() 4) rq->__data_len = nr_bytes after the patch: 1) rq->__data_len = sdp->sector_size 2) scsi_init_io() 3) rq->__data_len = rq->__data_len -> __data_len is wrong It will cause that io can only complete one segment each time, and the io will requeue in scsi_io_completion_action(), which will cause severe performance degradation. Scsi write same is removed in commit e383e16e ("scsi: sd: Remove WRITE_SAME support") from mainline, hence this patch is only needed for stable kernels. Fixes: 84f7a9de ("scsi: sd: Remove a local variable") Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NBart Van Assche <bvanassche@acm.org> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ido Schimmel 提交于
stable inclusion from stable-v5.10.138 commit 0e28678a770df7989108327cfe86f835d8760c33 category: bugfix bugzilla: 187888 CVE: CVE-2022-3625 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0e28678a770df7989108327cfe86f835d8760c33 -------------------------------- commit 6b4db2e5 upstream. After a failed devlink reload, devlink parameters are still registered, which means user space can set and get their values. In the case of the mlxsw "acl_region_rehash_interval" parameter, these operations will trigger a use-after-free [1]. Fix this by rejecting set and get operations while in the failed state. Return the "-EOPNOTSUPP" error code which does not abort the parameters dump, but instead causes it to skip over the problematic parameter. Another possible fix is to perform these checks in the mlxsw parameter callbacks, but other drivers might be affected by the same problem and I am not aware of scenarios where these stricter checks will cause a regression. [1] mlxsw_spectrum3 0000:00:10.0: Port 125: Failed to register netdev mlxsw_spectrum3 0000:00:10.0: Failed to create ports ================================================================== BUG: KASAN: use-after-free in mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904 Read of size 4 at addr ffff8880099dcfd8 by task kworker/u4:4/777 CPU: 1 PID: 777 Comm: kworker/u4:4 Not tainted 5.19.0-rc7-custom-126601-gfe26f28c586d #1 Hardware name: QEMU MSN4700, BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x92/0xbd lib/dump_stack.c:106 print_address_description mm/kasan/report.c:313 [inline] print_report.cold+0x5e/0x5cf mm/kasan/report.c:429 kasan_report+0xb9/0xf0 mm/kasan/report.c:491 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report_generic.c:306 mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904 mlxsw_sp_acl_region_rehash_intrvl_get+0x49/0x60 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c:1106 mlxsw_sp_params_acl_region_rehash_intrvl_get+0x33/0x80 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3854 devlink_param_get net/core/devlink.c:4981 [inline] devlink_nl_param_fill+0x238/0x12d0 net/core/devlink.c:5089 devlink_param_notify+0xe5/0x230 net/core/devlink.c:5168 devlink_ns_change_notify net/core/devlink.c:4417 [inline] devlink_ns_change_notify net/core/devlink.c:4396 [inline] devlink_reload+0x15f/0x700 net/core/devlink.c:4507 devlink_pernet_pre_exit+0x112/0x1d0 net/core/devlink.c:12272 ops_pre_exit_list net/core/net_namespace.c:152 [inline] cleanup_net+0x494/0xc00 net/core/net_namespace.c:582 process_one_work+0x9fc/0x1710 kernel/workqueue.c:2289 worker_thread+0x675/0x10b0 kernel/workqueue.c:2436 kthread+0x30c/0x3d0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> The buggy address belongs to the physical page: page:ffffea0000267700 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99dc flags: 0x100000000000000(node=0|zone=1) raw: 0100000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099dce80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8880099dcf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff8880099dcf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff8880099dd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8880099dd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Fixes: 98bbf70c ("mlxsw: spectrum: add "acl_region_rehash_interval" devlink param") Signed-off-by: NIdo Schimmel <idosch@nvidia.com> Reviewed-by: NJiri Pirko <jiri@nvidia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alistair Popple 提交于
mainline inclusion from mainline-v6.1-rc2 commit 97061d44 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5VZ0L Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97061d441110528dc02972818f2f1dad485107f9 -------------------------------- Commit 16ce101d ("mm/memory.c: fix race when faulting a device private page") changed the migrate_to_ram() callback to take a reference on the device page to ensure it can't be freed while handling the fault. Unfortunately the corresponding update to Nouveau to accommodate this change was inadvertently dropped from that patch causing GPU to CPU migration to fail so add it here. Link: https://lkml.kernel.org/r/20221019122934.866205-1-apopple@nvidia.com Fixes: 16ce101d ("mm/memory.c: fix race when faulting a device private page") Signed-off-by: NAlistair Popple <apopple@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alistair Popple 提交于
mainline inclusion from mainline-v6.1-rc1 commit 16ce101d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5VZ0L CVE: CVE-2022-3523 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16ce101db85db694a91380aa4c89b25530871d33 -------------------------------- Patch series "Fix several device private page reference counting issues", v2 This series aims to fix a number of page reference counting issues in drivers dealing with device private ZONE_DEVICE pages. These result in use-after-free type bugs, either from accessing a struct page which no longer exists because it has been removed or accessing fields within the struct page which are no longer valid because the page has been freed. During normal usage it is unlikely these will cause any problems. However without these fixes it is possible to crash the kernel from userspace. These crashes can be triggered either by unloading the kernel module or unbinding the device from the driver prior to a userspace task exiting. In modules such as Nouveau it is also possible to trigger some of these issues by explicitly closing the device file-descriptor prior to the task exiting and then accessing device private memory. This involves some minor changes to both PowerPC and AMD GPU code. Unfortunately I lack hardware to test either of those so any help there would be appreciated. The changes mimic what is done in for both Nouveau and hmm-tests though so I doubt they will cause problems. This patch (of 8): When the CPU tries to access a device private page the migrate_to_ram() callback associated with the pgmap for the page is called. However no reference is taken on the faulting page. Therefore a concurrent migration of the device private page can free the page and possibly the underlying pgmap. This results in a race which can crash the kernel due to the migrate_to_ram() function pointer becoming invalid. It also means drivers can't reliably read the zone_device_data field because the page may have been freed with memunmap_pages(). Close the race by getting a reference on the page while holding the ptl to ensure it has not been freed. Unfortunately the elevated reference count will cause the migration required to handle the fault to fail. To avoid this failure pass the faulting page into the migrate_vma functions so that if an elevated reference count is found it can be checked to see if it's expected or not. [mpe@ellerman.id.au: fix build] Link: https://lkml.kernel.org/r/87fsgbf3gh.fsf@mpe.ellerman.id.au Link: https://lkml.kernel.org/r/cover.60659b549d8509ddecafad4f498ee7f03bb23c69.1664366292.git-series.apopple@nvidia.com Link: https://lkml.kernel.org/r/d3e813178a59e565e8d78d9b9a4e2562f6494f90.1664366292.git-series.apopple@nvidia.comSigned-off-by: NAlistair Popple <apopple@nvidia.com> Acked-by: NFelix Kuehling <Felix.Kuehling@amd.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Lyude Paul <lyude@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Alex Sierra <alex.sierra@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Christian König <christian.koenig@amd.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: "Huang, Ying" <ying.huang@intel.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Yang Shi <shy828301@gmail.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: arch/powerpc/kvm/book3s_hv_uvmem.c include/linux/migrate.h lib/test_hmm.c mm/migrate.c Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-