- Kernel - mailweb.openeuler.org

[PATCH openEuler-21.09 01/38] crypto: hisilicon/sec - fix the process of disabling sva prefetching
by Zheng Zengkai 04 Sep '21

04 Sep '21

From: Kai Ye <yekai13(a)huawei.com> mainline inclusion from mainline-master commit 66192b2e3fd8ab97ed518d6c0240e26655a20b4b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I475XT?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/d… ---------------------------------------------------------------------- The open interface of the sva prefetching function is distinguish the chip version. But the close interface of the sva prefetching function doesn't distinguish the chip version. As a result, the sva prefetching close operation is also performed on Kunpeng920, those registers are important on Kunpeng920, which eventually leads to abnormal hardware problems. So need to fix it immediately. Signed-off-by: Kai Ye <yekai13(a)huawei.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Reviewed-by: Hao Fang <fanghao11(a)huawei.com> Reviewed-by: Mingqiang Ling <lingmingqiang(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> --- drivers/crypto/hisilicon/sec2/sec_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/hisilicon/sec2/sec_main.c b/drivers/crypto/hisilicon/sec2/sec_main.c index d120ce3e34ed..490db7bccf61 100644 --- a/drivers/crypto/hisilicon/sec2/sec_main.c +++ b/drivers/crypto/hisilicon/sec2/sec_main.c @@ -364,6 +364,9 @@ static void sec_close_sva_prefetch(struct hisi_qm *qm) u32 val; int ret; + if (qm->ver < QM_HW_V3) + return; + val = readl_relaxed(qm->io_base + SEC_PREFETCH_CFG); val |= SEC_PREFETCH_DISABLE; writel(val, qm->io_base + SEC_PREFETCH_CFG); -- 2.20.1

1 37

[PATCH kernel-4.19] itrace: add missing itrace_hardirqs_ignore() calls
by Yang Yingliang 03 Sep '21

03 Sep '21

From: Bixuan Cui <cuibixuan(a)huawei.com> ascend inclusion category: bugfix bugzilla: NA CVE: NA --------------------------------------------- There is an anomalous statistics in itrace irqsoff: max_time:3945(us) caller:__do_softirq+0x8c/0x310 max_time:7996(us) caller:__do_softirq+0x8c/0x310 Use function tracer to trace: stress-ng-cpu-3723 [011] d... 2817.510377: rcu_nmi_exit <-rcu_irq_exit stress-ng-cpu-3723 [011] d... 2817.510377: rcu_dynticks_curr_cpu_in_eqs <-rcu_nmi_exit stress-ng-cpu-3723 [011] d... 2817.514356: gic_handle_irq <-el0_irq_naked stress-ng-cpu-3723 [011] d... 2817.514356: __handle_domain_irq <-gic_handle_irq ... The per-cpu interrupt is enabled after irq_handler in el0_irq_naked() is executed. However, the itrace does not add the irqsoff monitoring to el0_irq_naked. And the same omission appears in the following files: arch/arm64/include/asm/daifflags.h arch/arm64/kernel/entry.S arch/arm64/kernel/syscall.c arch/arm64/mm/fault.c Add missing itrace_hardirqs_ignore() calls into it. Signed-off-by: Bixuan Cui <cuibixuan(a)huawei.com> Reviewed-by: Ding Tianhong <dingtianhong(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/arm64/include/asm/daifflags.h | 3 +++ arch/arm64/kernel/entry.S | 9 +++++++++ arch/arm64/kernel/syscall.c | 3 +++ arch/arm64/mm/fault.c | 6 +++++- 4 files changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h index 1230923b032dd..1d832814eae8f 100644 --- a/arch/arm64/include/asm/daifflags.h +++ b/arch/arm64/include/asm/daifflags.h @@ -72,6 +72,9 @@ static inline void local_daif_restore(unsigned long flags) if (!irq_disabled) { trace_hardirqs_on(); +#ifdef CONFIG_ITRACE_IRQSOFF + itrace_hardirqs_ignore(); +#endif if (system_uses_irq_prio_masking()) { gic_write_pmr(GIC_PRIO_IRQON); diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 2eb1b657de2fb..2c9b8d94d3677 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -718,6 +718,9 @@ alternative_else_nop_endif #endif bl trace_hardirqs_on 1: +#endif +#ifdef CONFIG_ITRACE_IRQSOFF + bl itrace_hardirqs_ignore #endif kernel_exit 1 @@ -954,6 +957,9 @@ el0_irq_naked: #ifdef CONFIG_TRACE_IRQFLAGS bl trace_hardirqs_on +#endif +#ifdef CONFIG_ITRACE_IRQSOFF + bl itrace_hardirqs_ignore #endif b ret_to_user ENDPROC(el0_irq) @@ -989,6 +995,9 @@ work_pending: bl do_notify_resume #ifdef CONFIG_TRACE_IRQFLAGS bl trace_hardirqs_on // enabled while in userspace +#endif +#ifdef CONFIG_ITRACE_IRQSOFF + bl itrace_hardirqs_ignore #endif ldr x1, [tsk, #TSK_TI_FLAGS] // re-check for single-step b finish_ret_to_user diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c index f2d2dbbbfca20..964df44d7429a 100644 --- a/arch/arm64/kernel/syscall.c +++ b/arch/arm64/kernel/syscall.c @@ -131,6 +131,9 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr, * the SPSR. */ trace_hardirqs_on(); +#ifdef CONFIG_ITRACE_IRQSOFF + itrace_hardirqs_ignore(); +#endif return; } local_daif_restore(DAIF_PROCCTX); diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index 08040fe73199a..4e7aaa658d636 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -1094,8 +1094,12 @@ asmlinkage int __exception do_debug_exception(unsigned long addr_if_watchpoint, rv = 0; } - if (interrupts_enabled(regs)) + if (interrupts_enabled(regs)) { trace_hardirqs_on(); +#ifdef CONFIG_ITRACE_IRQSOFF + itrace_hardirqs_ignore(); +#endif + } return rv; } -- 2.25.1

1 0

[PATCH kernel-4.19 1/3] mm/filemap.c: fix a data race in filemap_fault()
by Yang Yingliang 03 Sep '21

03 Sep '21

From: "Kirill A. Shutemov" <kirill(a)shutemov.name> mainline inclusion from mainline-v5.9-rc1 commit e630bfac79456d3acd22c9286b50e83aafb7a07c category: bugfix bugzilla: 41542 CVE: NA ----------------------------------------------- struct file_ra_state ra.mmap_miss could be accessed concurrently during page faults as noticed by KCSAN, BUG: KCSAN: data-race in filemap_fault / filemap_map_pages write to 0xffff9b1700a2c1b4 of 4 bytes by task 3292 on cpu 30: filemap_fault+0x920/0xfc0 do_sync_mmap_readahead at mm/filemap.c:2384 (inlined by) filemap_fault at mm/filemap.c:2486 __xfs_filemap_fault+0x112/0x3e0 [xfs] xfs_filemap_fault+0x74/0x90 [xfs] __do_fault+0x9e/0x220 do_fault+0x4a0/0x920 __handle_mm_fault+0xc69/0xd00 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x6f9 page_fault+0x34/0x40 read to 0xffff9b1700a2c1b4 of 4 bytes by task 3313 on cpu 32: filemap_map_pages+0xc2e/0xd80 filemap_map_pages at mm/filemap.c:2625 do_fault+0x3da/0x920 __handle_mm_fault+0xc69/0xd00 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x6f9 page_fault+0x34/0x40 Reported by Kernel Concurrency Sanitizer on: CPU: 32 PID: 3313 Comm: systemd-udevd Tainted: G W L 5.5.0-next-20200210+ #1 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 ra.mmap_miss is used to contribute the readahead decisions, a data race could be undesirable. Both the read and write is only under non-exclusive mmap_sem, two concurrent writers could even underflow the counter. Fix the underflow by writing to a local variable before committing a final store to ra.mmap_miss given a small inaccuracy of the counter should be acceptable. Signed-off-by: Kirill A. Shutemov <kirill(a)shutemov.name> Signed-off-by: Qian Cai <cai(a)lca.pw> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Tested-by: Qian Cai <cai(a)lca.pw> Reviewed-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Marco Elver <elver(a)google.com> Link: http://lkml.kernel.org/r/20200211030134.1847-1-cai@lca.pw Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: mm/filemap.c [Peng Liu: cherry-pick from e630bfac79456d3acd22c9286b50e83aafb7a07c] Signed-off-by: Peng Liu <liupeng256(a)huawei.com> Reviewed-by: tong tiangen <tongtiangen(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- mm/filemap.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 5c33c40e80192..4cf4b096d5b63 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2528,6 +2528,7 @@ static void do_sync_mmap_readahead(struct vm_area_struct *vma, pgoff_t offset) { struct address_space *mapping = file->f_mapping; + unsigned int mmap_miss; /* If we don't want any read-ahead, don't bother */ if (vma->vm_flags & VM_RAND_READ) @@ -2542,14 +2543,15 @@ static void do_sync_mmap_readahead(struct vm_area_struct *vma, } /* Avoid banging the cache line if not needed */ - if (ra->mmap_miss < MMAP_LOTSAMISS * 10) - ra->mmap_miss++; + mmap_miss = READ_ONCE(ra->mmap_miss); + if (mmap_miss < MMAP_LOTSAMISS * 10) + WRITE_ONCE(ra->mmap_miss, ++mmap_miss); /* * Do we miss much more than hit in this file? If so, * stop bothering with read-ahead. It will only hurt. */ - if (ra->mmap_miss > MMAP_LOTSAMISS) + if (mmap_miss > MMAP_LOTSAMISS) return; /* @@ -2572,12 +2574,14 @@ static void do_async_mmap_readahead(struct vm_area_struct *vma, pgoff_t offset) { struct address_space *mapping = file->f_mapping; + unsigned int mmap_miss; /* If we don't want any read-ahead, don't bother */ if (vma->vm_flags & VM_RAND_READ) return; - if (ra->mmap_miss > 0) - ra->mmap_miss--; + mmap_miss = READ_ONCE(ra->mmap_miss); + if (mmap_miss) + WRITE_ONCE(ra->mmap_miss, --mmap_miss); if (PageReadahead(page)) page_cache_async_readahead(mapping, ra, file, page, offset, ra->ra_pages); @@ -2737,6 +2741,7 @@ void filemap_map_pages(struct vm_fault *vmf, pgoff_t last_pgoff = start_pgoff; unsigned long max_idx; struct page *head, *page; + unsigned int mmap_miss = READ_ONCE(file->f_ra.mmap_miss); rcu_read_lock(); radix_tree_for_each_slot(slot, &mapping->i_pages, &iter, start_pgoff) { @@ -2784,8 +2789,8 @@ void filemap_map_pages(struct vm_fault *vmf, if (page->index >= max_idx) goto unlock; - if (file->f_ra.mmap_miss > 0) - file->f_ra.mmap_miss--; + if (mmap_miss > 0) + mmap_miss--; vmf->address += (iter.index - last_pgoff) << PAGE_SHIFT; if (vmf->pte) @@ -2807,6 +2812,7 @@ void filemap_map_pages(struct vm_fault *vmf, break; } rcu_read_unlock(); + WRITE_ONCE(file->f_ra.mmap_miss, mmap_miss); } EXPORT_SYMBOL(filemap_map_pages); -- 2.25.1

1 2

[PATCH kernel-4.19 1/5] share_pool: Add compact switch for vmalloc_huge* funcs
by Yang Yingliang 03 Sep '21

03 Sep '21

From: Tang Yizhou <tangyizhou(a)huawei.com> ascend inclusion category: bugfix bugzilla: NA CVE: NA ------------------------------------------------- Let memory compact to be configurable. Signed-off-by: Tang Yizhou <tangyizhou(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- mm/share_pool.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/share_pool.c b/mm/share_pool.c index e5a71e25964c1..ea2ea37111b9c 100644 --- a/mm/share_pool.c +++ b/mm/share_pool.c @@ -3226,6 +3226,7 @@ struct page *sp_alloc_pages(struct vm_struct *area, gfp_t mask, noreclaim_flag = memalloc_noreclaim_save(); page = hugetlb_alloc_hugepage(NUMA_NO_NODE, HUGETLB_ALLOC_NONE); memalloc_noreclaim_restore(noreclaim_flag); + sp_try_to_compact(); return page; } else return alloc_pages_node(node, mask, page_order); -- 2.25.1

1 4

[PATCH kernel-4.19] scsi/hifc: Fix memory leakage bug
by Yang Yingliang 03 Sep '21

03 Sep '21

From: chenguangli <chenguangli2(a)huawei.com> driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I47Z9P ------------------------------------------------------------------- The memory will be leaked when driver set the port_poto_cfg invalid value. Signed-off-by: chenguangli <chenguangli2(a)huawei.com> Reviewed-by: baowenyi <baowenyi(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/scsi/huawei/hifc/hifc_chipitf.c | 2 +- drivers/scsi/huawei/hifc/unf_common.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/huawei/hifc/hifc_chipitf.c b/drivers/scsi/huawei/hifc/hifc_chipitf.c index fe97f64685570..74e3df2fe8605 100644 --- a/drivers/scsi/huawei/hifc/hifc_chipitf.c +++ b/drivers/scsi/huawei/hifc/hifc_chipitf.c @@ -369,7 +369,7 @@ unsigned int hifc_config_port_table(struct hifc_hba_s *v_hba) v_hba->port_cfg.port_id, (unsigned char)v_hba->port_topo_cfg); - return UNF_RETURN_ERROR; + goto exit; } /* About speed */ diff --git a/drivers/scsi/huawei/hifc/unf_common.h b/drivers/scsi/huawei/hifc/unf_common.h index bc11cc542c56d..9253cc3eada53 100644 --- a/drivers/scsi/huawei/hifc/unf_common.h +++ b/drivers/scsi/huawei/hifc/unf_common.h @@ -13,7 +13,7 @@ /* B version, B0XX Corresponding x.x */ #define UNF_B_VERSION "5.0" /* Indicates the minor version number of the driver */ -#define UNF_DRIVER_VERSION "11" +#define UNF_DRIVER_VERSION "12" /* version num */ #define UNF_FC_VERSION UNF_MAJOR_VERSION "." UNF_B_VERSION "." UNF_DRIVER_VERSION extern unsigned int unf_dbg_level; -- 2.25.1

2 1

[PATCH kernel-4.19 01/16] RDMA/hns: Fix an cmd queue issue when resetting
by Yang Yingliang 02 Sep '21

02 Sep '21

From: Shunfeng Yang <yangshunfeng2(a)huawei.com> mainline inclusion from mainline-v5.8 commit 3ec5f54f7a0f category: bugfix bugzilla: NA CVE: NA The hns NIC driver divides the reset process into 3 status: initialization, hardware resetting and softwaring restting. RoCE driver gets reset status by interfaces provided by NIC driver and commands will not be sent to the IMP if the driver is in any above status. The main reason for this issue is that there is a time gap between status 1 and 2, if the RoCE driver sends commands to the IMP during this gap, the IMP will stop working because it is not ready. Signed-off-by: Shunfeng Yang <yangshunfeng2(a)huawei.com> Signed-off-by: Yangyang Li <liyangyang20(a)huawei.com> Reviewed-by: chunzhi hu <huchunzhi(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index 07932c1e029ab..eb9654707a213 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -957,7 +957,7 @@ static int hns_roce_v2_rst_process_cmd(struct hns_roce_dev *hr_dev) instance_stage = handle->rinfo.instance_state; reset_stage = handle->rinfo.reset_state; reset_cnt = ops->ae_dev_reset_cnt(handle); - hw_resetting = ops->get_hw_reset_stat(handle); + hw_resetting = ops->get_cmdq_stat(handle); sw_resetting = ops->ae_dev_resetting(handle); if (reset_cnt != hr_dev->reset_cnt) -- 2.25.1

1 15

【Meeting Notice】openEuler kernel 技术分享第十一期 & 双周例会 Time: 2021-09-03 14:00-17:00
by Meeting Book 02 Sep '21

02 Sep '21

1 0

[PATCH openEuler-21.03] MPAM/ACPI: add return value check for acpi_get_table
by mpiglet 02 Sep '21

02 Sep '21

openEuler inclusion category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=339 CVE: NA Reference: https://gitee.com/openeuler/kernel/issues/I3U11D --------------------------------------------------- This fix check return value of acpi_get_table. Fixes: MPAM driver need to check return value, thus we need to check the return value of acpi_get_table(ACPI_SIG_PPTT, 0, &pptt) Signed-off-by: mpiglet <mpiglet(a)outlook.com> --- drivers/acpi/arm64/mpam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c index 6c238f5a5c5a..fe870605f652 100644 --- a/drivers/acpi/arm64/mpam.c +++ b/drivers/acpi/arm64/mpam.c @@ -255,7 +255,7 @@ int __init acpi_mpam_parse(void) return -ENOENT; /* PPTT is optional, there may be no mpam cache controls */ - acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); + status = acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); if (ACPI_FAILURE(status)) pptt = NULL; -- 2.27.0

1 0

[PATCH openEuler-21.03] MPAM/ACPI: add return value check for acpi_get_table
by mpiglet 01 Sep '21

01 Sep '21

openEuler inclusion category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=339 CVE: NA Reference: https://gitee.com/openeuler/kernel/issues/I3U11D --------------------------------------------------- Signed-off-by: mpiglet <mpiglet(a)outlook.com> --- drivers/acpi/arm64/mpam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c index 6c238f5a5c5a..fe870605f652 100644 --- a/drivers/acpi/arm64/mpam.c +++ b/drivers/acpi/arm64/mpam.c @@ -255,7 +255,7 @@ int __init acpi_mpam_parse(void) return -ENOENT; /* PPTT is optional, there may be no mpam cache controls */ - acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); + status = acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); if (ACPI_FAILURE(status)) pptt = NULL; -- 2.27.0

1 0

openEuler inclusion category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=339 CVE: NA Reference: https://gitee.com/openeuler/kernel/issues/I3U11D
by mpiglet 01 Sep '21

01 Sep '21

--------------------------------------------------- From 1f1b7a2256db5e829cd03f8e4e382b1fbe36802a Mon Sep 17 00:00:00 2001 From: mpiglet <mpiglet(a)outlook.com> Date: Tue, 31 Aug 2021 00:51:42 +0800 Subject: [PATCH openEuler-21.03] add return value check for acpi_get_table Signed-off-by: mpiglet <mpiglet(a)outlook.com> --- drivers/acpi/arm64/mpam.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c index 6c238f5a5c5a..fe870605f652 100644 --- a/drivers/acpi/arm64/mpam.c +++ b/drivers/acpi/arm64/mpam.c @@ -255,7 +255,7 @@ int __init acpi_mpam_parse(void) return -ENOENT; /* PPTT is optional, there may be no mpam cache controls */ - acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); + status = acpi_get_table(ACPI_SIG_PPTT, 0, &pptt); if (ACPI_FAILURE(status)) pptt = NULL; -- 2.27.0

1 0