mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 53 participants
  • 18751 discussions
[PATCH openEuler-22.03-LTS-SP1] drm/lima: fix a memleak in lima_heap_alloc
by Guo Mengqi 17 Oct '24

17 Oct '24
From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit f2e80ac9344aebbff576453d5c0290b332e187ed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q978 CVE: CVE-2024-35829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 04ae3eb470e52a3c41babe85ff8cee195e4dcbea ] When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks. Fixes: 6aebc51d7aef ("drm/lima: support heap buffer creation") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Qiang Yu <yuq825(a)gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117071328.3811480-1-alex… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/gpu/drm/lima/lima_gem.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c index 11223fe348df..894175f2ed49 100644 --- a/drivers/gpu/drm/lima/lima_gem.c +++ b/drivers/gpu/drm/lima/lima_gem.c @@ -74,29 +74,34 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm) } else { bo->base.sgt = kmalloc(sizeof(*bo->base.sgt), GFP_KERNEL); if (!bo->base.sgt) { - sg_free_table(&sgt); - return -ENOMEM; + ret = -ENOMEM; + goto err_out0; } } ret = dma_map_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); - if (ret) { - sg_free_table(&sgt); - kfree(bo->base.sgt); - bo->base.sgt = NULL; - return ret; - } + if (ret) + goto err_out1; *bo->base.sgt = sgt; if (vm) { ret = lima_vm_map_bo(vm, bo, old_size >> PAGE_SHIFT); if (ret) - return ret; + goto err_out2; } bo->heap_size = new_size; return 0; + +err_out2: + dma_unmap_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); +err_out1: + kfree(bo->base.sgt); + bo->base.sgt = NULL; +err_out0: + sg_free_table(&sgt); + return ret; } int lima_gem_create_handle(struct drm_device *dev, struct drm_file *file, -- 2.17.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] octeontx2-af: Use separate handlers for interrupts
by Guo Mengqi 17 Oct '24

17 Oct '24
From: Subbaraya Sundeep <sbhatta(a)marvell.com> stable inclusion from stable-v5.10.214 commit 766c2627acb2d9d1722cce2e24837044d52d888a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9N9 CVE: CVE-2024-27030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ] For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data. Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers") Signed-off-by: Subbaraya Sundeep <sbhatta(a)marvell.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c index c26652436c53..5465a80e8973 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c @@ -1885,10 +1885,9 @@ static void rvu_queue_work(struct mbox_wq_info *mw, int first, } } -static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +static irqreturn_t rvu_mbox_pf_intr_handler(int irq, void *rvu_irq) { struct rvu *rvu = (struct rvu *)rvu_irq; - int vfs = rvu->vfs; u64 intr; intr = rvu_read64(rvu, BLKADDR_RVUM, RVU_AF_PFAF_MBOX_INT); @@ -1902,6 +1901,18 @@ static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) rvu_queue_work(&rvu->afpf_wq_info, 0, rvu->hw->total_pfs, intr); + return IRQ_HANDLED; +} + +static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +{ + struct rvu *rvu = (struct rvu *)rvu_irq; + int vfs = rvu->vfs; + u64 intr; + + /* Sync with mbox memory region */ + rmb(); + /* Handle VF interrupts */ if (vfs > 64) { intr = rvupf_read64(rvu, RVU_PF_VFPF_MBOX_INTX(1)); @@ -2216,7 +2227,7 @@ static int rvu_register_interrupts(struct rvu *rvu) /* Register mailbox interrupt handler */ sprintf(&rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], "RVUAF Mbox"); ret = request_irq(pci_irq_vector(rvu->pdev, RVU_AF_INT_VEC_MBOX), - rvu_mbox_intr_handler, 0, + rvu_mbox_pf_intr_handler, 0, &rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], rvu); if (ret) { dev_err(rvu->dev, -- 2.17.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] media: go7007: fix a memleak in go7007_load_encoder
by Guo Mengqi 17 Oct '24

17 Oct '24
From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit b49fe84c6cefcc1c2336d793b53442e716c95073 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9IB CVE: CVE-2024-27074 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b9b683844b01d171a72b9c0419a2d760d946ee12 ] In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. Fixes: 95ef39403f89 ("[media] go7007: remember boot firmware") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/media/usb/go7007/go7007-driver.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/usb/go7007/go7007-driver.c b/drivers/media/usb/go7007/go7007-driver.c index 6650eab913d8..3c66542ce284 100644 --- a/drivers/media/usb/go7007/go7007-driver.c +++ b/drivers/media/usb/go7007/go7007-driver.c @@ -80,7 +80,7 @@ static int go7007_load_encoder(struct go7007 *go) const struct firmware *fw_entry; char fw_name[] = "go7007/go7007fw.bin"; void *bounce; - int fw_len, rv = 0; + int fw_len; u16 intr_val, intr_data; if (go->boot_fw == NULL) { @@ -109,9 +109,11 @@ static int go7007_load_encoder(struct go7007 *go) go7007_read_interrupt(go, &intr_val, &intr_data) < 0 || (intr_val & ~0x1) != 0x5a5a) { v4l2_err(go, "error transferring firmware\n"); - rv = -1; + kfree(go->boot_fw); + go->boot_fw = NULL; + return -1; } - return rv; + return 0; } MODULE_FIRMWARE("go7007/go7007fw.bin"); -- 2.17.1
2 1
0 0
[PATCH OLK-5.10] octeontx2-af: Use separate handlers for interrupts
by Guo Mengqi 17 Oct '24

17 Oct '24
From: Subbaraya Sundeep <sbhatta(a)marvell.com> stable inclusion from stable-v5.10.214 commit 766c2627acb2d9d1722cce2e24837044d52d888a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9N9 CVE: CVE-2024-27030 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 50e60de381c342008c0956fd762e1c26408f372c ] For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data. Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers") Signed-off-by: Subbaraya Sundeep <sbhatta(a)marvell.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c index acbc67074f59..23b829f974de 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c @@ -1969,10 +1969,9 @@ static void rvu_queue_work(struct mbox_wq_info *mw, int first, } } -static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +static irqreturn_t rvu_mbox_pf_intr_handler(int irq, void *rvu_irq) { struct rvu *rvu = (struct rvu *)rvu_irq; - int vfs = rvu->vfs; u64 intr; intr = rvu_read64(rvu, BLKADDR_RVUM, RVU_AF_PFAF_MBOX_INT); @@ -1986,6 +1985,18 @@ static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) rvu_queue_work(&rvu->afpf_wq_info, 0, rvu->hw->total_pfs, intr); + return IRQ_HANDLED; +} + +static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq) +{ + struct rvu *rvu = (struct rvu *)rvu_irq; + int vfs = rvu->vfs; + u64 intr; + + /* Sync with mbox memory region */ + rmb(); + /* Handle VF interrupts */ if (vfs > 64) { intr = rvupf_read64(rvu, RVU_PF_VFPF_MBOX_INTX(1)); @@ -2300,7 +2311,7 @@ static int rvu_register_interrupts(struct rvu *rvu) /* Register mailbox interrupt handler */ sprintf(&rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], "RVUAF Mbox"); ret = request_irq(pci_irq_vector(rvu->pdev, RVU_AF_INT_VEC_MBOX), - rvu_mbox_intr_handler, 0, + rvu_mbox_pf_intr_handler, 0, &rvu->irq_name[RVU_AF_INT_VEC_MBOX * NAME_SIZE], rvu); if (ret) { dev_err(rvu->dev, -- 2.17.1
2 1
0 0
[PATCH OLK-6.6] drm/amd/display: Ensure index calculation will not overflow
by Tong Tiangen 17 Oct '24

17 Oct '24
From: Alex Hung <alex.hung(a)amd.com> stable inclusion from stable-v6.6.50 commit 3dc6bb57dab36b38b7374af0ac916174c146b6ed category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IARV8L CVE: CVE-2024-46726 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8e2734bf444767fed787305ccdcb36a2be5301a2 ] [WHY & HOW] Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will never overflow and exceess array size. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Tom Chung <chiahsuan.chung(a)amd.com> Signed-off-by: Alex Hung <alex.hung(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c index 50b0434354f8..c08169de3660 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c +++ b/drivers/gpu/drm/amd/display/dc/dml/calcs/dcn_calcs.c @@ -1453,10 +1453,9 @@ void dcn_bw_update_from_pplib_fclks( ASSERT(fclks->num_levels); vmin0p65_idx = 0; - vmid0p72_idx = fclks->num_levels - - (fclks->num_levels > 2 ? 3 : (fclks->num_levels > 1 ? 2 : 1)); - vnom0p8_idx = fclks->num_levels - (fclks->num_levels > 1 ? 2 : 1); - vmax0p9_idx = fclks->num_levels - 1; + vmid0p72_idx = fclks->num_levels > 2 ? fclks->num_levels - 3 : 0; + vnom0p8_idx = fclks->num_levels > 1 ? fclks->num_levels - 2 : 0; + vmax0p9_idx = fclks->num_levels > 0 ? fclks->num_levels - 1 : 0; dc->dcn_soc->fabric_and_dram_bandwidth_vmin0p65 = 32 * (fclks->data[vmin0p65_idx].clocks_in_khz / 1000.0) / 1000.0; -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] greybus: Fix use-after-free bug in gb_interface_release due to race condition.
by Tong Tiangen 17 Oct '24

17 Oct '24
From: Sicong Huang <congei42(a)163.com> stable inclusion from stable-v5.10.221 commit 2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACR2E CVE: CVE-2024-39495 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce upstream. In gb_interface_create, &intf->mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object "intf". The possible execution flow that may lead to the issue is as follows: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (free) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (use) Fix it by canceling the work before kfree. Signed-off-by: Sicong Huang <congei42(a)163.com> Link: https://lore.kernel.org/r/20240416080313.92306-1-congei42@163.com Cc: Ronnie Sahlberg <rsahlberg(a)ciq.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/greybus/interface.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/greybus/interface.c b/drivers/greybus/interface.c index 9ec949a438ef..52ef6be9d449 100644 --- a/drivers/greybus/interface.c +++ b/drivers/greybus/interface.c @@ -694,6 +694,7 @@ static void gb_interface_release(struct device *dev) trace_gb_interface_release(intf); + cancel_work_sync(&intf->mode_switch_work); kfree(intf); } -- 2.25.1
2 1
0 0
[PATCH OLK-6.6] RDMA/hns: Fix flush cqe error when racing with destroy qp
by Chengchang Tang 17 Oct '24

17 Oct '24
From: wenglianfa <wenglianfa(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAXK5A ---------------------------------------------------------------------- QP needs to be modified to IB_QPS_ERROR to trigger HW flush cqe. But when this process races with destroy qp, the destroy-qp process may modify the QP to IB_QPS_RESET first. In this case flush cqe will fail since it is invalid to modify qp from IB_QPS_RESET to IB_QPS_ERROR. Add lock and bit flag to make sure pending flush cqe work is completed first. Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler") Signed-off-by: wenglianfa <wenglianfa(a)huawei.com> Signed-off-by: Xinghai Cen <cenxinghai(a)h-partners.com> --- drivers/infiniband/hw/hns/hns_roce_device.h | 2 ++ drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 7 +++++++ drivers/infiniband/hw/hns/hns_roce_qp.c | 14 ++++++++++++-- 3 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h index 8add4742c094..7e139134b765 100644 --- a/drivers/infiniband/hw/hns/hns_roce_device.h +++ b/drivers/infiniband/hw/hns/hns_roce_device.h @@ -674,6 +674,7 @@ struct hns_roce_dev; enum { HNS_ROCE_FLUSH_FLAG = 0, + HNS_ROCE_STOP_FLUSH_FLAG = 1, }; struct hns_roce_work { @@ -740,6 +741,7 @@ struct hns_roce_qp { enum hns_roce_cong_type cong_type; bool delayed_destroy_flag; struct hns_roce_mtr_node *mtr_node; + spinlock_t flush_lock; }; struct hns_roce_ib_iboe { diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c index bc0b944ecfac..18e969b96fd1 100644 --- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c @@ -6020,8 +6020,15 @@ int hns_roce_v2_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata) { struct hns_roce_dev *hr_dev = to_hr_dev(ibqp->device); struct hns_roce_qp *hr_qp = to_hr_qp(ibqp); + unsigned long flags; int ret; + /* Make sure flush_cqe() is complete */ + spin_lock_irqsave(&hr_qp->flush_lock, flags); + set_bit(HNS_ROCE_STOP_FLUSH_FLAG, &hr_qp->flush_flag); + spin_unlock_irqrestore(&hr_qp->flush_lock, flags); + flush_work(&hr_qp->flush_work.work); + ret = hns_roce_v2_destroy_qp_common(hr_dev, hr_qp, udata); if (ret) ibdev_err_ratelimited(&hr_dev->ib_dev, diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c b/drivers/infiniband/hw/hns/hns_roce_qp.c index 2eb2694acf21..a62b1b96655a 100644 --- a/drivers/infiniband/hw/hns/hns_roce_qp.c +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c @@ -71,11 +71,18 @@ static void flush_work_handle(struct work_struct *work) void init_flush_work(struct hns_roce_dev *hr_dev, struct hns_roce_qp *hr_qp) { struct hns_roce_work *flush_work = &hr_qp->flush_work; + unsigned long flags; + + spin_lock_irqsave(&hr_qp->flush_lock, flags); + /* Exit flush_work after destroy_qp() */ + if (test_bit(HNS_ROCE_STOP_FLUSH_FLAG, &hr_qp->flush_flag)) { + spin_unlock_irqrestore(&hr_qp->flush_lock, flags); + return; + } - flush_work->hr_dev = hr_dev; - INIT_WORK(&flush_work->work, flush_work_handle); refcount_inc(&hr_qp->refcount); queue_work(hr_dev->irq_workq, &flush_work->work); + spin_unlock_irqrestore(&hr_qp->flush_lock, flags); } void flush_cqe(struct hns_roce_dev *dev, struct hns_roce_qp *qp) @@ -1225,6 +1232,7 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev, struct ib_udata *udata, struct hns_roce_qp *hr_qp) { + struct hns_roce_work *flush_work = &hr_qp->flush_work; struct hns_roce_ib_create_qp_resp resp = {}; struct ib_device *ibdev = &hr_dev->ib_dev; struct hns_roce_ib_create_qp ucmd = {}; @@ -1236,6 +1244,8 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev, hr_qp->state = IB_QPS_RESET; hr_qp->flush_flag = 0; + flush_work->hr_dev = hr_dev; + INIT_WORK(&flush_work->work, flush_work_handle); ret = set_qp_param(hr_dev, hr_qp, init_attr, udata, &ucmd); if (ret) { -- 2.33.0
2 1
0 0
[openeuler:OLK-5.10] BUILD REGRESSION 0f104c990d5fcb49911d3716e4b58266ee1050d1
by kernel test robot 17 Oct '24

17 Oct '24
tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 0f104c990d5fcb49911d3716e4b58266ee1050d1 !12208 Some bugfixs for ubi/fs Error/Warning ids grouped by kconfigs: recent_errors |-- x86_64-allyesconfig | |-- drivers-net-ipvlan-ipvlan_main.c:warning:variable-old_prog-set-but-not-used | |-- kernel-sched-core.c:warning:no-previous-prototype-for-function-sched_setsteal | |-- kernel-sched-core.c:warning:no-previous-prototype-for-function-tg_change_steal | |-- ld.lld:error:duplicate-symbol:g_uld_mutex | |-- ld.lld:error:duplicate-symbol:lld_dev_hold | |-- ld.lld:error:duplicate-symbol:lld_dev_put | `-- ld.lld:error:duplicate-symbol:nic_ioctl `-- x86_64-kexec `-- arch-x86-kvm-vmx-vmx.o:warning:objtool:fix_rmode_seg:unreachable-instruction elapsed time: 1568m configs tested: 5 configs skipped: 10 tested configs: x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 defconfig gcc-11 x86_64 kexec clang-18 x86_64 rhel-8.3 gcc-12 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS] BUILD REGRESSION 3e047c2ecbf1e613c098ce2e01e3fb7ef0994669
by kernel test robot 17 Oct '24

17 Oct '24
tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 3e047c2ecbf1e613c098ce2e01e3fb7ef0994669 !12138 md/raid1: don't free conf on raid0_run failure Error/Warning (recently discovered and may have been fixed): https://lore.kernel.org/oe-kbuild-all/202410171121.xyH2iCWj-lkp@intel.com drivers/net/ethernet/stmicro/stmmac/dwmac-phytium.c:159:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'int' [-Wint-conversion] Error/Warning ids grouped by kconfigs: recent_errors |-- x86_64-allnoconfig | `-- mm-memory.c:error:implicit-declaration-of-function-hugetlb_insert_hugepage_pte_by_pa-Werror-Wimplicit-function-declaration |-- x86_64-allyesconfig | `-- drivers-net-ethernet-stmicro-stmmac-dwmac-phytium.c:error:incompatible-pointer-to-integer-conversion-returning-void-from-a-function-with-result-type-int `-- x86_64-kexec `-- mm-memory.c:error:implicit-declaration-of-function-hugetlb_insert_hugepage_pte_by_pa-Werror-Wimplicit-function-declaration elapsed time: 1561m configs tested: 5 configs skipped: 10 tested configs: x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 defconfig gcc-11 x86_64 kexec clang-18 x86_64 rhel-8.3 gcc-12 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 21354/23833] drivers/net/ethernet/stmicro/stmmac/dwmac-phytium.c:159:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'int'
by kernel test robot 17 Oct '24

17 Oct '24
Hi wangzhimin, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3e047c2ecbf1e613c098ce2e01e3fb7ef0994669 commit: af48889301db8235deab66a8822e3e00195ca14b [21354/23833] dwmac:add phytium dwmac driver config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20241017/202410171121.xyH2iCWj-lkp@…) compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241017/202410171121.xyH2iCWj-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410171121.xyH2iCWj-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/net/ethernet/stmicro/stmmac/dwmac-phytium.c:159:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'int' [-Wint-conversion] 159 | return stmmac_res.addr; | ^~~~~~~~~~~~~~~ drivers/net/ethernet/stmicro/stmmac/dwmac-phytium.c:172:5: warning: no previous prototype for function 'phytium_dwmac_remove' [-Wmissing-prototypes] 172 | int phytium_dwmac_remove(struct platform_device *pdev) | ^ drivers/net/ethernet/stmicro/stmmac/dwmac-phytium.c:172:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 172 | int phytium_dwmac_remove(struct platform_device *pdev) | ^ | static 1 warning and 1 error generated. vim +159 drivers/net/ethernet/stmicro/stmmac/dwmac-phytium.c 32 33 static int phytium_dwmac_probe(struct platform_device *pdev) 34 { 35 struct fwnode_handle *fwnode = dev_fwnode(&pdev->dev); 36 struct plat_stmmacenet_data *plat; 37 struct stmmac_resources stmmac_res; 38 struct device_node *np = pdev->dev.of_node; 39 struct resource *res; 40 u64 clk_freq; 41 char clk_name[20]; 42 int ret; 43 44 plat = devm_kzalloc(&pdev->dev, sizeof(*plat), GFP_KERNEL); 45 if (!plat) 46 return -ENOMEM; 47 48 plat->dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*plat->dma_cfg), 49 GFP_KERNEL); 50 if (!plat->dma_cfg) 51 return -ENOMEM; 52 53 plat->axi = devm_kzalloc(&pdev->dev, sizeof(*plat->axi), GFP_KERNEL); 54 if (!plat->axi) 55 return -ENOMEM; 56 57 plat->interface = device_get_phy_mode(&pdev->dev); 58 if (plat->interface < 0) 59 return plat->interface; 60 61 /* Configure PHY if using device-tree */ 62 if (pdev->dev.of_node) 63 plat->phy_node = of_parse_phandle(np, "phy-handle", 0); 64 65 if (pdev->dev.of_node) { 66 plat->bus_id = of_alias_get_id(np, "ethernet"); 67 if (plat->bus_id < 0) 68 plat->bus_id = 0; 69 } else if (fwnode_property_read_u32(fwnode, "bus_id", &plat->bus_id)) { 70 plat->bus_id = 2; 71 } 72 73 plat->phy_addr = -1; 74 plat->clk_csr = -1; 75 plat->has_gmac = 1; 76 plat->enh_desc = 1; 77 plat->bugged_jumbo = 1; 78 plat->pmt = 1; 79 plat->force_sf_dma_mode = 1; 80 81 if (fwnode_property_read_u32(fwnode, "max-speed", &plat->max_speed)) 82 plat->max_speed = -1; 83 84 if (fwnode_property_read_u32(fwnode, "max-frame-size", &plat->maxmtu)) 85 plat->maxmtu = JUMBO_LEN; 86 87 if (fwnode_property_read_u32(fwnode, "snps,multicast-filter-bins", 88 &plat->multicast_filter_bins)) 89 plat->multicast_filter_bins = HASH_TABLE_SIZE; 90 91 if (fwnode_property_read_u32(fwnode, "snps,perfect-filter-entries", 92 &plat->unicast_filter_entries)) 93 plat->unicast_filter_entries = 1; 94 95 if (fwnode_property_read_u32(fwnode, "tx-fifo-depth", 96 &plat->tx_fifo_size)) 97 plat->tx_fifo_size = 0x1000; 98 99 if (fwnode_property_read_u32(fwnode, "rx-fifo-depth", 100 &plat->rx_fifo_size)) 101 plat->rx_fifo_size = 0x1000; 102 103 if (phytium_dwmac_acpi_phy(plat, fwnode, &pdev->dev)) 104 return -ENODEV; 105 106 plat->rx_queues_to_use = 1; 107 plat->tx_queues_to_use = 1; 108 plat->rx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB; 109 plat->tx_queues_cfg[0].mode_to_use = MTL_QUEUE_DCB; 110 111 if (fwnode_property_read_u64(fwnode, "clock-frequency", &clk_freq)) 112 clk_freq = 125000000; 113 114 /* Set system clock */ 115 snprintf(clk_name, sizeof(clk_name), "%s-%d", "stmmaceth", 116 plat->bus_id); 117 118 plat->stmmac_clk = clk_register_fixed_rate(&pdev->dev, clk_name, 119 NULL, 0, clk_freq); 120 if (IS_ERR(plat->stmmac_clk)) { 121 dev_warn(&pdev->dev, "Fail to register stmmac-clk\n"); 122 plat->stmmac_clk = NULL; 123 } 124 125 ret = clk_prepare_enable(plat->stmmac_clk); 126 if (ret) { 127 clk_unregister_fixed_rate(plat->stmmac_clk); 128 return ret; 129 } 130 131 plat->clk_ptp_rate = clk_get_rate(plat->stmmac_clk); 132 plat->clk_ptp_ref = NULL; 133 134 if (fwnode_property_read_u32(fwnode, "snps,pbl", &plat->dma_cfg->pbl)) 135 plat->dma_cfg->pbl = 16; 136 137 fwnode_property_read_u32(fwnode, "snps,txpbl", &plat->dma_cfg->txpbl); 138 fwnode_property_read_u32(fwnode, "snps,rxpbl", &plat->dma_cfg->rxpbl); 139 140 plat->dma_cfg->pblx8 = !fwnode_property_read_bool(fwnode, 141 "snps,no-pbl-x8"); 142 plat->dma_cfg->aal = fwnode_property_read_bool(fwnode, "snps,aal"); 143 plat->dma_cfg->fixed_burst = fwnode_property_read_bool(fwnode, 144 "snps,fixed-burst"); 145 plat->dma_cfg->mixed_burst = fwnode_property_read_bool(fwnode, 146 "snps,mixed-burst"); 147 148 plat->axi->axi_lpi_en = false; 149 plat->axi->axi_xit_frm = false; 150 plat->axi->axi_wr_osr_lmt = 7; 151 plat->axi->axi_rd_osr_lmt = 7; 152 plat->axi->axi_blen[0] = 16; 153 154 memset(&stmmac_res, 0, sizeof(stmmac_res)); 155 res = platform_get_resource(pdev, IORESOURCE_MEM, 0); 156 stmmac_res.addr = devm_ioremap_resource(&pdev->dev, res); 157 if (stmmac_res.addr < 0) { 158 dev_err(&pdev->dev, "resource map failed.\n"); > 159 return stmmac_res.addr; 160 } 161 stmmac_res.irq = platform_get_irq(pdev, 0); 162 if (stmmac_res.irq < 0) { 163 dev_err(&pdev->dev, "IRQ not found.\n"); 164 return -ENXIO; 165 } 166 stmmac_res.wol_irq = stmmac_res.irq; 167 stmmac_res.lpi_irq = -1; 168 169 return stmmac_dvr_probe(&pdev->dev, plat, &stmmac_res); 170 } 171 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 527
  • 528
  • 529
  • 530
  • 531
  • 532
  • 533
  • ...
  • 1876
  • Older →

HyperKitty Powered by HyperKitty