- Apr 07, 2021
-
-
LeoLiu-oc authored
mainline inclusion from mainline-5.9 commit 8687bdc0 category: x86/cpu bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ---------------------------------------------------------------- Use a normal if statements instead of a two-condition switch-case. [ bp: Massage commit message. ] Signed-off-by:
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/1599562666-31351-2-git-send-email-TonyWWang-oc@zhaoxin.com Signed-off-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
LeoLiu-oc authored
mainline inclusion from mainline-5.6 commit 283bab98 category: x86/cpu bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ---------------------------------------------------------------- Both functions call init_intel_cacheinfo() which computes L2 and L3 cache sizes from CPUID(4). But then they also call cpu_detect_cache_sizes() a bit later which computes ->x86_tlbsize and L2 size from CPUID(80000006). However, the latter call is not needed because - on these CPUs, CPUID(80000006).EBX for ->x86_tlbsize is reserved - CPUID(80000006).ECX for the L2 size has the same result as CPUID(4) Therefore, remove the latter call to simplify the code. [ bp: Rewrite commit message. ] Signed-off-by:
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/1579075257-6985-1-git-send-email-TonyWWang-oc@zhaoxin . Signed-off-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
LeoLiu-oc authored
mainline inclusion from mainline-5.2 commit 761fdd5e category: x86/cpu bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ---------------------------------------------------------------- Add x86 architecture support for new Zhaoxin processors. Carve out initialization code needed by Zhaoxin processors into a separate compilation unit. To identify Zhaoxin CPU, add a new vendor type X86_VENDOR_ZHAOXIN for system recognition. Signed-off-by:
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: "hpa@zytor.com" <hpa@zytor.com> Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> Cc: "rjw@rjwysocki.net" <rjw@rjwysocki.net> Cc: "lenb@kernel.org" <lenb@kernel.org> Cc: David Wang <DavidWang@zhaoxin.com> Cc: "Cooper Yan(BJ-RD)" <CooperYan@zhaoxin.com> Cc: "Qiyuan Wang(BJ-RD)" <QiyuanWang@zhaoxin.com> Cc: "Herry Yang(BJ-RD)" <HerryYang@zhaoxin.com> Link: https://lkml.kernel.org/r/01042674b2f741b2aed1f797359bdffb@zhaoxin.com Signed-off-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Mathias Nyman authored
mainline inclusion from mainline-5.6.rc3 commit a3ae87dc category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ----------------------------------------------------------- commit a3ae87dc upstream. Intel Comet Lake based platform require the XHCI_PME_STUCK_QUIRK quirk as well. Without this xHC can not enter D3 in runtime suspend. Cc: stable@vger.kernel.org Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200210134553.9144-5-mathias.nyman@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Mathias Nyman authored
mainline inclusion from mainline-5.6.rc3 commit cf0ee7c6 category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ----------------------------------------------------------- commit cf0ee7c6 upstream. xhci driver assumed that xHC controllers have at most one custom supported speed table (PSI) for all usb 3.x ports. Memory was allocated for one PSI table under the xhci hub structure. Turns out this is not the case, some controllers have a separate "supported protocol capability" entry with a PSI table for each port. This means each usb3 roothub port can in theory support different custom speeds. To solve this, cache all supported protocol capabilities with their PSI tables in an array, and add pointers to the xhci port structure so that every port points to its capability entry in the array. When creating the SuperSpeedPlus USB Device Capability BOS descriptor for the xhci USB 3.1 roothub we for now will use only data from the first USB 3.1 capable protocol capability entry in the array. This could be improved later, this patch focuses resolving the memory leak. Reported-by:
Paul Menzel <pmenzel@molgen.mpg.de> Reported-by:
Sajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com> Fixes: 47189098 ("xhci: parse xhci protocol speed ID list for usb 3.1 usage") Cc: stable <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200211150158.14475-1-mathias.nyman@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Mathias Nyman authored
mainline inclusion from mainline-5.6.9 commit 024d411e category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ----------------------------------------------------------- commit 024d411e upstream. Intel hosts that need the XHCI_PME_STUCK_QUIRK flag should enable runtime pm by calling xhci_pme_acpi_rtd3_enable() before usb_hcd_pci_probe() calls pci_dev_run_wake(). Otherwise usage count for the device won't be decreased, and runtime suspend is prevented. usb_hcd_pci_probe() only decreases the usage count if device can generate run-time wake-up events, i.e. when pci_dev_run_wake() returns true. This issue was exposed by pci_dev_run_wake() change in commit 8feaec33 ("PCI / PM: Always check PME wakeup capability for runtime wakeup support") and should be backported to kernels with that change Cc: <stable@vger.kernel.org> # 4.13+ Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200210134553.9144-4-mathias.nyman@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Mathias Nyman authored
mainline inclusion from mainline-5.6-rc3 commit f148b9f4 category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=19 CVE: NA ----------------------------------------------------------- commit f148b9f4 upstream. A Full-speed bulk USB audio device (DJ-Tech CTRL) with a invalid Maximum Packet Size of 4 causes a xHC "Parameter Error" at enumeration. This is because valid Maximum packet sizes for Full-speed bulk endpoints are 8, 16, 32 and 64 bytes. Hosts are not required to support other values than these. See usb 2 specs section 5.8.3 for details. The device starts working after forcing the maximum packet size to 8. This is most likely the case with other devices as well, so force the maximum packet size to a valid range. Cc: stable@vger.kernel.org Reported-by:
Rene D Obermueller <cmdrrdo@gmail.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200210134553.9144-2-mathias.nyman@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
LeoLiu-oc <LeoLiu-oc@zhaoxin.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
- Apr 01, 2021
-
-
Yang Yingliang authored
driver inclusion category: feature bugzilla: 34535 CVE: NA Make CONFIG_BMA=m, except euleros_defconfig. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Naixin Yu authored
driver inclusion category: feature bugzilla: 34535 CVE: NA The BMA software is a system management software offered by Huawei. It supports the status monitoring, performance monitoring, and event monitoring of various components, including server CPUs, memory, hard disks, NICs, IB cards, PCIe cards, RAID controller cards, and optical modules. The host_kbox_drv driver serves the function of a black box. When a panic or mce event happen to the system, it will record the event time, system's status and system logs and send them to BMC before the OS shutdown. This driver depends on the host_edms_drv driver. Link: https://lkml.org/lkml/2020/6/22/752 Signed-off-by:
Naixin Yu <yunaixin@huawei.com> Reviewed-by:
Wang Qindong <wangqindong@huawei.com> Acked-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Naixin Yu authored
driver inclusion category: feature bugzilla: 34535 CVE: NA The BMA software is a system management software offered by Huawei. It supports the status monitoring, performance monitoring, and event monitoring of various components, including server CPUs, memory, hard disks, NICs, IB cards, PCIe cards, RAID controller cards, and optical modules. This cdev_veth_drv driver is one of the communication drivers used by BMA software. It depends on the host_edma_drv driver. It will create a char device once loaded, offering interfaces (open, close, read, write and poll) to BMA to send/receive RESTful messages between BMC software. When the message is longer than 1KB, it will be cut into packets of 1KB. The other side, BMC's cdev_veth driver, will assemble these packets back into original mesages. Link: https://lkml.org/lkml/2020/6/22/752 Signed-off-by:
Naixin Yu <yunaixin@huawei.com> Reviewed-by:
Wang Qindong <wangqindong@huawei.com> Acked-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Naixin Yu authored
driver inclusion category: feature bugzilla: 34535 CVE: NA The BMA software is a system management software offered by Huawei. It supports the status monitoring, performance monitoring, and event monitoring of various components, including server CPUs, memory, hard disks, NICs, IB cards, PCIe cards, RAID controller cards, and optical modules. This host_veth_drv driver is one of the communication drivers used by BMA software. It depends on the host_edma_drv driver. The host_veth_drv driver will create a virtual net device "veth" once loaded. BMA software will use it to send/receive RESTful messages to/from BMC software. Link: https://lkml.org/lkml/2020/6/22/752 Signed-off-by:
Naixin Yu <yunaixin@huawei.com> Reviewed-by:
Wang Qindong <wangqindong@huawei.com> Acked-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Naixin Yu authored
driver inclusion category: feature bugzilla: 34535 CVE: NA The BMA software is a system management software offered by Huawei. It supports the status monitoring, performance monitoring, and event monitoring of various components, including server CPUs, memory, hard disks, NICs, IB cards, PCIe cards, RAID controller cards, and optical modules. This host_cdev_drv driver is one of the communication driver used by BMA software. It depends on the host_edma_drv driver. The host_cdev_drv driver will create 4 char devices(hwbmc0, hwbmc1, hwbmc2, hwbmc3) once loaded. These char devices offer interfaces, including open, close, read, write and poll, to upper level applications. BMA uses them to send/receive ipmi commons to/from BMC. Link: https://lkml.org/lkml/2020/6/22/752 Signed-off-by:
Naixin Yu <yunaixin@huawei.com> Reviewed-by:
Wang Qindong <wangqindong@huawei.com> Acked-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Naixin Yu authored
driver inclusion category: feature bugzilla: 34535 CVE: NA The BMA software is a system management software offered by Huawei. It supports the status monitoring, performance monitoring, and event monitoring of various components, including server CPUs, memory, hard disks, NICs, IB cards, PCIe cards, RAID controller cards, and optical modules. This host_edma_drv driver is a PCIe driver used by Huawei BMA software. The main function of it is to control the PCIe bus between BMA software and Huawei 1711 chip. The chip will then process the data and display to users. This host_edma_drv driver offers API to send/receive data for other BMA drivers which want to use the PCIe channel in different ways(eg.host_cdev_drv, host_veth_drv). Link: https://lkml.org/lkml/2020/6/22/752 Signed-off-by:
Naixin Yu <yunaixin@huawei.com> Reviewed-by:
Wang Qindong <wangqindong@huawei.com> Acked-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Ding Hui authored
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I3BNT6 CVE: NA ----------------------------------------------- We can get a crash when disconnecting the iSCSI session, the call trace like this: [ffff00002a00fb70] kfree at ffff00000830e224 [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 [ffff00002a00fbd0] device_del at ffff0000086b6a98 [ffff00002a00fc50] device_unregister at ffff0000086b6d58 [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c [ffff00002a00fca0] scsi_remove_device at ffff000008706134 [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 [ffff00002a00fdb0] process_one_work at ffff00000810f35c [ffff00002a00fe00] worker_thread at ffff00000810f648 [ffff00002a00fe70] kthread at ffff000008116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process Another fix option is report error and do not attach in ses_intf_add if we meet a zero component enclosure Tested-by:
Zeng Zhicong <timmyzeng@163.com> Signed-off-by:
Ding Hui <dinghui@sangfor.com.cn> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Guangbin Huang authored
driver inclusion category: feature bugzilla: NA CVE: NA ---------------------------- Previously, VF updates its link status every second by send query command to PF in periodic service task. If link stats of PF is changed, VF may need at most one second to update its link status. To reduce delay of link status between PF and VFs, PF actively push its link status to VFs when its link status is updated. And to let VF know PF supports this new feature, the link status changed mailbox command Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Yonglong Liu authored
driver inclusion category: bugfix bugzilla: NA CVE: NA ----------------------------- This patch update hns version to 21.2.1 and make driver version the same as module version. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
YueHaibing authored
mainline inclusion from mainline-5.10-rc1 commit 26613a95 category: bugfix bugzilla: NA CVE: NA --------------------------- There is no caller in tree. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Barry Song authored
mainline inclusion from mainline-5.10-rc1 commit 5a6bd84f category: bugfix bugzilla: NA CVE: NA --------------------------- Rather than doing request_irq and then disabling the irq immediately, it should be safer to use IRQ_NOAUTOEN flag for the irq. It removes any gap between request_irq() and disable_irq(). Cc: Salil Mehta <salil.mehta@huawei.com> Reviewed-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
Barry Song <song.bao.hua@hisilicon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Gustavo A. R. Silva authored
mainline inclusion from mainline-5.7-rc1 commit c5d6cf90 category: bugfix bugzilla: NA CVE: NA --------------------------- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Zheng Yongjun authored
mainline inclusion from mainline-5.11-rc1 commit 3d4068b24cd947ca4e3fd7f4f2a34fa1bc229202 category: bugfix bugzilla: NA CVE: NA --------------------------- Replace a comma between expression statements by a semicolon. Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Colin Ian King authored
mainline inclusion from mainline-5.5-rc1 commit 99d89572 category: bugfix bugzilla: NA CVE: NA --------------------------- Don't populate the arrays port_map and sl_map on the stack but instead make them static. Makes the object code smaller by 64 bytes. Before: text data bss dec hex filename 49575 6872 64 56511 dcbf hisilicon/hns/hns_dsaf_main.o After: text data bss dec hex filename 49350 7032 64 56446 dc7e hisilicon/hns/hns_dsaf_main.o (gcc version 9.2.1, amd64) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Krzysztof Wilczynski authored
mainline inclusion from mainline-5.4-rc1 commit 5e5d8bc4 category: bugfix bugzilla: NA CVE: NA --------------------------- Move the static keyword to the front of declaration of g_dsaf_mode_match, and resolve the following compiler warning that can be seen when building with warnings enabled (W=1): drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:27:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] Signed-off-by:
Krzysztof Wilczynski <kw@linux.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Xu Wang authored
mainline inclusion from mainline-5.9-rc1 commit 74b5afea category: bugfix bugzilla: NA CVE: NA --------------------------- This patch is to use eth_broadcast_addr() to assign broadcast address insetad of memset(). Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Jason Yan authored
mainline inclusion from mainline-5.8-rc1 commit 6d927977 category: bugfix bugzilla: NA CVE: NA --------------------------- Fix the following coccicheck warning: drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:700:2-8: WARNING: Assignment of 0/1 to bool variable drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:702:2-8: WARNING: Assignment of 0/1 to bool variable Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Yonglong Liu authored
driver inclusion category: bugfix bugzilla: NA CVE: NA ----------------------------- The "Advertised link modes" always shows "1000baseT/Full", because the driver only assigned this value. Function ethtool_convert_link_mode_to_legacy_u32() should be called after function phy_ethtool_ksettings_get() to get the current value of the phy. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Yonglong Liu authored
driver inclusion category: bugfix bugzilla: NA CVE: NA ----------------------------- When setting "autoneg off speed 100 duplex half", ping will failed. This patch turn off the autoneg mode of mac to fix the problem. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Tom Rix authored
mainline inclusion from mainline-v5.11-rc5 commit 99d518970c5a1901e83cdd4a0a6ff5a41ba56a56 category: bugfix bugzilla: NA CVE: NA ---------------------------- When DEBUG is defined this error occurs drivers/net/ethernet/hisilicon/hns/hns_enet.c:1505:36: error: ‘struct net_device’ has no member named ‘ae_handle’; did you mean ‘rx_handler’? assert(skb->queue_mapping < ndev->ae_handle->q_num); ^~~~~~~~~ ae_handle is an element of struct hns_nic_priv, so change ndev to priv. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20210117191044.533725-1-trix@redhat.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Yonglong Liu authored
driver inclusion category: bugfix bugzilla: NA CVE: NA ---------------------------- When disable promisc mode after enable promisc mode, the non-promiscuous mode does not take effect. The driver use the last 12 mac table for promisc mode(6 ports, each port have a mc vague mac table and a uc vague mac table). But when disabling promisc mode, the driver did not look for the last 12 vague mac table, cause this problem. Fixes: 421ccc3859d6 ("net: hns: fix ping failed when use net bridge and send multicast") Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Yonglong Liu authored
driver inclusion category: cleanup bugzilla: NA CVE: NA ---------------------------- Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Thomas Gleixner authored
mainline inclusion from mainline-5.2-rc3 commit 2874c5fd category: bugfix bugzilla: NA CVE: NA --------------------------- Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Reviewed-by:
li yongxin <liyongxin1@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Chiqijun authored
driver inclusion category: bugfix bugzilla: 4472 ----------------------------------------------------------------------- update hinic version to 2.3.2.18 Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Chiqijun authored
driver inclusion category: feature bugzilla: 4472 ----------------------------------------------------------------------- Add support for hinic PMD on VF Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Chiqijun authored
driver inclusion category: feature bugzilla: 4472 ----------------------------------------------------------------------- Add XDP support for pass and drop actions. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Chiqijun authored
driver inclusion category: feature bugzilla: 4472 ----------------------------------------------------------------------- Add the 'ethtool -K ethx rx-vlan-filter on/off' command to turn on/off the vlan filter. Signed-off-by:
Chiqijun <chiqijun@huawei.com> Reviewed-by:
Wangxiaoyun <cloud.wangxiaoyun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Wenwen Wang authored
mainline inclusion from mainline-5.4-rc1 commit cfddf9f4 category: bugfix bugzilla: 21612 CVE: NA --------------------------- In __break_lease(), the file lock 'new_fl' is allocated in lease_alloc(). However, it is not deallocated in the following execution if smp_load_acquire() fails, leading to a memory leak bug. To fix this issue, free 'new_fl' before returning the error. Signed-off-by:
Wenwen Wang <wenwen@cs.uga.edu> Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
zhangyi (F) <yi.zhang@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
- Mar 29, 2021
-
-
Liu Shixin authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I3CG47 CVE: NA ------------------------------------------------- Patch a222f341 ("mm: generalize putback scan functions") has combined move_active_pages_to_lru() and putback_inactive_pages() into single move_pages_to_lru(). But we didn't backport this patch so move_active_pages_to_lru() is still existed. When We moved mem_cgroup_uncharge() in 7ae88534 ("mm: move mem_cgroup_uncharge out of __page_cache_release()"), move_active_pages_to_lru() should be changed together. Fixes: 7ae88534 ("mm: move mem_cgroup_uncharge out of __page_cache_release()") Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Dan Carpenter authored
stable inclusion from linux-4.19.181 commit eda4378094de16090d74eacea3d8c10f7719ed25 CVE: CVE-2021-28660 -------------------------------- commit 74b6b20df8cfe90ada777d621b54c32e69e27cd7 upstream. This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->ssid[] array. Fixes: a2c60d42 ("staging: r8188eu: Add files for new driver - part 16") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/YEHymwsnHewzoam7@mwanda Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Tyrel Datwyler authored
stable inclusion from linux-4.19.183 commit f27a00f0d5b0646a52633e98f5fc3ef719004dcd CVE: CVE-2021-28972 -------------------------------- commit cc7a0bb058b85ea03db87169c60c7cfdd5d34678 upstream. Both add_slot_store() and remove_slot_store() try to fix up the drc_name copied from the store buffer by placing a NUL terminator at nbyte + 1 or in place of a '\n' if present. However, the static buffer that we copy the drc_name data into is not zeroed and can contain anything past the n-th byte. This is problematic if a '\n' byte appears in that buffer after nbytes and the string copied into the store buffer was not NUL terminated to start with as the strchr() search for a '\n' byte will mark this incorrectly as the end of the drc_name string resulting in a drc_name string that contains garbage data after the n-th byte. Additionally it will cause us to overwrite that '\n' byte on the stack with NUL, potentially corrupting data on the stack. The following debugging shows an example of the drmgr utility writing "PHB 4543" to the add_slot sysfs attribute, but add_slot_store() logging a corrupted string value. drmgr: drmgr: -c phb -a -s PHB 4543 -d 1 add_slot_store: drc_name = PHB 4543°|<82>!, rc = -19 Fix this by using strscpy() instead of memcpy() to ensure the string is NUL terminated when copied into the static drc_name buffer. Further, since the string is now NUL terminated the code only needs to change '\n' to '\0' when present. Cc: stable@vger.kernel.org Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> [mpe: Reformat change log and add mention of possible stack corruption] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210315214821.452959-1-tyreld@linux.ibm.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Kan Liang authored
stable inclusion from linux-4.19.183 commit b35214c541365c7dd7c9d5f44a02b0633a1cc83f CVE: CVE-2021-28971 -------------------------------- commit d88d05a9e0b6d9356e97129d4ff9942d765f46ea upstream. A repeatable crash can be triggered by the perf_fuzzer on some Haswell system. https://lore.kernel.org/lkml/7170d3b-c17f-1ded-52aa-cc6d9ae999f4@maine.edu/ For some old CPUs (HSW and earlier), the PEBS status in a PEBS record may be mistakenly set to 0. To minimize the impact of the defect, the commit was introduced to try to avoid dropping the PEBS record for some cases. It adds a check in the intel_pmu_drain_pebs_nhm(), and updates the local pebs_status accordingly. However, it doesn't correct the PEBS status in the PEBS record, which may trigger the crash, especially for the large PEBS. It's possible that all the PEBS records in a large PEBS have the PEBS status 0. If so, the first get_next_pebs_record_by_bit() in the __intel_pmu_pebs_event() returns NULL. The at = NULL. Since it's a large PEBS, the 'count' parameter must > 1. The second get_next_pebs_record_by_bit() will crash. Besides the local pebs_status, correct the PEBS status in the PEBS record as well. Fixes: 01330d72 ("perf/x86: Allow zero PEBS status with only single active event") Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Suggested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1615555298-140216-1-git-send-email-kan.liang@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Jian Cheng <cj.chengjian@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-
Filipe Manana authored
stable inclusion from linux-4.19.183 commit 12dc6889bcff1bc2921a1587afca55ca4091b73e CVE: CVE-2021-28964 -------------------------------- commit dbcc7d57bffc0c8cac9dac11bec548597d59a6a5 upstream. While resolving backreferences, as part of a logical ino ioctl call or fiemap, we can end up hitting a BUG_ON() when replaying tree mod log operations of a root, triggering a stack trace like the following: ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:1210! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 PID: 19054 Comm: crawl_335 Tainted: G W 5.11.0-2d11c0084b02-misc-next+ #89 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__tree_mod_log_rewind+0x3b1/0x3c0 Code: 05 48 8d 74 10 (...) RSP: 0018:ffffc90001eb70b8 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff88812344e400 RCX: ffffffffb28933b6 RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff88812344e42c RBP: ffffc90001eb7108 R08: 1ffff11020b60a20 R09: ffffed1020b60a20 R10: ffff888105b050f9 R11: ffffed1020b60a1f R12: 00000000000000ee R13: ffff8880195520c0 R14: ffff8881bc958500 R15: ffff88812344e42c FS: 00007fd1955e8700(0000) GS:ffff8881f5600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007efdb7928718 CR3: 000000010103a006 CR4: 0000000000170ee0 Call Trace: btrfs_search_old_slot+0x265/0x10d0 ? lock_acquired+0xbb/0x600 ? btrfs_search_slot+0x1090/0x1090 ? free_extent_buffer.part.61+0xd7/0x140 ? free_extent_buffer+0x13/0x20 resolve_indirect_refs+0x3e9/0xfc0 ? lock_downgrade+0x3d0/0x3d0 ? __kasan_check_read+0x11/0x20 ? add_prelim_ref.part.11+0x150/0x150 ? lock_downgrade+0x3d0/0x3d0 ? __kasan_check_read+0x11/0x20 ? lock_acquired+0xbb/0x600 ? __kasan_check_write+0x14/0x20 ? do_raw_spin_unlock+0xa8/0x140 ? rb_insert_color+0x30/0x360 ? prelim_ref_insert+0x12d/0x430 find_parent_nodes+0x5c3/0x1830 ? resolve_indirect_refs+0xfc0/0xfc0 ? lock_release+0xc8/0x620 ? fs_reclaim_acquire+0x67/0xf0 ? lock_acquire+0xc7/0x510 ? lock_downgrade+0x3d0/0x3d0 ? lockdep_hardirqs_on_prepare+0x160/0x210 ? lock_release+0xc8/0x620 ? fs_reclaim_acquire+0x67/0xf0 ? lock_acquire+0xc7/0x510 ? poison_range+0x38/0x40 ? unpoison_range+0x14/0x40 ? trace_hardirqs_on+0x55/0x120 btrfs_find_all_roots_safe+0x142/0x1e0 ? find_parent_nodes+0x1830/0x1830 ? btrfs_inode_flags_to_xflags+0x50/0x50 iterate_extent_inodes+0x20e/0x580 ? tree_backref_for_extent+0x230/0x230 ? lock_downgrade+0x3d0/0x3d0 ? read_extent_buffer+0xdd/0x110 ? lock_downgrade+0x3d0/0x3d0 ? __kasan_check_read+0x11/0x20 ? lock_acquired+0xbb/0x600 ? __kasan_check_write+0x14/0x20 ? _raw_spin_unlock+0x22/0x30 ? __kasan_check_write+0x14/0x20 iterate_inodes_from_logical+0x129/0x170 ? iterate_inodes_from_logical+0x129/0x170 ? btrfs_inode_flags_to_xflags+0x50/0x50 ? iterate_extent_inodes+0x580/0x580 ? __vmalloc_node+0x92/0xb0 ? init_data_container+0x34/0xb0 ? init_data_container+0x34/0xb0 ? kvmalloc_node+0x60/0x80 btrfs_ioctl_logical_to_ino+0x158/0x230 btrfs_ioctl+0x205e/0x4040 ? __might_sleep+0x71/0xe0 ? btrfs_ioctl_get_supported_features+0x30/0x30 ? getrusage+0x4b6/0x9c0 ? __kasan_check_read+0x11/0x20 ? lock_release+0xc8/0x620 ? __might_fault+0x64/0xd0 ? lock_acquire+0xc7/0x510 ? lock_downgrade+0x3d0/0x3d0 ? lockdep_hardirqs_on_prepare+0x210/0x210 ? lockdep_hardirqs_on_prepare+0x210/0x210 ? __kasan_check_read+0x11/0x20 ? do_vfs_ioctl+0xfc/0x9d0 ? ioctl_file_clone+0xe0/0xe0 ? lock_downgrade+0x3d0/0x3d0 ? lockdep_hardirqs_on_prepare+0x210/0x210 ? __kasan_check_read+0x11/0x20 ? lock_release+0xc8/0x620 ? __task_pid_nr_ns+0xd3/0x250 ? lock_acquire+0xc7/0x510 ? __fget_files+0x160/0x230 ? __fget_light+0xf2/0x110 __x64_sys_ioctl+0xc3/0x100 do_syscall_64+0x37/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fd1976e2427 Code: 00 00 90 48 8b 05 (...) RSP: 002b:00007fd1955e5cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fd1955e5f40 RCX: 00007fd1976e2427 RDX: 00007fd1955e5f48 RSI: 00000000c038943b RDI: 0000000000000004 RBP: 0000000001000000 R08: 0000000000000000 R09: 00007fd1955e6120 R10: 0000557835366b00 R11: 0000000000000246 R12: 0000000000000004 R13: 00007fd1955e5f48 R14: 00007fd1955e5f40 R15: 00007fd1955e5ef8 Modules linked in: ---[ end trace ec8931a1c36e57be ]--- (gdb) l *(__tree_mod_log_rewind+0x3b1) 0xffffffff81893521 is in __tree_mod_log_rewind (fs/btrfs/ctree.c:1210). 1205 * the modification. as we're going backwards, we do the 1206 * opposite of each operation here. 1207 */ 1208 switch (tm->op) { 1209 case MOD_LOG_KEY_REMOVE_WHILE_FREEING: 1210 BUG_ON(tm->slot < n); 1211 fallthrough; 1212 case MOD_LOG_KEY_REMOVE_WHILE_MOVING: 1213 case MOD_LOG_KEY_REMOVE: 1214 btrfs_set_node_key(eb, &tm->key, tm->slot); Here's what happens to hit that BUG_ON(): 1) We have one tree mod log user (through fiemap or the logical ino ioctl), with a sequence number of 1, so we have fs_info->tree_mod_seq == 1; 2) Another task is at ctree.c:balance_level() and we have eb X currently as the root of the tree, and we promote its single child, eb Y, as the new root. Then, at ctree.c:balance_level(), we call: tree_mod_log_insert_root(eb X, eb Y, 1); 3) At tree_mod_log_insert_root() we create tree mod log elements for each slot of eb X, of operation type MOD_LOG_KEY_REMOVE_WHILE_FREEING each with a ->logical pointing to ebX->start. These are placed in an array named tm_list. Lets assume there are N elements (N pointers in eb X); 4) Then, still at tree_mod_log_insert_root(), we create a tree mod log element of operation type MOD_LOG_ROOT_REPLACE, ->logical set to ebY->start, ->old_root.logical set to ebX->start, ->old_root.level set to the level of eb X and ->generation set to the generation of eb X; 5) Then tree_mod_log_insert_root() calls tree_mod_log_free_eb() with tm_list as argument. After that, tree_mod_log_free_eb() calls __tree_mod_log_insert() for each member of tm_list in reverse order, from highest slot in eb X, slot N - 1, to slot 0 of eb X; 6) __tree_mod_log_insert() sets the sequence number of each given tree mod log operation - it increments fs_info->tree_mod_seq and sets fs_info->tree_mod_seq as the sequence number of the given tree mod log operation. This means that for the tm_list created at tree_mod_log_insert_root(), the element corresponding to slot 0 of eb X has the highest sequence number (1 + N), and the element corresponding to the last slot has the lowest sequence number (2); 7) Then, after inserting tm_list's elements into the tree mod log rbtree, the MOD_LOG_ROOT_REPLACE element is inserted, which gets the highest sequence number, which is N + 2; 8) Back to ctree.c:balance_level(), we free eb X by calling btrfs_free_tree_block() on it. Because eb X was created in the current transaction, has no other references and writeback did not happen for it, we add it back to the free space cache/tree; 9) Later some other task T allocates the metadata extent from eb X, since it is marked as free space in the space cache/tree, and uses it as a node for some other btree; 10) The tree mod log user task calls btrfs_search_old_slot(), which calls get_old_root(), and finally that calls __tree_mod_log_oldest_root() with time_seq == 1 and eb_root == eb Y; 11) First iteration of the while loop finds the tree mod log element with sequence number N + 2, for the logical address of eb Y and of type MOD_LOG_ROOT_REPLACE; 12) Because the operation type is MOD_LOG_ROOT_REPLACE, we don't break out of the loop, and set root_logical to point to tm->old_root.logical which corresponds to the logical address of eb X; 13) On the next iteration of the while loop, the call to tree_mod_log_search_oldest() returns the smallest tree mod log element for the logical address of eb X, which has a sequence number of 2, an operation type of MOD_LOG_KEY_REMOVE_WHILE_FREEING and corresponds to the old slot N - 1 of eb X (eb X had N items in it before being freed); 14) We then break out of the while loop and return the tree mod log operation of type MOD_LOG_ROOT_REPLACE (eb Y), and not the one for slot N - 1 of eb X, to get_old_root(); 15) At get_old_root(), we process the MOD_LOG_ROOT_REPLACE operation and set "logical" to the logical address of eb X, which was the old root. We then call tree_mod_log_search() passing it the logical address of eb X and time_seq == 1; 16) Then before calling tree_mod_log_search(), task T adds a key to eb X, which results in adding a tree mod log operation of type MOD_LOG_KEY_ADD to the tree mod log - this is done at ctree.c:insert_ptr() - but after adding the tree mod log operation and before updating the number of items in eb X from 0 to 1... 17) The task at get_old_root() calls tree_mod_log_search() and gets the tree mod log operation of type MOD_LOG_KEY_ADD just added by task T. Then it enters the following if branch: if (old_root && tm && tm->op != MOD_LOG_KEY_REMOVE_WHILE_FREEING) { (...) } (...) Calls read_tree_block() for eb X, which gets a reference on eb X but does not lock it - task T has it locked. Then it clones eb X while it has nritems set to 0 in its header, before task T sets nritems to 1 in eb X's header. From hereupon we use the clone of eb X which no other task has access to; 18) Then we call __tree_mod_log_rewind(), passing it the MOD_LOG_KEY_ADD mod log operation we just got from tree_mod_log_search() in the previous step and the cloned version of eb X; 19) At __tree_mod_log_rewind(), we set the local variable "n" to the number of items set in eb X's clone, which is 0. Then we enter the while loop, and in its first iteration we process the MOD_LOG_KEY_ADD operation, which just decrements "n" from 0 to (u32)-1, since "n" is declared with a type of u32. At the end of this iteration we call rb_next() to find the next tree mod log operation for eb X, that gives us the mod log operation of type MOD_LOG_KEY_REMOVE_WHILE_FREEING, for slot 0, with a sequence number of N + 1 (steps 3 to 6); 20) Then we go back to the top of the while loop and trigger the following BUG_ON(): (...) switch (tm->op) { case MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); fallthrough; (...) Because "n" has a value of (u32)-1 (4294967295) and tm->slot is 0. Fix this by taking a read lock on the extent buffer before cloning it at ctree.c:get_old_root(). This should be done regardless of the extent buffer having been freed and reused, as a concurrent task might be modifying it (while holding a write lock on it). Reported-by:
Zygo Blaxell <ce3g8jdj@umail.furryterror.org> Link: https://lore.kernel.org/linux-btrfs/20210227155037.GN28049@hungrycats.org/ Fixes: 834328a8 ("Btrfs: tree mod log's old roots could still be part of the tree") CC: stable@vger.kernel.org # 4.4+ Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Cheng Jian <cj.chengjian@huawei.com>
-