- 09 8月, 2022 14 次提交
-
-
由 Junhao He 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5EZY2 ------------------------------------------------------------------ In FIFO mode, when the state of sink buffer is full, the sink device will continuously backpressures the ETM, so that the ETM cannot switch to the idle state. In this case, the WFx instruction cannot be executed because the CPU detects that the ETM is not in the idle state which that will cause CPU hung. We workaround this issue on HiSilicon ETM by setting bit 13 of TRCAUXCTLR which is used to indicate that the ETM is in the idle state. The call trace is shown below: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 10-...0: (1 ticks this GP) idle=5b6/1/0x4000000000000000 softirq=12309/12318 fqs=114196 (detected by 67, t=330041 jiffies, g=309253, q=453663) Task dump for CPU 10: task:ksoftirqd/10 state:R running task stack: 0 pid: 64 ppid: 2 flags:0x0000000a Call trace: __switch_to+0xbc/0xfc irqtime_account_irq+0x58/0xc4 __do_softirq+0x6c/0x358 run_ksoftirqd+0x68/0x90 smpboot_thread_fn+0x15c/0x1a0 kthread+0x108/0x13c ret_from_fork+0x10/0x18 watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [bash:133345] ... Call trace: smp_call_function_single+0x178/0x190 etm4_disable_sysfs+0x74/0xfc [coresight_etm4x] etm4_disable+0x6c/0x70 [coresight_etm4x] coresight_disable_source+0x7c/0xa0 [coresight] coresight_disable+0x6c/0x13c [coresight] enable_source_store+0x88/0xa0 [coresight] dev_attr_store+0x20/0x34 sysfs_kf_write+0x4c/0x5c kernfs_fop_write_iter+0x130/0x1c0 new_sync_write+0xec/0x18c vfs_write+0x214/0x2ac ksys_write+0x70/0xfc __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.0+0x7c/0x1bc do_el0_svc+0x2c/0x94 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Signed-off-by: NQi Liu <liuqi115@huawei.com> Signed-off-by: NJunhao He <hejunhao3@huawei.com> Reviewed-by: NJay Fang <f.fangjian@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Qi Liu 提交于
mainline inclusion from mainline-v5.19-rc1 commit 6b79738b category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5AZ87 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b79738b6ed9 -------------------------------------------------------------------------- On HiSilicon Hip09 platform, there is a CPA (Coherency Protocol Agent) on each SICL (Super IO Cluster) which implements packet format translation, route parsing and traffic statistics. CPA PMU has 8 PMU counters and interrupt is supported to handle counter overflow. Let's support its driver under the framework of HiSilicon PMU driver. Signed-off-by: NQi Liu <liuqi115@huawei.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Reviewed-by: NShaokun Zhang <zhangshaokun@hisilicon.com> Link: https://lore.kernel.org/r/20220415102352.6665-3-liuqi115@huawei.comSigned-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NJunhao He <hejunhao3@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Qi Liu 提交于
mainline inclusion from mainline-v5.19-rc1 commit 807907da category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5AZ87 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=807907dae970 -------------------------------------------------------------------------- If a PMU is in a SICL (Super IO cluster), it is not appropriate to associate this PMU with a CPU die. So we associate it with all CPUs online, rather than CPUs in the nearest SCCL. As the firmware of Hip09 platform hasn't been published yet, change of PMU driver will not influence backwards compatibility between driver and firmware. Signed-off-by: NQi Liu <liuqi115@huawei.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20220415102352.6665-2-liuqi115@huawei.comSigned-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NJunhao He <hejunhao3@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Qi Liu 提交于
mainline inclusion from mainline-v5.17-rc1 commit 8404b0fb category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5AZ87 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8404b0fbc7fb -------------------------------------------------------------------------- PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported to sample bandwidth, latency, buffer occupation etc. Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is registered as a PMU in /sys/bus/event_source/devices, so users can select target PMU, and use filter to do further sets. Filtering options contains: event - select the event. port - select target Root Ports. Information of Root Ports are shown under sysfs. bdf - select requester_id of target EP device. trig_len - set trigger condition for starting event statistics. trig_mode - set trigger mode. 0 means starting to statistic when bigger than trigger condition, and 1 means smaller. thr_len - set threshold for statistics. thr_mode - set threshold mode. 0 means count when bigger than threshold, and 1 means smaller. Acked-by: NKrzysztof Wilczyński <kw@linux.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NQi Liu <liuqi115@huawei.com> Reviewed-by: NShaokun Zhang <zhangshaokun@hisilicon.com> Link: https://lore.kernel.org/r/20211202080633.2919-3-liuqi115@huawei.comSigned-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NJunhao He <hejunhao3@huawei.com> Reviewed-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Muchun Song 提交于
stable inclusion from stable-v5.10.116 commit d1ac096f886914ad2630ffad7adf8658d77a2870 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d1ac096f886914ad2630ffad7adf8658d77a2870 -------------------------------- commit 7c25a0b8 upstream. userfaultfd calls mcopy_atomic_pte() and __mcopy_atomic() which do not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this by insert flush_dcache_page() after copy_from_user() succeeds. Link: https://lkml.kernel.org/r/20220210123058.79206-7-songmuchun@bytedance.com Fixes: b6ebaedb ("userfaultfd: avoid mmap_sem read recursion in mcopy_atomic") Fixes: c1a4de99 ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") Signed-off-by: NMuchun Song <songmuchun@bytedance.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Rientjes <rientjes@google.com> Cc: Fam Zheng <fam.zheng@bytedance.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Lars Persson <lars.persson@axis.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Peter Xu <peterx@redhat.com> Cc: Xiongchun Duan <duanxiongchun@bytedance.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Muchun Song 提交于
stable inclusion from stable-v5.10.116 commit c6cbf5431a626fbb13271cacad93ae849b889769 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c6cbf5431a626fbb13271cacad93ae849b889769 -------------------------------- commit e763243c upstream. userfaultfd calls copy_huge_page_from_user() which does not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this issue by flushing dcache in copy_huge_page_from_user(). Link: https://lkml.kernel.org/r/20220210123058.79206-4-songmuchun@bytedance.com Fixes: fa4d75c1 ("userfaultfd: hugetlbfs: add copy_huge_page_from_user for hugetlb userfaultfd support") Signed-off-by: NMuchun Song <songmuchun@bytedance.com> Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Rientjes <rientjes@google.com> Cc: Fam Zheng <fam.zheng@bytedance.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Lars Persson <lars.persson@axis.com> Cc: Peter Xu <peterx@redhat.com> Cc: Xiongchun Duan <duanxiongchun@bytedance.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Muchun Song 提交于
stable inclusion from stable-v5.10.116 commit 308ff6a6e76813528667912a5349d182a32ffdce category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=308ff6a6e76813528667912a5349d182a32ffdce -------------------------------- commit 2771739a upstream. The D-cache maintenance inside move_to_new_page() only consider one page, there is still D-cache maintenance issue for tail pages of compound page (e.g. THP or HugeTLB). THP migration is only enabled on x86_64, ARM64 and powerpc, while powerpc and arm64 need to maintain the consistency between I-Cache and D-Cache, which depends on flush_dcache_page() to maintain the consistency between I-Cache and D-Cache. But there is no issues on arm64 and powerpc since they already considers the compound page cache flushing in their icache flush function. HugeTLB migration is enabled on arm, arm64, mips, parisc, powerpc, riscv, s390 and sh, while arm has handled the compound page cache flush in flush_dcache_page(), but most others do not. In theory, the issue exists on many architectures. Fix this by not using flush_dcache_folio() since it is not backportable. Link: https://lkml.kernel.org/r/20220210123058.79206-3-songmuchun@bytedance.com Fixes: 290408d4 ("hugetlb: hugepage migration core") Signed-off-by: NMuchun Song <songmuchun@bytedance.com> Reviewed-by: NZi Yan <ziy@nvidia.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: David Rientjes <rientjes@google.com> Cc: Fam Zheng <fam.zheng@bytedance.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Lars Persson <lars.persson@axis.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Peter Xu <peterx@redhat.com> Cc: Xiongchun Duan <duanxiongchun@bytedance.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Itay Iellin 提交于
stable inclusion from stable-v5.10.116 commit 185fa5984d7a54bab63d37952aa5465b4fd08ac8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=185fa5984d7a54bab63d37952aa5465b4fd08ac8 -------------------------------- commit 103a2f32 upstream. Set a size limit of 8 bytes of the written buffer to "hdev->name" including the terminating null byte, as the size of "hdev->name" is 8 bytes. If an id value which is greater than 9999 is allocated, then the "snprintf(hdev->name, sizeof(hdev->name), "hci%d", id)" function call would lead to a truncation of the id value in decimal notation. Set an explicit maximum id parameter in the id allocation function call. The id allocation function defines the maximum allocated id value as the maximum id parameter value minus one. Therefore, HCI_MAX_ID is defined as 10000. Signed-off-by: NItay Iellin <ieitayie@gmail.com> Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Mike Rapoport 提交于
stable inclusion from stable-v5.10.116 commit 9ff4a6b80642623a7eeb82f1e48feb549fcba6d9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ff4a6b80642623a7eeb82f1e48feb549fcba6d9 -------------------------------- commit 5e545df3 upstream. ARM is the only architecture that defines CONFIG_ARCH_HAS_HOLES_MEMORYMODEL which in turn enables memmap_valid_within() function that is intended to verify existence of struct page associated with a pfn when there are holes in the memory map. However, the ARCH_HAS_HOLES_MEMORYMODEL also enables HAVE_ARCH_PFN_VALID and arch-specific pfn_valid() implementation that also deals with the holes in the memory map. The only two users of memmap_valid_within() call this function after a call to pfn_valid() so the memmap_valid_within() check becomes redundant. Remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL and memmap_valid_within() and rely entirely on ARM's implementation of pfn_valid() that is now enabled unconditionally. Link: https://lkml.kernel.org/r/20201101170454.9567-9-rppt@kernel.orgSigned-off-by: NMike Rapoport <rppt@linux.ibm.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matt Turner <mattst88@gmail.com> Cc: Meelis Roos <mroos@linux.ee> Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Tony Luck <tony.luck@intel.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Reported-by: Nkernel test robot <lkp@intel.com> Fixes: 8dd559d53b3b ("arm: ioremap: don't abuse pfn_valid() to check if pfn is in RAM") Signed-off-by: NMike Rapoport <rppt@linux.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Nathan Chancellor 提交于
stable inclusion from stable-v5.10.116 commit dfb55dcf9d39850810710eea92e4d4fa24624a73 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dfb55dcf9d39850810710eea92e4d4fa24624a73 -------------------------------- commit 8a64ef04 upstream. A new warning in clang points out two places in this driver where boolean expressions are being used with a bitwise OR instead of a logical one: drivers/net/ethernet/netronome/nfp/nfp_asm.c:199:20: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] reg->src_lmextn = swreg_lmextn(lreg) | swreg_lmextn(rreg); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/net/ethernet/netronome/nfp/nfp_asm.c:199:20: note: cast one or both operands to int to silence this warning drivers/net/ethernet/netronome/nfp/nfp_asm.c:280:20: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] reg->src_lmextn = swreg_lmextn(lreg) | swreg_lmextn(rreg); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/net/ethernet/netronome/nfp/nfp_asm.c:280:20: note: cast one or both operands to int to silence this warning 2 errors generated. The motivation for the warning is that logical operations short circuit while bitwise operations do not. In this case, it does not seem like short circuiting is harmful so implement the suggested fix of changing to a logical operation to fix the warning. Link: https://github.com/ClangBuiltLinux/linux/issues/1479Reported-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NNathan Chancellor <nathan@kernel.org> Reviewed-by: NNick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20211018193101.2340261-1-nathan@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Lee Jones 提交于
stable inclusion from stable-v5.10.116 commit f89f76f4b0e7ae7d7f5316fe0584c4cb79fa2507 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f89f76f4b0e7ae7d7f5316fe0584c4cb79fa2507 -------------------------------- commit 353f7f3a upstream. Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function ‘dal_gpio_service_create’: drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ [-Wenum-conversion] Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Lee Jones 提交于
stable inclusion from stable-v5.10.116 commit efd1429fa99ba872149b8cac89afc0ac94ec24d1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=efd1429fa99ba872149b8cac89afc0ac94ec24d1 -------------------------------- commit 1f1e87b4 upstream. Fixes the following W=1 kernel build warning(s): from drivers/block/drbd/drbd_nl.c:24: drivers/block/drbd/drbd_nl.c: In function ‘drbd_adm_set_role’: drivers/block/drbd/drbd_nl.c:793:11: warning: implicit conversion from ‘enum drbd_state_rv’ to ‘enum drbd_ret_code’ [-Wenum-conversion] drivers/block/drbd/drbd_nl.c:795:11: warning: implicit conversion from ‘enum drbd_state_rv’ to ‘enum drbd_ret_code’ [-Wenum-conversion] drivers/block/drbd/drbd_nl.c: In function ‘drbd_adm_attach’: drivers/block/drbd/drbd_nl.c:1965:10: warning: implicit conversion from ‘enum drbd_state_rv’ to ‘enum drbd_ret_code’ [-Wenum-conversion] drivers/block/drbd/drbd_nl.c: In function ‘drbd_adm_connect’: drivers/block/drbd/drbd_nl.c:2690:10: warning: implicit conversion from ‘enum drbd_state_rv’ to ‘enum drbd_ret_code’ [-Wenum-conversion] drivers/block/drbd/drbd_nl.c: In function ‘drbd_adm_disconnect’: drivers/block/drbd/drbd_nl.c:2803:11: warning: implicit conversion from ‘enum drbd_state_rv’ to ‘enum drbd_ret_code’ [-Wenum-conversion] Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: drbd-dev@lists.linbit.com Cc: linux-block@vger.kernel.org Signed-off-by: NLee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210312105530.2219008-8-lee.jones@linaro.orgSigned-off-by: NJens Axboe <axboe@kernel.dk> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Dmitry Osipenko 提交于
stable inclusion from stable-v5.10.116 commit a71658c7db0b2be9fcab3522aeabe11792a4f481 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71658c7db0b2be9fcab3522aeabe11792a4f481 -------------------------------- commit 51dfb6ca upstream. Add missing stubs to regulator/consumer.h in order to fix COMPILE_TEST of the kernel. In particular this should fix compile-testing of OPP core because of a missing stub for regulator_sync_voltage(). Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NDmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210120205844.12658-1-digetx@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org> Cc: Bjørn Mork <bjorn@mork.no> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 Nathan Chancellor 提交于
stable inclusion from stable-v5.10.116 commit 7648f42d1a6241111078cd3f237086f998e63027 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L64K Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7648f42d1a6241111078cd3f237086f998e63027 -------------------------------- commit d422c6c0 upstream. When building xway_defconfig with clang: arch/mips/lantiq/prom.c:82:23: error: array comparison always evaluates to true [-Werror,-Wtautological-compare] else if (__dtb_start != __dtb_end) ^ 1 error generated. These are not true arrays, they are linker defined symbols, which are just addresses. Using the address of operator silences the warning and does not change the resulting assembly with either clang/ld.lld or gcc/ld (tested with diff + objdump -Dr). Do the same thing across the entire MIPS subsystem to ensure there are no more warnings around this type of comparison. Link: https://github.com/ClangBuiltLinux/linux/issues/1232Signed-off-by: NNathan Chancellor <natechancellor@gmail.com> Acked-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
- 06 8月, 2022 1 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @etzhao Hi, Bus lock detection and ratelimit feature for OpenEuler backporting was tested Okay, help to review and merge Title: bus lock detection and ratelimit feature for OpenEuler. Content: Bus locks degrade performance for the whole system, not just for the CPU that requested the bus lock. Two CPU features "#AC for split lock" and "#DB for bus lock" provide hooks so that the operating system may choose one of several mitigation strategies. bus lock feature to cover additional situations with new options to mitigate. This patch set enables the bus lock detection functions and will limite the warning message output rate to desired number. Intel-kernel issue: #I5G10C:SPR:Bus lock detection and ratelimit support Test: Bus lock detection/split lock disable test for OpenEuler Check If the CPU has the bus lock detection or split lock feature #cat /proc/cpuinfo |grep bus_lock_detect bus_lock_detect #cat /proc/cpuinfo |grep split_lock_detect split_lock_detect The result shows the "bus_lock_detect" or "split_lock_detect" pass warn mode, default is warn mode without any parameters to kernel command line. split lock detection is enabled by kernel dmesg |grep '#AC' [ 0.000000] x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks (seeing above, pass, or fail) Note the under default "warn" mode, bus lock detect handler is disabled, handled by split lock handler. #wget http://linux-os.sc.intel.com/~fyu/projects/split_lock/tests/split_lock_test_user.c #gcc -o split_lock_test_user split_lock_test_user.c #./split_lock_test_user This test both split lock(cross cache line) and bus lock (explict lock instruction) [67152.780022] x86/split lock detection: #AC: split_lock_test/284139 took a split_lock trap at address: 0x4011ab (seeing this, pass, or fail) Modify the split_lock_test_user.c to only trigger bus lock with 64 bytes aligned WB cached memory + /* iptr = (int *)(cptr + 61); */ test_sigbus(iptr); free(cptr); return 0; } gcc -o split_lock_test_user split_lock_test_user.c #./split_lock_test_user #see dmesg, no warning message. Under your kernel source git repo directory. #git am 0001-x86-split-lock-vmdos-Test-split-lock-and-vmdos.patch #make #cd arch/x86/kernel/cpu/ #insmod ./test_split_lock_drv.ko Got following panic message and panic pass or fail. [ 327.415019] split lock test: split lock address=0xff722131cce07bbd [ 327.415025] Split lock detected : 0000 [#1] SMP NOPTI [ 327.415048] CPU: 46 PID: 4952 Comm: insmod Tainted: G S [ 327.415069] Hardware name: Intel Corporation EAGLESTREAM/EAGLESTREAM, [ 327.415093] RIP: 0010:init_module+0x40/0x85 [test_split_lock_drv] [ 327.415107] Code: ec c0 00 00 00 65 48 8b 04 25 28 00 00 00 48 89 84 24 b8 00 00 00 31 c0 48 8d 74 24 3d c7 44 24 3d 00 00 00 00 e8 22 41 b2 d8 0f ba 6c 24 3d 00 83 7c 24 3d 01 75 0e 48 c7 c7 70 50 42 c0 e8 [ 327.415156] RSP: 0018:ff722131cce07b80 EFLAGS: 00010246 [ 327.415801] RAX: 0000000000000036 RBX: ffffffffc0424000 RCX: 0000000000000000 [ 327.416431] RDX: 0000000000000000 RSI: ff1928e73ef98860 RDI: ff1928e73ef98860 [ 327.417052] RBP: ff722131cce07c68 R08: 0000000000000000 R09: c0000000fffeffff [ 327.417674] R10: 0000000000000001 R11: ff722131cce07950 R12: 0000000000000000 [ 327.418293] R13: ff722131cce07d68 R14: ff722131cce07e70 R15: ffffffffc0426000 [ 327.418907] FS: 00007fdb99824740(0000) GS:ff1928e73ef80000(0000) knlGS:0000000000000000 [ 327.419535] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 327.420169] CR2: 000055e9f3d8a068 CR3: 000000017cbbc003 CR4: 0000000000771ee0 [ 327.420808] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 327.421441] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Verify ratelimit (raltelimit implies the warn mode of bus lock detect with ratelimit feature) Append "split_lock_detect=ratelimit:2" to kernel command line See dmesg [ 0.000000] x86/split lock detection: #DB: setting system wide bus lock rate limit to 2/sec modify the split_lock_test_user.c to add while(1) loop, trigger bus lock forever without interval. void test_sigbus(int *iptr) { pid_t pid; pid = fork(); if (pid) return; /* * The locked instruction will trigger #AC and kernel will deliver * SIGBUS to this process. The SIGBUS handler in this process will * verify that the signal is delivered and the process is killed then. */ + while(1) do_split_locked_inst(iptr); } Re-run the ./split_lock_test see dmesg to know the warning message is limited to 2 times per second or fail. [ 1274.605344] x86/split lock detection: #DB: split_lock_test/23868 took a bus_lock trap at address: 0x4011af [ 1275.617334] x86/split lock detection: #DB: split_lock_test/23868 took a bus_lock trap at address: 0x4011af Fatal mode Append split_lock_detect=fatal to kernel command line see dmesg [ 0.000000] x86/split lock detection: #AC: crashing the kernel on kernel split_locks and sending SIGBUS on user-space split_locks Run #./split_lock_test ./split_lock_test_user Caught SIGBUS/#AC due to split locked access (seeing above message pass, or fail) #cd arch/x86/kernel/cpu/ #insmod ./test_split_lock_drv.ko Got following panic message and panic pass or fail. [ 327.415019] split lock test: split lock address=0xff722131cce07bbd [ 327.415025] Split lock detected : 0000 [#1] SMP NOPTI [ 327.415048] CPU: 46 PID: 4952 Comm: insmod Tainted: G S [ 327.415069] Hardware name: Intel Corporation EAGLESTREAM [ 327.415093] RIP: 0010:init_module+0x40/0x85 [test_split_lock_drv] [ 327.415107] Code: ec c0 00 00 00 65 48 8b 04 25 28 00 00 00 48 89 84 24 b8 00 00 00 31 c0 48 8d 74 24 3d c7 44 24 3d 00 00 00 00 e8 22 41 b2 d8 0f ba 6c 24 3d 00 83 7c 24 3d 01 75 0e 48 c7 c7 70 50 42 c0 e8 [ 327.415156] RSP: 0018:ff722131cce07b80 EFLAGS: 00010246 [ 327.415801] RAX: 0000000000000036 RBX: ffffffffc0424000 RCX: 0000000000000000 [ 327.416431] RDX: 0000000000000000 RSI: ff1928e73ef98860 RDI: ff1928e73ef98860 [ 327.417052] RBP: ff722131cce07c68 R08: 0000000000000000 R09: c0000000fffeffff [ 327.417674] R10: 0000000000000001 R11: ff722131cce07950 R12: 0000000000000000 [ 327.418293] R13: ff722131cce07d68 R14: ff722131cce07e70 R15: ffffffffc0426000 [ 327.418907] FS: 00007fdb99824740(0000) GS:ff1928e73ef80000(0000) knlGS:0000000000000000 [ 327.419535] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 327.420169] CR2: 000055e9f3d8a068 CR3: 000000017cbbc003 CR4: 0000000000771ee0 [ 327.420808] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 327.421441] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Known issue: No Default config change: No Thanks, Ethan Link:https://gitee.com/openeuler/kernel/pulls/53 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Liu Chao <liuchao173@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 05 8月, 2022 1 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @wuzheng_e61f This patch is to add Intel NTB LTR vendor support for gen4 NTB. Intel-kernel issue: https://gitee.com/openeuler/intel-kernel/issues/I5IZNI Test: 1.Using CEM to Occulink adapter(NTB hardware cards) for connecting two Sapphire Rapids. 2.set the right NTB port for matching the pcie port of CEM to Occulink adapter in BIOS. 3.Afer Intel NTB hardware is ready, please check the following link to test NTB in Linux. https://github.com/davejiang/linux/wiki/Intel-NTB-Startup-Guide Known issue: N/A Default config change: CONFIG_NTB_NETDEV=m CONFIG_NTB=m CONFIG_NTB_INTEL=m CONFIG_NTB_PINGPONG=m CONFIG_NTB_TOOL=m CONFIG_NTB_PERF=m CONFIG_NTB_TRANSPORT=m Link:https://gitee.com/openeuler/kernel/pulls/45 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Liu Chao <liuchao173@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 04 8月, 2022 24 次提交
-
-
由 Ziyang Xuan 提交于
mainline inclusion from mainline-v5.19 commit 85f0173d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5JW9C?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=85f0173df35e5462d89947135a6a5599c6c3ef6f ------------------------------- Change net device's MTU to smaller than IPV6_MIN_MTU or unregister device while matching route. That may trigger null-ptr-deref bug for ip6_ptr probability as following. ========================================================= BUG: KASAN: null-ptr-deref in find_match.part.0+0x70/0x134 Read of size 4 at addr 0000000000000308 by task ping6/263 CPU: 2 PID: 263 Comm: ping6 Not tainted 5.19.0-rc7+ #14 Call trace: dump_backtrace+0x1a8/0x230 show_stack+0x20/0x70 dump_stack_lvl+0x68/0x84 print_report+0xc4/0x120 kasan_report+0x84/0x120 __asan_load4+0x94/0xd0 find_match.part.0+0x70/0x134 __find_rr_leaf+0x408/0x470 fib6_table_lookup+0x264/0x540 ip6_pol_route+0xf4/0x260 ip6_pol_route_output+0x58/0x70 fib6_rule_lookup+0x1a8/0x330 ip6_route_output_flags_noref+0xd8/0x1a0 ip6_route_output_flags+0x58/0x160 ip6_dst_lookup_tail+0x5b4/0x85c ip6_dst_lookup_flow+0x98/0x120 rawv6_sendmsg+0x49c/0xc70 inet_sendmsg+0x68/0x94 Reproducer as following: Firstly, prepare conditions: $ip netns add ns1 $ip netns add ns2 $ip link add veth1 type veth peer name veth2 $ip link set veth1 netns ns1 $ip link set veth2 netns ns2 $ip netns exec ns1 ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1 $ip netns exec ns2 ip -6 addr add 2001:0db8:0:f101::2/64 dev veth2 $ip netns exec ns1 ifconfig veth1 up $ip netns exec ns2 ifconfig veth2 up $ip netns exec ns1 ip -6 route add 2000::/64 dev veth1 metric 1 $ip netns exec ns2 ip -6 route add 2001::/64 dev veth2 metric 1 Secondly, execute the following two commands in two ssh windows respectively: $ip netns exec ns1 sh $while true; do ip -6 addr add 2001:0db8:0:f101::1/64 dev veth1; ip -6 route add 2000::/64 dev veth1 metric 1; ping6 2000::2; done $ip netns exec ns1 sh $while true; do ip link set veth1 mtu 1000; ip link set veth1 mtu 1500; sleep 5; done It is because ip6_ptr has been assigned to NULL in addrconf_ifdown() firstly, then ip6_ignore_linkdown() accesses ip6_ptr directly without NULL check. cpu0 cpu1 fib6_table_lookup __find_rr_leaf addrconf_notify [ NETDEV_CHANGEMTU ] addrconf_ifdown RCU_INIT_POINTER(dev->ip6_ptr, NULL) find_match ip6_ignore_linkdown So we can add NULL check for ip6_ptr before using in ip6_ignore_linkdown() to fix the null-ptr-deref bug. Fixes: dcd1f572 ("net/ipv6: Remove fib6_idev") Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NDavid Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220728013307.656257-1-william.xuanziyang@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Hangyu Hua 提交于
stable inclusion from stable-v5.10.134 commit 47b696dd654450cdec3103a833e5bf29c4b83bfa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5JMHA CVE: CVE-2022-36879 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=47b696dd654450cdec3103a833e5bf29c4b83bfa -------------------------------- [ Upstream commit f85daf0e ] xfrm_policy_lookup() will call xfrm_pol_hold_rcu() to get a refcount of pols[0]. This refcount can be dropped in xfrm_expand_policies() when xfrm_expand_policies() return error. pols[0]'s refcount is balanced in here. But xfrm_bundle_lookup() will also call xfrm_pols_put() with num_pols == 1 to drop this refcount when xfrm_expand_policies() return error. This patch also fix an illegal address access. pols[0] will save a error point when xfrm_policy_lookup fails. This lead to xfrm_pols_put to resolve an illegal address in xfrm_bundle_lookup's error path. Fix these by setting num_pols = 0 in xfrm_expand_policies()'s error path. Fixes: 80c802f3 ("xfrm: cache bundles instead of policies for outgoing flows") Signed-off-by: NHangyu Hua <hbh25y@gmail.com> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pavel Skripkin 提交于
mainline inclusion from mainline-v5.19-rc8 commit 0ac4827f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I58DFB CVE: CVE-2022-1679 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ac4827f78c7ffe8eef074bc010e7e34bc22f533 -------------------------------- Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The problem was in incorrect htc_handle->drv_priv initialization. Probable call trace which can trigger use-after-free: ath9k_htc_probe_device() /* htc_handle->drv_priv = priv; */ ath9k_htc_wait_for_target() <--- Failed ieee80211_free_hw() <--- priv pointer is freed <IRQ> ... ath9k_hif_usb_rx_cb() ath9k_hif_usb_rx_stream() RX_STAT_INC() <--- htc_handle->drv_priv access In order to not add fancy protection for drv_priv we can move htc_handle->drv_priv initialization at the end of the ath9k_htc_probe_device() and add helper macro to make all *_STAT_* macros NULL safe, since syzbot has reported related NULL deref in that macros [1] Link: https://syzkaller.appspot.com/bug?id=6ead44e37afb6866ac0c7dd121b4ce07cb665f60 [0] Link: https://syzkaller.appspot.com/bug?id=b8101ffcec107c0567a0cd8acbbacec91e9ee8de [1] Fixes: fb9987d0 ("ath9k_htc: Support for AR9271 chipset.") Reported-and-tested-by: syzbot+03110230a11411024147@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+c6dde1f690b60e0b9fbe@syzkaller.appspotmail.com Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Acked-by: NToke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: NKalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/d57bbedc857950659bfacac0ab48790c1eda00c8.1655145743.git.paskripkin@gmail.comSigned-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhihao Cheng 提交于
hulk inclusion category: bugfix bugzilla: 187185, https://gitee.com/openeuler/kernel/issues/I5JAOC CVE: NA -------------------------------- Following process will fail assertion 'jh->b_frozen_data == NULL' in jbd2_journal_dirty_metadata(): jbd2_journal_commit_transaction unlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMIT unlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // return false --> jbd2 abort <-- while (commit_transaction->t_buffers) if (is_journal_aborted) jbd2_journal_refile_buffer __jbd2_journal_refile_buffer WRITE_ONCE(jh->b_transaction, jh->b_next_transaction) WRITE_ONCE(jh->b_next_transaction, NULL) __jbd2_journal_file_buffer(jh, BJ_Reserved) J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure ! The reproducer (See detail in [Link]) reports: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1629! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: unlink Tainted: G W 5.19.0-rc6-00115-g4a57a840-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Call Trace: <TASK> __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80 After journal aborting, __jbd2_journal_refile_buffer() is executed with holding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()' into the area protected by @jh->b_state_lock. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216251 Fixes: 470decc6 ("[PATCH] jbd2: initial copy of files from jbd") Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Haoyue Xu 提交于
mainline inclusion from mainline-for-next commit 2de949ab category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZO5 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=2de949abd6a539fac4b2c89a560e4ae505b6fb52 ---------------------------------------------------------------------- Since ECC memory maintains a memory system immune to single-bit errors, add support for correcting the 1bit-ECC error, which prevents a 1bit-ECC error become an uncorrected type error. When a 1bit-ECC error happens in the internal ram of the ROCE engine, such as the QPC table, as a 1bit-ECC error caused by reading, the ROCE engine only corrects those 1bit ECC errors by writing. Link: https://lore.kernel.org/r/20220714134353.16700-6-liangwenpeng@huawei.comSigned-off-by: NHaoyue Xu <xuhaoyue1@hisilicon.com> Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: NLeon Romanovsky <leon@kernel.org> Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Haoyue Xu 提交于
mainline inclusion from mainline-for-next commit 75e4e716 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZO5 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=75e4e716f7089558fda4ddc660fa8dbdec4eb1d3 ---------------------------------------------------------------------- Use a single function to handle the same kind of abnormal interrupts. Link: https://lore.kernel.org/r/20220714134353.16700-5-liangwenpeng@huawei.comSigned-off-by: NHaoyue Xu <xuhaoyue1@hisilicon.com> Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: NLeon Romanovsky <leon@kernel.org> Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Haoyue Xu 提交于
mainline inclusion from mainline-for-next commit ecb4db5c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZO5 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=ecb4db5c3590aa956b4b2c352081a5b632d1f9f9 ---------------------------------------------------------------------- The driver will clear all the interrupts in the same area when the driver handles the interrupt of type AEQ overflow. It should only set the interrupt status bit of type AEQ overflow. Fixes: a5073d60 ("RDMA/hns: Add eq support of hip08") Link: https://lore.kernel.org/r/20220714134353.16700-4-liangwenpeng@huawei.comSigned-off-by: NHaoyue Xu <xuhaoyue1@hisilicon.com> Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: NLeon Romanovsky <leon@kernel.org> Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Haoyue Xu 提交于
mainline inclusion from mainline-for-next commit d95e0a0c category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZO5 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=d95e0a0c6c9602ff6bb90c1c20987b204493d8e1 ---------------------------------------------------------------------- The type of return value of the interrupt handler should be irqreturn_t. Link: https://lore.kernel.org/r/20220714134353.16700-3-liangwenpeng@huawei.comSigned-off-by: NHaoyue Xu <xuhaoyue1@hisilicon.com> Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: NLeon Romanovsky <leon@kernel.org> Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Haoyue Xu 提交于
mainline inclusion from mainline-for-next commit f5c25465 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZO5 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=f5c25465b4f7d3badcaa5bf4a6f82f5763865b19 ---------------------------------------------------------------------- The HNS NIC driver receives and handles the abnormal interrupt of the RAS type generated by ROCEE, and the HNS RDMA driver does not need to handle this type of interrupt. Therefore, delete unused codes in the HNS RDMA driver. Link: https://lore.kernel.org/r/20220714134353.16700-2-liangwenpeng@huawei.comSigned-off-by: NHaoyue Xu <xuhaoyue1@hisilicon.com> Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: NLeon Romanovsky <leon@kernel.org> Signed-off-by: NZhengfeng Luo <luozhengfeng@h-partners.com> Reviewed-by: NYangyang Li <liyangyang20@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- When ext4_xattr_block_set() decides to remove xattr block the following race can happen: CPU1 CPU2 ext4_xattr_block_set() ext4_xattr_release_block() new_bh = ext4_xattr_block_cache_find() lock_buffer(bh); ref = le32_to_cpu(BHDR(bh)->h_refcount); if (ref == 1) { ... mb_cache_entry_delete(); unlock_buffer(bh); ext4_free_blocks(); ... ext4_forget(..., bh, ...); jbd2_journal_revoke(..., bh); ext4_journal_get_write_access(..., new_bh, ...) do_get_write_access() jbd2_journal_cancel_revoke(..., new_bh); Later the code in ext4_xattr_block_set() finds out the block got freed and cancels reusal of the block but the revoke stays canceled and so in case of block reuse and journal replay the filesystem can get corrupted. If the race works out slightly differently, we can also hit assertions in the jbd2 code. Fix the problem by making sure that once matching mbcache entry is found, code dropping the last xattr block reference (or trying to modify xattr block in place) waits until the mbcache entry reference is dropped. This way code trying to reuse xattr block is protected from someone trying to drop the last reference to xattr block. Reported-and-tested-by: NRitesh Harjani <ritesh.list@gmail.com> CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by: NJan Kara <jack@suse.cz> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Remove unnecessary else (and thus indentation level) from a code block in ext4_xattr_block_set(). It will also make following code changes easier. No functional changes. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by: NJan Kara <jack@suse.cz> Conflicts: fs/ext4/xattr.c [ 188c299e ("ext4: Support for checksumming from journal triggers") is not applied. ] Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Currently we remove EA inode from mbcache as soon as its xattr refcount drops to zero. However there can be pending attempts to reuse the inode and thus refcount handling code has to handle the situation when refcount increases from zero anyway. So save some work and just keep EA inode in mbcache until it is getting evicted. At that moment we are sure following iget() of EA inode will fail anyway (or wait for eviction to finish and load things from the disk again) and so removing mbcache entry at that moment is fine and simplifies the code a bit. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by: NJan Kara <jack@suse.cz> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Add function mb_cache_entry_delete_or_get() to delete mbcache entry if it is unused and also add a function to wait for entry to become unused - mb_cache_entry_wait_unused(). We do not share code between the two deleting function as one of them will go away soon. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by: NJan Kara <jack@suse.cz> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Do not reclaim entries that are currently used by somebody from a shrinker. Firstly, these entries are likely useful. Secondly, we will need to keep such entries to protect pending increment of xattr block refcount. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by: NJan Kara <jack@suse.cz> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.12-rc1 commit e82ed3a4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I587H6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e82ed3a4fbb54b2d7dcb2a7733520f3e10b97abf ------------------------------- Refactor raid5_read_one_chunk so that all simple checks are done before allocating the bio. Signed-off-by: NChristoph Hellwig <hch@lst.de> Acked-by: NSong Liu <song@kernel.org> Reviewed-by: NJohannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Acked-by: NDamien Le Moal <damien.lemoal@wdc.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflict: drivers/md/raid5.c Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guoqing Jiang 提交于
mainline inclusion from mainline-v5.14-rc1 commit 528bc2cf category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I587H6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=528bc2cf2fccef2c2c17263f9932094bf81fee5a ------------------------------- For raid10, we record the start time between split bio and clone bio, and finish the accounting in the final endio. Also introduce start_time in r10bio accordingly. Signed-off-by: NGuoqing Jiang <jiangguoqing@kylinos.cn> Signed-off-by: NSong Liu <song@kernel.org> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guoqing Jiang 提交于
mainline inclusion from mainline-v5.14-rc1 commit a0159832 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I587H6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a0159832e51e3af03b89ecc5d6b9db451e529b5f ------------------------------- For raid1, we record the start time between split bio and clone bio, and finish the accounting in the final endio. Also introduce start_time in r1bio accordingly. Signed-off-by: NGuoqing Jiang <jiangguoqing@kylinos.cn> Signed-off-by: NSong Liu <song@kernel.org> Conflict: drivers/md/raid1.c Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guoqing Jiang 提交于
mainline inclusion from mainline-v5.14-rc1 commit 9b8ae7b9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I587H6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b8ae7b938235229ccb112c4e887ff1bcc232836 ------------------------------- The caller of raid1_read_request could pass NULL or a valid pointer for "struct r1bio *r1_bio", so it actually means whether r1_bio is existed or not. Signed-off-by: NGuoqing Jiang <jiangguoqing@kylinos.cn> Signed-off-by: NSong Liu <song@kernel.org> Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guoqing Jiang 提交于
mainline inclusion from mainline-v5.14-rc1 commit 1147f58e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I587H6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1147f58e1010b8688bac1fd3bbab753b1379291d ------------------------------- After enable io accounting, chunk read bio could be cloned twice which is not good. To avoid such inefficiency, let's clone align_bio from io_acct_set too, then we need only call md_account_bio in make_request unconditionally. Signed-off-by: NGuoqing Jiang <jiangguoqing@kylinos.cn> Signed-off-by: NSong Liu <song@kernel.org> Conflict: drivers/md/raid5.c Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Guoqing Jiang 提交于
mainline inclusion from mainline-v5.14-rc1 commit 10764815 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I587H6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=10764815ff4728d2c57da677cd5d3dd6f446cf5f ------------------------------- We introduce a new bioset (io_acct_set) for raid0 and raid5 since they don't own clone infrastructure to accounting io. And the bioset is added to mddev instead of to raid0 and raid5 layer, because with this way, we can put common functions to md.h and reuse them in raid0 and raid5. Also struct md_io_acct is added accordingly which includes io start_time, the origin bio and cloned bio. Then we can call bio_{start,end}_io_acct to get related io status. Signed-off-by: NGuoqing Jiang <jiangguoqing@kylinos.cn> Signed-off-by: NSong Liu <song@kernel.org> Conflict: drivers/md/md.c drivers/md/md.h Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ricky WU 提交于
stable inclusion from stable-v5.10.115 commit 8528806abed5a759ce2061206d5152a89350ef63 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZ9C Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8528806abed5a759ce2061206d5152a89350ef63 -------------------------------- commit 1f311c94 upstream. SD spec definition: "Host provides at least 74 Clocks before issuing first command" After 1ms for the voltage stable then start issuing the Clock signals if POWER STATE is MMC_POWER_OFF to MMC_POWER_UP to issue Clock signal to card MMC_POWER_UP to MMC_POWER_ON to stop issuing signal to card Signed-off-by: NRicky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/1badf10aba764191a1a752edcbf90389@realtek.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChristian Loehle <cloehle@hyperstone.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Pali Rohár 提交于
stable inclusion from stable-v5.10.115 commit e1ab92302b4460416edbe473064a3dc1b5e0ec4f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZ9C Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e1ab92302b4460416edbe473064a3dc1b5e0ec4f -------------------------------- commit 805dfc18 upstream. In advk_pcie_handle_msi() it is expected that when bit i in the W1C register PCIE_MSI_STATUS_REG is cleared, the PCIE_MSI_PAYLOAD_REG is updated to contain the MSI number corresponding to index i. Experiments show that this is not so, and instead PCIE_MSI_PAYLOAD_REG always contains the number of the last received MSI, overall. Do not read PCIE_MSI_PAYLOAD_REG register for determining MSI interrupt number. Since Aardvark already forbids more than 32 interrupts and uses own allocated hwirq numbers, the msi_idx already corresponds to the received MSI number. Link: https://lore.kernel.org/r/20220110015018.26359-3-kabel@kernel.org Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NMarek Behún <kabel@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NMarek Behún <kabel@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Pali Rohár 提交于
stable inclusion from stable-v5.10.115 commit 49143c9ed2326f98651aed6f376cfa3369c38bb3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZ9C Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=49143c9ed2326f98651aed6f376cfa3369c38bb3 -------------------------------- commit 7d8dc1f7 upstream. We already clear all the other interrupts (ISR0, ISR1, HOST_CTRL_INT). Define a new macro PCIE_MSI_ALL_MASK and do the same clearing for MSIs, to ensure that we don't start receiving spurious interrupts. Use this new mask in advk_pcie_handle_msi(); Link: https://lore.kernel.org/r/20211130172913.9727-5-kabel@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NMarek Behún <kabel@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mike Snitzer 提交于
stable inclusion from stable-v5.10.115 commit 7676a5b99f3da170d42d3e457cd7ff8c82001dd1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IZ9C Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7676a5b99f3da170d42d3e457cd7ff8c82001dd1 -------------------------------- commit 9f6dc633 upstream. Commit d208b894 ("dm: fix mempool NULL pointer race when completing IO") didn't go far enough. When bio_end_io_acct ends the count of in-flight I/Os may reach zero and the DM device may be suspended. There is a possibility that the suspend races with dm_stats_account_io. Fix this by adding percpu "pending_io" counters to track outstanding dm_io. Move kicking of suspend queue to dm_io_dec_pending(). Also, rename md_in_flight_bios() to dm_in_flight_bios() and update it to iterate all pending_io counters. Fixes: d208b894 ("dm: fix mempool NULL pointer race when completing IO") Cc: stable@vger.kernel.org Co-developed-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-