“c29d150305f7f655b7002cc31754c605e5c0d1a0”上不存在“arch/mips/include/asm/page.h”
- 26 11月, 2021 31 次提交
-
-
由 Luo Jiaxing 提交于
mainline inclusion from mainline-v5.11-rc1 commit 356b01a9 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4HX08 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=356b01a986a5550ee16dd0b85306c6741f2d02d5 -------------------------------------------------------------------- This GPIO driver is for HiSilicon's ARM SoC. HiSilicon's GPIO controller support double-edge interrupt and multi-core concurrent access. ACPI table example for this GPIO controller: Device (GPO0) { Name (_HID, "HISI0184") Device (PRTA) { Name (_ADR, Zero) Name (_UID, Zero) Name (_DSD, Package (0x01) { Package (0x02) { "ngpios", 0x20 } }) } } Signed-off-by: NLuo Jiaxing <luojiaxing@huawei.com> Link: https://lore.kernel.org/r/1607934255-52544-2-git-send-email-luojiaxing@huawei.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NYihang Li <liyihang6@hisilicon.com> Reviewed-by: NQi Liu <liuqi115@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 yangerkun 提交于
hulk inclusion category: bugfix bugzilla: 185798 https://gitee.com/openeuler/kernel/issues/I4JWYM CVE: NA --------------------------- luojiajun report a problem[1] two years ago which seems still exists in mainline. vfs_fallocate can avoid 'offset + len' trigger overflow, but 'offset + len + hpage_size - 1' may overflow too and will lead to a wrong 'end'. luojiajun give a solution which can fix the wrong 'end' but leave the overflow still happened. Fix it with DIV_ROUND_UP_ULL. [1] https://patchwork.kernel.org/project/linux-mm/patch/1554775226-67213-1-git-send-email-luojiajun3@huawei.com/Signed-off-by: Nyangerkun <yangerkun@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xu Qiang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- Signed-off-by: NXu Qiang <xuqiang36@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xu Qiang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- When hard lockup detection is disabled, core lockup detection is not performed. Signed-off-by: NXu Qiang <xuqiang36@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xu Qiang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- A user-mode interface is added to control the core lockup detection sensitivity. Signed-off-by: NXu Qiang <xuqiang36@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xu Qiang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- Optimized core lockup detection judgment rules to make it easier to understand. Core suspension detection is performed in the hrtimer interrupt processing function. The detection condition is that the hrtimer interrupt and NMI interrupt are not updated for multiple consecutive times. Signed-off-by: NXu Qiang <xuqiang36@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dong Kai 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- Add cmdline params "enable_corelockup_detector" to support enable core suspend detector. And enable defaultly within ascend features. Signed-off-by: NDong Kai <dongkai11@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dong Kai 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- When using pmu events as nmi source, the pmu clock is disabled under wfi/wfe mode. And the nmi can't respond periodically. To minimize the misjudgment by wfi/wfe, we adopt a simple method which to disable wfi/wfe at the right time and the watchdog hrtimer is a good baseline. The watchdog hrtimer is based on generate timer and has high freq than nmi. If watchdog hrtimer not works we disable wfi/wfe mode then the pmu nmi should always responds as long as the cpu core not suspend. Signed-off-by: NDong Kai <dongkai11@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dong Kai 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4F3V1 CVE: NA -------------------------------- The softlockup and hardlockup detector only check the status of the cpu which it resides. If certain cpu core suspends, they are both not works. There is no any valid log but the cpu already abnormal and brings a lot of problems of system. To detect this case, we add the corelockup detector. First we use whether cpu core can responds to nmi as a sectence to determine if it is suspended. Then things is simple. Per cpu core maintains it's nmi interrupt counts and detector the nmi_counts of next cpu core. If the nmi interrupt counts not changed any more which means it can't respond nmi normally, we regard it as suspend. To ensure robustness, only consecutive lost nmi more than two times then trigger the warn. The detection chain is as following: cpu0->cpu1->...->cpuN->cpu0 Signed-off-by: NDong Kai <dongkai11@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Heyi Guo 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZPY CVE: NA ------------------------------------------------- Pending LPIs may block new allocated LPIs in kdump secondary kernel. We only do that for guest kernel access to limit the change impact. Signed-off-by: NHeyi Guo <guoheyi@huawei.com> Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Link: https://gitee.com/openeuler/kernel/commit/5b574685b743Reviewed-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanan Wang 提交于
mainline inclusion from mainline-v5.12-rc1-dontuse commit 509552e6 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZOS CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=509552e65ae8 --------------------------------------------------------------------- We now set the pfn dirty and mark the page dirty before calling fault handlers in user_mem_abort(), so we might end up having spurious dirty pages if update of permissions or mapping has failed. Let's move these two operations after the fault handlers, and they will be done only if the fault has been handled successfully. When an -EAGAIN errno is returned from the map handler, we hope to the vcpu to enter guest directly instead of exiting back to userspace, so adjust the return value at the end of function. Signed-off-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210114121350.123684-4-wangyanan55@huawei.comReviewed-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanan Wang 提交于
mainline inclusion from mainline-v5.12-rc1-dontuse commit 694d071f category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZOS CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=694d071f8d85 --------------------------------------------------------------------- (1) During running time of a a VM with numbers of vCPUs, if some vCPUs access the same GPA almost at the same time and the stage-2 mapping of the GPA has not been built yet, as a result they will all cause translation faults. The first vCPU builds the mapping, and the followed ones end up updating the valid leaf PTE. Note that these vCPUs might want different access permissions (RO, RW, RX, RWX, etc.). (2) It's inevitable that we sometimes will update an existing valid leaf PTE in the map path, and we perform break-before-make in this case. Then more unnecessary translation faults could be caused if the *break stage* of BBM is just catched by other vCPUS. With (1) and (2), something unsatisfactory could happen: vCPU A causes a translation fault and builds the mapping with RW permissions, vCPU B then update the valid leaf PTE with break-before-make and permissions are updated back to RO. Besides, *break stage* of BBM may trigger more translation faults. Finally, some useless small loops could occur. We can make some optimization to solve above problems: When we need to update a valid leaf PTE in the map path, let's filter out the case where this update only change access permissions, and don't update the valid leaf PTE here in this case. Instead, let the vCPU enter back the guest and it will exit next time to go through the relax_perms path without break-before-make if it still wants more permissions. Signed-off-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210114121350.123684-3-wangyanan55@huawei.comReviewed-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanan Wang 提交于
mainline inclusion from mainline-v5.12-rc1-dontuse commit 8ed80051 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZOS CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8ed80051c8c3 ---------------------------------------------------------------------- Procedures of hyp stage-1 map and guest stage-2 map are quite different, but they are tied closely by function kvm_set_valid_leaf_pte(). So adjust the relative code for ease of code maintenance in the future. Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210114121350.123684-2-wangyanan55@huawei.comReviewed-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zenghui Yu 提交于
virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZOS CVE: NA ---------------------------------------------------- Kunpeng 920 offers the HHA ncsnp capability, with which hypervisor doesn't need to perform a lot of cache maintenance like before (in case the guest has some non-cacheable Stage-1 mappings). Currently we apply this hardware capability when - vCPU switching MMU+caches on/off - creating Stage-2 mappings for Daborts Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NYanan Wang <wangyanan55@huawei.com> Reviewed-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zenghui Yu 提交于
virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZOS CVE: NA ---------------------------------------------------- Parse ACPI/DTB to get where the hypervisor is running. Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NYanan Wang <wangyanan55@huawei.com> Reviewed-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zenghui Yu 提交于
virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZPY CVE: NA ------------------------------------------------- When guest exits due to "TRAP", we can analyze the guest exit reasons deeplier. Enhance perf-kvm-stat to record and analyze VM TRAP events. There is a mapping between guest's "trap_code" (ESR_ELx's bits[31:26]) and "trap_reason" - kvm_arm_exception_class. Copy it from kernel to aarch64_guest_exits.h, export it to userspace. This patch records two new KVM tracepoints: "kvm:kvm_trap_enter" and "kvm:kvm_trap_exit", and reports statistical data between these two tracepoints. A simple test go below: # ./tools/perf/perf kvm stat record -p 20763 [ perf record: Woken up 92 times to write data ] [ perf record: Captured and wrote 203.727 MB perf.data.guest (2601786 samples) ] # ./tools/perf/perf kvm stat report --event=vmexit Analyze events for all VMs, all VCPUs: VM-EXIT Samples Samples% Time% Min Time Max Time Avg time TRAP 640931 97.12% 100.00% 2.44us 14683.86us 3446.49us ( +- 0.05% ) IRQ 19019 2.88% 0.00% 0.90us 461.94us 2.12us ( +- 2.09% ) Total Samples:659950, Total events handled time:2209005391.30us. # ./tools/perf/perf kvm stat report --event=trap Analyze events for all VMs, all VCPUs: TRAP-EVENT Samples Samples% Time% Min Time Max Time Avg time WFx 601194 93.80% 99.98% 0.90us 4294.04us 3671.01us ( +- 0.03% ) SYS64 33714 5.26% 0.01% 1.10us 41.34us 5.68us ( +- 0.18% ) DABT_LOW 6014 0.94% 0.00% 1.12us 18.04us 2.57us ( +- 0.91% ) IABT_LOW 12 0.00% 0.01% 12597.76us 14679.96us 12893.61us ( +- 1.34% ) Total Samples:640934, Total events handled time:2207353434.56us. Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/1560330526-15468-6-git-send-email-yuzenghui@huawei.com Link: https://gitee.com/openeuler/kernel/commit/59634497418bReviewed-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zenghui Yu 提交于
virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZPY CVE: NA ------------------------------------------------- 'perf kvm stat report/record' generates a statistical analysis of KVM events and can be used to analyze guest exit reasons. This patch tries to add stat support on arm64. We have a mapping between guest's "exit_code" and "exit_reason" which already exists under arch/arm64/include/asm/ (kvm_arm_exception_type), and we've used it to report guest's exit type through trace_kvm_exit(). Copy kvm_arm_exception_type into aarch64_guest_exits.h, thus export it to userspace. It records on two available KVM tracepoints for arm64: "kvm:kvm_entry" and "kvm:kvm_exit", and reports statistical data which includes events handles time, samples, and so on. A simple test go below: # pgrep qemu 6039 9937 # ./tools/perf/perf kvm stat record -p 6039 [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 15.629 MB perf.data.guest (199063 samples) ] # ./tools/perf/perf kvm stat report --event=vmexit Analyze events for all VMs, all VCPUs: VM-EXIT Samples Samples% Time% Min Time Max Time Avg time TRAP 49040 97.15% 100.00% 2.60us 4072.98us 3431.60us ( +- 0.17% ) IRQ 1437 2.85% 0.00% 0.90us 24.56us 2.06us ( +- 1.37% ) Total Samples:50477, Total events handled time:168288630.04us. Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/1560330526-15468-5-git-send-email-yuzenghui@huawei.com Link: https://gitee.com/openeuler/kernel/commit/15db05576381Reviewed-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zenghui Yu 提交于
virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZPY CVE: NA ------------------------------------------------- Currently, we use trace_kvm_exit() to report exception type (e.g., "IRQ", "TRAP") and exception class (ESR_ELx's bit[31:26]) together. But hardware only saves the exit class to ESR_ELx on synchronous exceptions, not on asynchronous exceptions. When the guest exits due to external interrupts, we will get tracing output like: "kvm_exit: IRQ: HSR_EC: 0x0000 (UNKNOWN), PC: 0xffff87259e30" Obviously, "HSR_EC" here is meaningless. This patch splits "exit" and "trap" events by adding two tracepoints explicitly in handle_trap_exceptions(). Let trace_kvm_exit() report VM exit events, and trace_kvm_trap_exit() report VM trap events. These tracepoints are adjusted also in preparation for supporting 'perf kvm stat' on arm64. Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/1560330526-15468-3-git-send-email-yuzenghui@huawei.com Link: https://gitee.com/openeuler/kernel/commit/14b85d8d7d2dReviewed-by: NYanan Wang <wangyanan55@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J9B0?from=project-issue ------------------------------------------------------------------------ Build HiSilicon I2C/SPI/SFC driver as module. Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Reviewed-by: NJay Fang <f.fangjian@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yiwen Jiang 提交于
euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4J0W7 CVE: NA ------------------------------------------------- lpi_cache_lock can be called in irq context, so it should use irqsave spinlock. Signed-off-by: NYiwen Jiang <jiangyiwen@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NChaochao Xing <xingchaochao@huawei.com> Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xiangyou Xie 提交于
euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J0W7 CVE: NA ------------------------------------------------- It is not necessary to invalidate the lpi translation cache when the virtual machine executes the movi instruction to adjust the affinity of the interrupt. Irqbalance will adjust the interrupt affinity in a short period of time to achieve the purpose of interrupting load balancing, but this does not affect the contents of the lpi translation cache. Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NChaochao Xing <xingchaochao@huawei.com> Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xiangyou Xie 提交于
virt inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J0W7 CVE: NA ------------------------------------------------- Because dist->lpi_list_lock is a perVM lock, when a virtual machine is configured with multiple virtual NIC devices and receives network packets at the same time, dist->lpi_list_lock will become a performance bottleneck. This patch increases the number of lpi_translation_cache to eight, hashes the cpuid that executes irqfd_wakeup, and chooses which lpi_translation_cache to use. I tested the impact of virtual interrupt injection time-consuming: Run the iperf command to send UDP packets to the VM: iperf -c $IP -u -b 40m -l 64 -t 6000& The vm just receive UDP traffic. When configure multiple NICs, each NIC receives the above iperf UDP traffic, This may reflect the performance impact of shared resource competition, such as lock. Observing the delay of virtual interrupt injection: the time spent by the "irqfd_wakeup", "irqfd_inject" function, and kworker context switch. The less the better. ITS translation cache greatly reduces the delay of interrupt injection compared to kworker thread, because it eliminate wakeup and uncertain scheduling delay: kworker ITS translation cache improved 1 NIC 6.692 us 1.766 us 73.6% 10 NICs 7.536 us 2.574 us 65.8% Increases the number of lpi_translation_cache reduce lock competition. Multi-interrupt concurrent injections perform better: ITS translation cache with patch improved 1 NIC 1.766 us 1.694 us 4.1% 10 NICs 2.574 us 1.848 us 28.2% Signed-off-by: NXiangyou Xie <xiexiangyou@huawei.com> Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NChaochao Xing <xingchaochao@huawei.com> Reviewed-by: NXiangyou Xie <xiexiangyou@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanling Song 提交于
Ramaxel inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J0GH CVE: NA ---------------------------------------- When the firmware does not support VXLAN offload, clear the flag of CSUM and TS0. Signed-off-by: NYanling Song <songyl@ramaxel.com> Reviewed-by: Xu Yun<xuyun@ramaxel.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanling Song 提交于
Ramaxel inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J0GH CVE: NA ----------------------------------------------- Support to configure DMA attribute thru firmware Signed-off-by: NYanling Song <songyl@ramaxel.com> Reviewed-by: Xu Yun<xuyun@ramaxel.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanling Song 提交于
Ramaxel inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J0GH CVE: NA -------------------------------------------- 1.Solve the problem that the indirection table cannot be obtained by ethtool - x ethx command. 2.Solve the system oops problem caused by ethtool - x ethx default command. Signed-off-by: NYanling Song <songyl@ramaxel.com> Reviewed-by: Xu Yun<xuyun@ramaxel.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Biaoxiang Ye 提交于
euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZNO CVE: NA ------------------------------------------------- On aarch64 NUMA machines, the kworker of iscsi created always jump around across node boundaries. If it work on the different node even different cpu package with the softirq of network interface, memcpy with in iscsi_tcp_segment_recv will be slow down, and iscsi got an terrible performance. In this patch, we trace the cpu of softirq, and tell queue_work_on to execute iscsi_xmitworker on the same NUMA node. The performance data as below: fio cmd: fio -filename=/dev/disk/by-id/wwn-0x6883fd3100a2ad260036281700000000 -direct=1 -iodepth=32 -rw=read -bs=64k -size=30G -ioengine=libaio -numjobs=1 -group_reporting -name=mytest -time_based -ramp_time=60 -runtime=60 before patch: Jobs: 1 (f=1): [R] [52.5% done] [852.3MB/0KB/0KB /s] [13.7K/0/0 iops] [eta 00m:57s] Jobs: 1 (f=1): [R] [53.3% done] [861.4MB/0KB/0KB /s] [13.8K/0/0 iops] [eta 00m:56s] Jobs: 1 (f=1): [R] [54.2% done] [868.2MB/0KB/0KB /s] [13.9K/0/0 iops] [eta 00m:55s] after pactch: Jobs: 1 (f=1): [R] [53.3% done] [1070MB/0KB/0KB /s] [17.2K/0/0 iops] [eta 00m:56s] Jobs: 1 (f=1): [R] [55.0% done] [1064MB/0KB/0KB /s] [17.3K/0/0 iops] [eta 00m:54s] Jobs: 1 (f=1): [R] [56.7% done] [1069MB/0KB/0KB /s] [17.1K/0/0 iops] [eta 00m:52s] cpu info: Architecture: aarch64 Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 1 Core(s) per socket: 64 Socket(s): 2 NUMA node(s): 4 Model: 0 CPU max MHz: 2600.0000 CPU min MHz: 200.0000 BogoMIPS: 200.00 L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 32768K NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node2 CPU(s): 64-95 NUMA node3 CPU(s): 96-127 Signed-off-by: NBiaoxiang Ye <yebiaoxiang@huawei.com> Acked-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: Nfang yi <eric.fangyi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Biaoxiang Ye 提交于
euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZNO CVE: NA ------------------------------------------------- Currently, single thread workqueue only have single pwq, all of works are queued the same workerpool. This is not optimal on NUMA machines, will cause workers jump around across node. This patch add a new wq flags __WQ_DYNAMIC, this new kind of single thread workqueue creates a separate pwq covering the intersecting CPUS for each NUMA node which has online CPUS in @attrs->cpumask instead of mapping all entries of numa_pwq_tbl[] to the same pwq. After this, we can specify the @cpu of queue_work_on, so the work can be executed on the same NUMA node of the specified @cpu. This kind of wq only support single work, multi works can't guarantee the work's order. Signed-off-by: NBiaoxiang Ye <yebiaoxiang@huawei.com> Acked-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: Nfang yi <eric.fangyi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Yingliang 提交于
euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZNO CVE: NA ------------------------------------------------- Add member to struct iscsi_conn. Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-By: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NBiaoXiang Ye <yebiaoxiang@huawei.com> Reviewed-by: Nfang yi <eric.fangyi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Weihua 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4IH1G CVE: NA --------------------------- Livepatch allows users to call hook functions to perform some customized operations when insmod the .ko. During the test, it is found that in the ARM64 architecture, if accesses the global variables defined by other ko in hook functions, a crash occurs. Since relocation is performed during the livepatch insertion, instructions in the icache should be invalid. If the instructions in the icache are directly obtained, incorrect addresses may be obtained, caseing crash. Therefore, flush the icache before calling the hook functions. Signed-off-by: NYe Weihua <yeweihua4@huawei.com> Reviewed-by: NJian Cheng <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Signed-off-by: NYe Weihua <yeweihua4@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Weihua 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4IGQ2 CVE: NA ------------------------------- Before a module is deleted, the kernel traverses the jump_label section to release resources applied by each jump entry. Common modules apply for these resources before module initialization, but livepatch modules apply during livepatch redirection. Therefore, when a livepatch module fails to be inserted, the resources to be applied by jump_label are not applied. As a result, a panic occurs when a null pointer is accessed during resource release. To solve the this problem, skip resource release if jump label is not relocated. Signed-off-by: NYe Weihua <yeweihua4@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanling Song 提交于
Ramaxel inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I0OZ CVE: NA -------------------------- Fix typo of last_cmsn which should be last_pmsn Signed-off-by: NYanling Song <songyl@ramaxel.com> Reviewed-by: Zhang Lei<zhanglei48@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 23 11月, 2021 1 次提交
-
-
由 Zekun Shen 提交于
mainline inclusion from mainline commit b922f622 bugzilla: 185788 https://e.gitee.com/open_euler/dashboard?issue=I4IYTG CVE: CVE-2021-43975 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b922f622592af76b57cbc566eaeccda0b31a3496 -------------------------------- This bug report shows up when running our research tools. The reports is SOOB read, but it seems SOOB write is also possible a few lines below. In details, fw.len and sw.len are inputs coming from io. A len over the size of self->rpc triggers SOOB. The patch fixes the bugs by adding sanity checks. The bugs are triggerable with compromised/malfunctioning devices. They are potentially exploitable given they first leak up to 0xffff bytes and able to overwrite the region later. The patch is tested with QEMU emulater. This is NOT tested with a real device. Attached is the log we found by fuzzing. BUG: KASAN: slab-out-of-bounds in hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] Read of size 4 at addr ffff888016260b08 by task modprobe/213 CPU: 0 PID: 213 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] __kasan_report.cold+0x37/0x7c ? aq_hw_read_reg_bit+0x60/0x70 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] kasan_report+0xe/0x20 hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] hw_atl_utils_fw_rpc_call+0x95/0x130 [atlantic] hw_atl_utils_fw_rpc_wait+0x176/0x210 [atlantic] hw_atl_utils_mpi_create+0x229/0x2e0 [atlantic] ? hw_atl_utils_fw_rpc_wait+0x210/0x210 [atlantic] ? hw_atl_utils_initfw+0x9f/0x1c8 [atlantic] hw_atl_utils_initfw+0x12a/0x1c8 [atlantic] aq_nic_ndev_register+0x88/0x650 [atlantic] ? aq_nic_ndev_init+0x235/0x3c0 [atlantic] aq_pci_probe+0x731/0x9b0 [atlantic] ? aq_pci_func_init+0xc0/0xc0 [atlantic] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 Reported-by: NBrendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: NZekun Shen <bruceshenzk@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NChen Jun <chenjun102@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 18 11月, 2021 8 次提交
-
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-master commit 688db0c7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=688db0c7a4a6 ---------------------------------------------------------------------- Currently, driver only allow configuring ETS bandwidth of TCs according to the max TC number queried from firmware. However, the hardware actually supports 8 TCs and users may need to configure ETS bandwidth of all TCs, so remove the restriction. Fixes: 330baff5 ("net: hns3: add ETS TC weight setting in SSU module") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-master commit 91fcc79b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91fcc79bff40 ---------------------------------------------------------------------- If users set unicast mac address for VFs by PF, they need to guarantee all VFs' address is different. This patch removes the check mac address exist of VFs, for usrs can refresh mac addresses of all VFs directly without need to modify the exist mac address to other value firstly. Fixes: 8e6de441 ("net: hns3: add support for configuring VF MAC from the host") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-master commit 1122eac1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1122eac19476 ---------------------------------------------------------------------- When driver queries the register number of mac statistics from firmware, the old firmware runs in device version V2 only returns number of valid registers, not include number of three reserved registers among of them. It cause driver doesn't record the last three data when query mac statistics. To fix this problem, driver never query register number in device version V2 and set it to a fixed value which include three reserved registers. Fixes: c8af2887 ("net: hns3: add support pause/pfc durations for mac statistics") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-master commit e140c798 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e140c7983e30 ---------------------------------------------------------------------- When fully configure VLANs for a VF, then unload the VF while triggering a reset to PF, will cause a kernel crash because the irq is already uninit. [ 293.177579] ------------[ cut here ]------------ [ 293.183502] kernel BUG at drivers/pci/msi.c:352! [ 293.189547] Internal error: Oops - BUG: 0 [#1] SMP ...... [ 293.390124] Workqueue: hclgevf hclgevf_service_task [hclgevf] [ 293.402627] pstate: 80c00009 (Nzcv daif +PAN +UAO) [ 293.414324] pc : free_msi_irqs+0x19c/0x1b8 [ 293.425429] lr : free_msi_irqs+0x18c/0x1b8 [ 293.436545] sp : ffff00002716fbb0 [ 293.446950] x29: ffff00002716fbb0 x28: 0000000000000000 [ 293.459519] x27: 0000000000000000 x26: ffff45b91ea16b00 [ 293.472183] x25: 0000000000000000 x24: ffffa587b08f4700 [ 293.484717] x23: ffffc591ac30e000 x22: ffffa587b08f8428 [ 293.497190] x21: ffffc591ac30e300 x20: 0000000000000000 [ 293.509594] x19: ffffa58a062a8300 x18: 0000000000000000 [ 293.521949] x17: 0000000000000000 x16: ffff45b91dcc3f48 [ 293.534013] x15: 0000000000000000 x14: 0000000000000000 [ 293.545883] x13: 0000000000000040 x12: 0000000000000228 [ 293.557508] x11: 0000000000000020 x10: 0000000000000040 [ 293.568889] x9 : ffff45b91ea1e190 x8 : ffffc591802d0000 [ 293.580123] x7 : ffffc591802d0148 x6 : 0000000000000120 [ 293.591190] x5 : ffffc591802d0000 x4 : 0000000000000000 [ 293.602015] x3 : 0000000000000000 x2 : 0000000000000000 [ 293.612624] x1 : 00000000000004a4 x0 : ffffa58a1e0c6b80 [ 293.623028] Call trace: [ 293.630340] free_msi_irqs+0x19c/0x1b8 [ 293.638849] pci_disable_msix+0x118/0x140 [ 293.647452] pci_free_irq_vectors+0x20/0x38 [ 293.656081] hclgevf_uninit_msi+0x44/0x58 [hclgevf] [ 293.665309] hclgevf_reset_rebuild+0x1ac/0x2e0 [hclgevf] [ 293.674866] hclgevf_reset+0x358/0x400 [hclgevf] [ 293.683545] hclgevf_reset_service_task+0xd0/0x1b0 [hclgevf] [ 293.693325] hclgevf_service_task+0x4c/0x2e8 [hclgevf] [ 293.702307] process_one_work+0x1b0/0x448 [ 293.710034] worker_thread+0x54/0x468 [ 293.717331] kthread+0x134/0x138 [ 293.724114] ret_from_fork+0x10/0x18 [ 293.731324] Code: f940b000 b4ffff00 a903e7b8 f90017b6 (d4210000) This patch fixes the problem by waiting for the VF reset done while unloading the VF. Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-master commit 3b6db4a0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b6db4a0492b ---------------------------------------------------------------------- When the driver processes rx packets, the head pointer is updated only after the number of received packets reaches 16. However, hardware relies on the head pointer to calculate the number of FBDs. As a result, the hardware calculates the FBD incorrectly. Therefore, the driver proactively updates the head pointer in each common poll to ensure that the number of FBDs calculated by the hardware is correct. Fixes: 68752b24 ("net: hns3: schedule the polling again when allocation fails") Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jie Wang 提交于
mainline inclusion from mainline-master commit 0b653a81 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b653a81a26d ---------------------------------------------------------------------- Currently, driver will send command to firmware to query pfc packet number when user uses dcb tool to get pfc parameters. However, the periodic service task will also periodically query and record MAC statistics, including pfc packet number. As the hardware registers of statistics is cleared after reading, it will cause pfc packet number of MAC statistics are not correct after using dcb tool to get pfc parameters. To fix this problem, when user uses dcb tool to get pfc parameters, driver updates MAC statistics firstly and then get pfc packet number from MAC statistics. Fixes: 64fd2300 ("net: hns3: add support for querying pfc puase packets statistic") Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jie Wang 提交于
mainline inclusion from mainline-master commit beb27ca4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=beb27ca451a5 ---------------------------------------------------------------------- Currently, NIC init ROCE interrupt vector with MSIX interrupt. But ROCE use pci_irq_vector() to get interrupt vector, which adds the relative interrupt vector again and gets wrong interrupt vector. So fixes it by assign relative interrupt vector to ROCE instead of MSIX interrupt vector and delete the unused struct member base_msi_vector declaration of hclgevf_dev. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-master commit 3b4c6566 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4I7P7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b4c6566c158 ---------------------------------------------------------------------- Currently, when driver is failed to add a new multicast mac address to hardware due to the multicast mac table is full, it will directly return. In this case, if the multicast mac list has some reuse addresses after the new address, those reuse addresses will never be added to hardware. To fix this problem, if function hclge_add_mc_addr_common() returns -ENOSPC, hclge_sync_vport_mac_list() should judge whether continue or stop to add next address. As function hclge_sync_vport_mac_list() needs parameter mac_type to know whether is uc or mc, refine this function to add parameter mac_type and remove parameter sync. So does function hclge_unsync_vport_mac_list(). Fixes: ee4bcd3b ("net: hns3: refactor the MAC address configure") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Reviewed-by: NYongxin Li <liyongxin1@huawei.com> Signed-off-by: NJunxin Chen <chenjunxin1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-