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

  • 51 participants
  • 18727 discussions
[PATCH openEuler-22.03-LTS-SP1] i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
by Yipeng Zou 24 Oct '24

24 Oct '24
From: Marek Vasut <marex(a)denx.de> stable inclusion from stable-v5.10.227 commit 9b8bc33ad64192f54142396470cc34ce539a8940 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCQ CVE: CVE-2024-49985 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream. In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex. Acked-by: Alain Volmat <alain.volmat(a)foss.st.com> Signed-off-by: Marek Vasut <marex(a)denx.de> Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support") Cc: <stable(a)vger.kernel.org> # v5.0+ Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/i2c/busses/i2c-stm32f7.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c index 0f4c0282028b..da3ff7802307 100644 --- a/drivers/i2c/busses/i2c-stm32f7.c +++ b/drivers/i2c/busses/i2c-stm32f7.c @@ -2275,7 +2275,7 @@ static int __maybe_unused stm32f7_i2c_runtime_suspend(struct device *dev) struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev); if (!stm32f7_i2c_is_slave_registered(i2c_dev)) - clk_disable_unprepare(i2c_dev->clk); + clk_disable(i2c_dev->clk); return 0; } @@ -2286,9 +2286,9 @@ static int __maybe_unused stm32f7_i2c_runtime_resume(struct device *dev) int ret; if (!stm32f7_i2c_is_slave_registered(i2c_dev)) { - ret = clk_prepare_enable(i2c_dev->clk); + ret = clk_enable(i2c_dev->clk); if (ret) { - dev_err(dev, "failed to prepare_enable clock\n"); + dev_err(dev, "failed to enable clock\n"); return ret; } } -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
by Yipeng Zou 24 Oct '24

24 Oct '24
From: Marek Vasut <marex(a)denx.de> stable inclusion from stable-v6.6.55 commit 22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCQ CVE: CVE-2024-49985 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream. In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex. Acked-by: Alain Volmat <alain.volmat(a)foss.st.com> Signed-off-by: Marek Vasut <marex(a)denx.de> Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support") Cc: <stable(a)vger.kernel.org> # v5.0+ Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/i2c/busses/i2c-stm32f7.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c index 887d55ae4096..b4f10ff31102 100644 --- a/drivers/i2c/busses/i2c-stm32f7.c +++ b/drivers/i2c/busses/i2c-stm32f7.c @@ -2394,7 +2394,7 @@ static int __maybe_unused stm32f7_i2c_runtime_suspend(struct device *dev) struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev); if (!stm32f7_i2c_is_slave_registered(i2c_dev)) - clk_disable_unprepare(i2c_dev->clk); + clk_disable(i2c_dev->clk); return 0; } @@ -2405,9 +2405,9 @@ static int __maybe_unused stm32f7_i2c_runtime_resume(struct device *dev) int ret; if (!stm32f7_i2c_is_slave_registered(i2c_dev)) { - ret = clk_prepare_enable(i2c_dev->clk); + ret = clk_enable(i2c_dev->clk); if (ret) { - dev_err(dev, "failed to prepare_enable clock\n"); + dev_err(dev, "failed to enable clock\n"); return ret; } } -- 2.34.1
2 1
0 0
[PATCH OLK-5.10] i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
by Yipeng Zou 24 Oct '24

24 Oct '24
From: Marek Vasut <marex(a)denx.de> stable inclusion from stable-v5.10.227 commit 9b8bc33ad64192f54142396470cc34ce539a8940 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCQ CVE: CVE-2024-49985 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream. In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex. Acked-by: Alain Volmat <alain.volmat(a)foss.st.com> Signed-off-by: Marek Vasut <marex(a)denx.de> Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support") Cc: <stable(a)vger.kernel.org> # v5.0+ Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/i2c/busses/i2c-stm32f7.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c index 7b9272f9cc21..0b4e73e63820 100644 --- a/drivers/i2c/busses/i2c-stm32f7.c +++ b/drivers/i2c/busses/i2c-stm32f7.c @@ -2278,7 +2278,7 @@ static int __maybe_unused stm32f7_i2c_runtime_suspend(struct device *dev) struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev); if (!stm32f7_i2c_is_slave_registered(i2c_dev)) - clk_disable_unprepare(i2c_dev->clk); + clk_disable(i2c_dev->clk); return 0; } @@ -2289,9 +2289,9 @@ static int __maybe_unused stm32f7_i2c_runtime_resume(struct device *dev) int ret; if (!stm32f7_i2c_is_slave_registered(i2c_dev)) { - ret = clk_prepare_enable(i2c_dev->clk); + ret = clk_enable(i2c_dev->clk); if (ret) { - dev_err(dev, "failed to prepare_enable clock\n"); + dev_err(dev, "failed to enable clock\n"); return ret; } } -- 2.34.1
2 1
0 0
[PATCH OLK-5.10] neighbour: fix data-races around n->output
by Wang Liang 24 Oct '24

24 Oct '24
From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.6-rc5 commit 5baa0433a15eadd729625004c37463acb982eca7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAZ542 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- n->output field can be read locklessly, while a writer might change the pointer concurrently. Add missing annotations to prevent load-store tearing. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Conflicts: net/core/neighbour.c [conflicts due to mergered 09eed1192cec ("neighbour: switch to standard rcu, instead of rcu_bh")] Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- include/net/neighbour.h | 2 +- net/bridge/br_netfilter_hooks.c | 2 +- net/core/neighbour.c | 10 +++++----- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/include/net/neighbour.h b/include/net/neighbour.h index 8e4404efd910..ef310154818e 100644 --- a/include/net/neighbour.h +++ b/include/net/neighbour.h @@ -514,7 +514,7 @@ static inline int neigh_output(struct neighbour *n, struct sk_buff *skb, READ_ONCE(hh->hh_len)) return neigh_hh_output(hh, skb); - return n->output(n, skb); + return READ_ONCE(n->output)(n, skb); } static inline struct neighbour * diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c index 119b1a36a126..a65a77eb740d 100644 --- a/net/bridge/br_netfilter_hooks.c +++ b/net/bridge/br_netfilter_hooks.c @@ -305,7 +305,7 @@ int br_nf_pre_routing_finish_bridge(struct net *net, struct sock *sk, struct sk_ /* tell br_dev_xmit to continue with forwarding */ nf_bridge->bridged_dnat = 1; /* FIXME Need to refragment */ - ret = neigh->output(neigh, skb); + ret = READ_ONCE(neigh->output)(neigh, skb); } neigh_release(neigh); return ret; diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 432e3a64dc4a..168868fb8e6c 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -364,7 +364,7 @@ static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *dev, */ __skb_queue_purge(&n->arp_queue); n->arp_queue_len_bytes = 0; - n->output = neigh_blackhole; + WRITE_ONCE(n->output, neigh_blackhole); if (n->nud_state & NUD_VALID) n->nud_state = NUD_NOARP; else @@ -875,7 +875,7 @@ static void neigh_suspect(struct neighbour *neigh) { neigh_dbg(2, "neigh %p is suspected\n", neigh); - neigh->output = neigh->ops->output; + WRITE_ONCE(neigh->output, neigh->ops->output); } /* Neighbour state is OK; @@ -887,7 +887,7 @@ static void neigh_connect(struct neighbour *neigh) { neigh_dbg(2, "neigh %p is connected\n", neigh); - neigh->output = neigh->ops->connected_output; + WRITE_ONCE(neigh->output, neigh->ops->connected_output); } static void neigh_periodic_work(struct work_struct *work) @@ -1402,7 +1402,7 @@ static int __neigh_update(struct neighbour *neigh, const u8 *lladdr, if (n2) n1 = n2; } - n1->output(n1, skb); + READ_ONCE(n1->output)(n1, skb); if (n2) neigh_release(n2); rcu_read_unlock(); @@ -3027,7 +3027,7 @@ int neigh_xmit(int index, struct net_device *dev, rcu_read_unlock_bh(); goto out_kfree_skb; } - err = neigh->output(neigh, skb); + err = READ_ONCE(neigh->output)(neigh, skb); rcu_read_unlock_bh(); } else if (index == NEIGH_LINK_TABLE) { -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS 0/8] backport some LTS patches
by Wang Liang 24 Oct '24

24 Oct '24
Ido Schimmel (1): bridge: switchdev: Allow clearing FDB entry offload indication Jonas Gorski (1): net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN Nikolay Aleksandrov (6): net: bridge: add support for sticky fdb entries net: bridge: fdb: convert is_local to bitops net: bridge: fdb: convert is_static to bitops net: bridge: fdb: convert is_sticky to bitops net: bridge: fdb: convert added_by_user to bitops net: bridge: fdb: convert added_by_external_learn to use bitops .../mellanox/mlxsw/spectrum_switchdev.c | 9 +- drivers/net/ethernet/rocker/rocker_main.c | 1 + include/net/switchdev.h | 3 +- include/uapi/linux/neighbour.h | 1 + net/bridge/br.c | 4 +- net/bridge/br_fdb.c | 128 ++++++++++-------- net/bridge/br_input.c | 2 +- net/bridge/br_private.h | 18 ++- net/bridge/br_switchdev.c | 11 +- net/dsa/slave.c | 1 + 10 files changed, 104 insertions(+), 74 deletions(-) -- 2.34.1
2 9
0 0
[openeuler:OLK-6.6 13320/15255] drivers/crypto/ccp/hygon/tdm-kernel-guard.c:308:37: error: 'NR_syscalls' undeclared; did you mean 'si_syscall'?
by kernel test robot 24 Oct '24

24 Oct '24
Hi chench00, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: e7bc79687a034a22f94328123d5cf8c4d4436c35 commit: 3ad98583441f7c8a2553e1e8d6340ed4397033e2 [13320/15255] crypto: tdm: Support dynamic protection for SCT and IDT by HYGON TDM config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410240917.ylHeViWu-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410240917.ylHeViWu-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/202410240917.ylHeViWu-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/crypto/ccp/hygon/tdm-kernel-guard.c:151:5: warning: no previous prototype for 'tdm_service_run' [-Wmissing-prototypes] 151 | int tdm_service_run(struct tdm_security_enhance *data) | ^~~~~~~~~~~~~~~ drivers/crypto/ccp/hygon/tdm-kernel-guard.c:212:5: warning: no previous prototype for 'tdm_service_exit' [-Wmissing-prototypes] 212 | int tdm_service_exit(struct tdm_security_enhance *data) | ^~~~~~~~~~~~~~~~ drivers/crypto/ccp/hygon/tdm-kernel-guard.c:243:15: warning: no previous prototype for 'kprobe_symbol_address_byname' [-Wmissing-prototypes] 243 | unsigned long kprobe_symbol_address_byname(const char *name) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/crypto/ccp/hygon/tdm-kernel-guard.c: In function 'kernel_security_enhance_init': >> drivers/crypto/ccp/hygon/tdm-kernel-guard.c:308:37: error: 'NR_syscalls' undeclared (first use in this function); did you mean 'si_syscall'? 308 | eh_objs[SCT].size = NR_syscalls * sizeof(char *); | ^~~~~~~~~~~ | si_syscall drivers/crypto/ccp/hygon/tdm-kernel-guard.c:308:37: note: each undeclared identifier is reported only once for each function it appears in vim +308 drivers/crypto/ccp/hygon/tdm-kernel-guard.c 286 287 sct_addr = (unsigned long *)kallsyms_lookup_name("sys_call_table"); 288 #endif 289 if (!sct_addr) { 290 ret = -DYN_ERR_API; 291 pr_err("kallsyms_lookup_name for sys_call_table failed!"); 292 goto end; 293 } 294 295 asm("sidt %0":"=m"(idtr)); 296 297 if (!psp_check_tdm_support()) 298 return 0; 299 300 for (i = 0; i < MAX_OBJ; i++) { 301 memset(&eh_objs[i], 0, sizeof(eh_objs[i])); 302 eh_objs[i].context = CONTEXT_CHECK_MODNAME; 303 eh_objs[i].obj_name = obj_names[i]; 304 } 305 306 if ((eh_obj == -1) || (eh_obj & (1 << SCT))) { 307 eh_objs[SCT].vaddr = (uint64_t)sct_addr; > 308 eh_objs[SCT].size = NR_syscalls * sizeof(char *); 309 } 310 if ((eh_obj == -1) || (eh_obj & (1 << IDT))) { 311 eh_objs[IDT].vaddr = idtr.address; 312 eh_objs[IDT].size = idtr.size; 313 } 314 315 for (i = 0; i < MAX_OBJ; i++) { 316 if (eh_objs[i].vaddr) 317 tdm_service_run(&eh_objs[i]); 318 } 319 320 pr_info("Hygon TDM guard load successfully!\n"); 321 322 end: 323 return ret; 324 } 325 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-6.6 2431/15255] arch/x86/events/amd/iommu.c:441:64: warning: '%u' directive output may be truncated writing between 1 and 10 bytes into a region of size 6
by kernel test robot 24 Oct '24

24 Oct '24
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: e7bc79687a034a22f94328123d5cf8c4d4436c35 commit: f04c0f3eb9b49427c273cd3e4d5a2ff895855b4b [2431/15255] make OPTIMIZE_INLINING config editable config: x86_64-buildonly-randconfig-004-20241024 (https://download.01.org/0day-ci/archive/20241024/202410240834.gfaxos6R-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410240834.gfaxos6R-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/202410240834.gfaxos6R-lkp@intel.com/ All warnings (new ones prefixed by >>): arch/x86/events/amd/iommu.c: In function 'amd_iommu_pc_init': >> arch/x86/events/amd/iommu.c:441:64: warning: '%u' directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Wformat-truncation=] 441 | snprintf(perf_iommu->name, IOMMU_NAME_SIZE, "amd_iommu_%u", idx); | ^~ In function 'init_one_iommu', inlined from 'amd_iommu_pc_init' at arch/x86/events/amd/iommu.c:474:9: arch/x86/events/amd/iommu.c:441:53: note: directive argument in the range [0, 4294967294] 441 | snprintf(perf_iommu->name, IOMMU_NAME_SIZE, "amd_iommu_%u", idx); | ^~~~~~~~~~~~~~ arch/x86/events/amd/iommu.c:441:9: note: 'snprintf' output between 12 and 21 bytes into a destination of size 16 441 | snprintf(perf_iommu->name, IOMMU_NAME_SIZE, "amd_iommu_%u", idx); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vim +441 arch/x86/events/amd/iommu.c 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 417 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 418 static __init int init_one_iommu(unsigned int idx) 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 419 { 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 420 struct perf_amd_iommu *perf_iommu; 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 421 int ret; 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 422 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 423 perf_iommu = kzalloc(sizeof(struct perf_amd_iommu), GFP_KERNEL); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 424 if (!perf_iommu) 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 425 return -ENOMEM; 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 426 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 427 raw_spin_lock_init(&perf_iommu->lock); 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 428 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 429 perf_iommu->pmu = iommu_pmu; 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 430 perf_iommu->iommu = get_amd_iommu(idx); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 431 perf_iommu->max_banks = amd_iommu_pc_get_max_banks(idx); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 432 perf_iommu->max_counters = amd_iommu_pc_get_max_counters(idx); 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 433 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 434 if (!perf_iommu->iommu || 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 435 !perf_iommu->max_banks || 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 436 !perf_iommu->max_counters) { 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 437 kfree(perf_iommu); f5863a00e73c43 arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-02-24 438 return -EINVAL; 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 439 } f5863a00e73c43 arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-02-24 440 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 @441 snprintf(perf_iommu->name, IOMMU_NAME_SIZE, "amd_iommu_%u", idx); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 442 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 443 ret = perf_pmu_register(&perf_iommu->pmu, perf_iommu->name, -1); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 444 if (!ret) { 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 445 pr_info("Detected AMD IOMMU #%d (%d banks, %d counters/bank).\n", 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 446 idx, perf_iommu->max_banks, perf_iommu->max_counters); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 447 list_add_tail(&perf_iommu->list, &perf_amd_iommu_list); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 448 } else { 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 449 pr_warn("Error initializing IOMMU %d.\n", idx); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 450 kfree(perf_iommu); 25df39f2cfd06a arch/x86/events/amd/iommu.c Suravee Suthikulpanit 2017-03-22 451 } 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 452 return ret; 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 453 } 7be6296fdd75f7 arch/x86/kernel/cpu/perf_event_amd_iommu.c Suravee Suthikulpanit 2013-06-05 454 :::::: The code at line 441 was first introduced by commit :::::: 25df39f2cfd06a4b49ad592c5b7cba0cbf24e27f x86/events/amd/iommu: Enable support for multiple IOMMUs :::::: TO: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> :::::: CC: Ingo Molnar <mingo(a)kernel.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-6.6 9626/15255] arch/x86/kernel/zhaoxin_kh40000.c:87:47: error: implicit declaration of function 'iommu_get_dma_domain'; did you mean 'iommu_is_dma_domain'?
by kernel test robot 24 Oct '24

24 Oct '24
Hi leoliu-oc, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: e7bc79687a034a22f94328123d5cf8c4d4436c35 commit: 4332dbb07181359cccca3ba757ef54e434fb1296 [9626/15255] Add kh40000_direct_dma_ops for KH-40000 platform config: x86_64-buildonly-randconfig-001-20241024 (https://download.01.org/0day-ci/archive/20241024/202410240848.VbEcgWD6-lkp@…) compiler: gcc-11 (Debian 11.3.0-12) 11.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410240848.VbEcgWD6-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/202410240848.VbEcgWD6-lkp@intel.com/ All errors (new ones prefixed by >>): arch/x86/kernel/zhaoxin_kh40000.c: In function 'kh40000_sync_single_dma_for_cpu': >> arch/x86/kernel/zhaoxin_kh40000.c:87:47: error: implicit declaration of function 'iommu_get_dma_domain'; did you mean 'iommu_is_dma_domain'? [-Werror=implicit-function-declaration] 87 | struct iommu_domain *domain = iommu_get_dma_domain(dev); | ^~~~~~~~~~~~~~~~~~~~ | iommu_is_dma_domain arch/x86/kernel/zhaoxin_kh40000.c:87:47: warning: initialization of 'struct iommu_domain *' from 'int' makes pointer from integer without a cast [-Wint-conversion] cc1: some warnings being treated as errors vim +87 arch/x86/kernel/zhaoxin_kh40000.c 64 65 static void kh40000_sync_single_dma_for_cpu(struct device *dev, dma_addr_t paddr, 66 enum dma_data_direction dir, bool is_iommu) 67 { 68 u8 vid; 69 struct pci_dev *pci; 70 u64 dma_mask = *dev->dma_mask; 71 72 /* check direction */ 73 if ((dir != DMA_FROM_DEVICE) && (dir != DMA_BIDIRECTIONAL)) 74 return; 75 76 /* check dma capability */ 77 if (dma_mask <= DMA_BIT_MASK(32)) 78 return; 79 80 /* check device type */ 81 pci = kh40000_get_pci_dev(dev); 82 if (pci == NULL) 83 return; 84 85 /* get real physical address */ 86 if (is_iommu) { > 87 struct iommu_domain *domain = iommu_get_dma_domain(dev); 88 89 paddr = iommu_iova_to_phys(domain, paddr); 90 if (!paddr) 91 return; 92 } 93 94 /* check node or not */ 95 if ((zhaoxin_patch_code & ZHAOXIN_P2CW_NODE_CHECK) 96 && pfn_to_nid(PFN_DOWN(paddr)) == dev_to_node(dev)) 97 return; 98 99 /* flush data by one pci read cycle */ 100 pci_read_config_byte(pci, PCI_VENDOR_ID, &vid); 101 } 102 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 17239/23855] drivers/nvme/host/core.c:1163:27: error: 'compat_uptr_t' undeclared; did you mean 'compat_time_t'?
by kernel test robot 24 Oct '24

24 Oct '24
Hi Nick, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3c02090eb0ad149880a8c798014249ad2d642617 commit: b8ba22a604e4d0a3ad8e23af22f432e12b6f1a65 [17239/23855] nvme: fix compat address handling in several ioctls config: arm64-randconfig-003-20241024 (https://download.01.org/0day-ci/archive/20241024/202410240741.LLyNQDLf-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410240741.LLyNQDLf-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/202410240741.LLyNQDLf-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/nvme/host/core.c: In function 'nvme_to_user_ptr': >> drivers/nvme/host/core.c:1163:27: error: 'compat_uptr_t' undeclared (first use in this function); did you mean 'compat_time_t'? 1163 | ptrval = (compat_uptr_t)ptrval; | ^~~~~~~~~~~~~ | compat_time_t drivers/nvme/host/core.c:1163:27: note: each undeclared identifier is reported only once for each function it appears in >> drivers/nvme/host/core.c:1163:41: error: expected ';' before 'ptrval' 1163 | ptrval = (compat_uptr_t)ptrval; | ^~~~~~ | ; vim +1163 drivers/nvme/host/core.c 1154 1155 /* 1156 * Convert integer values from ioctl structures to user pointers, silently 1157 * ignoring the upper bits in the compat case to match behaviour of 32-bit 1158 * kernels. 1159 */ 1160 static void __user *nvme_to_user_ptr(uintptr_t ptrval) 1161 { 1162 if (in_compat_syscall()) > 1163 ptrval = (compat_uptr_t)ptrval; 1164 return (void __user *)ptrval; 1165 } 1166 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 15515/23855] arch/x86/events/zhaoxin/core.c:505:12: error: redefinition of 'zhaoxin_pmu_init'
by kernel test robot 24 Oct '24

24 Oct '24
Hi LeoLiu-oc, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3c02090eb0ad149880a8c798014249ad2d642617 commit: 0ce7c3b6e8a986ee9ef92a07ae18964835446c07 [15515/23855] x86/perf: Add hardware performance events support for Zhaoxin CPU. config: x86_64-randconfig-001-20241024 (https://download.01.org/0day-ci/archive/20241024/202410240541.Jo4ftqeo-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410240541.Jo4ftqeo-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/202410240541.Jo4ftqeo-lkp@intel.com/ All errors (new ones prefixed by >>): >> arch/x86/events/zhaoxin/core.c:505:12: error: redefinition of 'zhaoxin_pmu_init' 505 | __init int zhaoxin_pmu_init(void) | ^~~~~~~~~~~~~~~~ In file included from arch/x86/events/zhaoxin/core.c:19: arch/x86/events/zhaoxin/../perf_event.h:1054:19: note: previous definition of 'zhaoxin_pmu_init' with type 'int(void)' 1054 | static inline int zhaoxin_pmu_init(void) | ^~~~~~~~~~~~~~~~ vim +/zhaoxin_pmu_init +505 arch/x86/events/zhaoxin/core.c 504 > 505 __init int zhaoxin_pmu_init(void) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 515
  • 516
  • 517
  • 518
  • 519
  • 520
  • 521
  • ...
  • 1873
  • Older →

HyperKitty Powered by HyperKitty