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

  • 46 participants
  • 18686 discussions
[PATCH openEuler-1.0-LTS] media: venus: fix use after free bug in venus_remove due to race condition
by Lin Ruifeng 01 Nov '24

01 Nov '24
From: Zheng Wang <zyytlz.wz(a)163.com> stable inclusion from stable-v5.10.227 commit 60b6968341a6dd5353554f3e72db554693a128a5 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCM CVE: CVE-2024-49981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 upstream. in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. Cc: stable(a)vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/media/platform/qcom/venus/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index 60069869596c..46dc50efc80a 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -345,6 +345,7 @@ static int venus_remove(struct platform_device *pdev) struct device *dev = core->dev; int ret; + cancel_delayed_work_sync(&core->work); ret = pm_runtime_get_sync(dev); WARN_ON(ret < 0); -- 2.17.1
2 1
0 0
[PATCH openEuler-1.0-LTS] iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw
by Lin Ruifeng 01 Nov '24

01 Nov '24
From: Wei Yongjun <weiyongjun1(a)huawei.com> stable inclusion from stable-v4.19.268 commit f5575041ec15310bdc50c42b8b22118cc900226e bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREK CVE: CVE-2022-49032 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fc92d9e3de0b2d30a3ccc08048a5fad533e4672b ] KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them. Fixes: b36e8257641a ("iio: health/afe440x: Use regmap fields") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: Andrew Davis <afd(a)ti.com> Link: https://lore.kernel.org/r/20221107152010.95937-1-weiyongjun@huaweicloud.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/iio/health/afe4404.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c index 11910922e655..56ff178bd07e 100644 --- a/drivers/iio/health/afe4404.c +++ b/drivers/iio/health/afe4404.c @@ -256,20 +256,20 @@ static int afe4404_read_raw(struct iio_dev *indio_dev, int *val, int *val2, long mask) { struct afe4404_data *afe = iio_priv(indio_dev); - unsigned int value_reg = afe4404_channel_values[chan->address]; - unsigned int led_field = afe4404_channel_leds[chan->address]; - unsigned int offdac_field = afe4404_channel_offdacs[chan->address]; + unsigned int value_reg, led_field, offdac_field; int ret; switch (chan->type) { case IIO_INTENSITY: switch (mask) { case IIO_CHAN_INFO_RAW: + value_reg = afe4404_channel_values[chan->address]; ret = regmap_read(afe->regmap, value_reg, val); if (ret) return ret; return IIO_VAL_INT; case IIO_CHAN_INFO_OFFSET: + offdac_field = afe4404_channel_offdacs[chan->address]; ret = regmap_field_read(afe->fields[offdac_field], val); if (ret) return ret; @@ -279,6 +279,7 @@ static int afe4404_read_raw(struct iio_dev *indio_dev, case IIO_CURRENT: switch (mask) { case IIO_CHAN_INFO_RAW: + led_field = afe4404_channel_leds[chan->address]; ret = regmap_field_read(afe->fields[led_field], val); if (ret) return ret; @@ -301,19 +302,20 @@ static int afe4404_write_raw(struct iio_dev *indio_dev, int val, int val2, long mask) { struct afe4404_data *afe = iio_priv(indio_dev); - unsigned int led_field = afe4404_channel_leds[chan->address]; - unsigned int offdac_field = afe4404_channel_offdacs[chan->address]; + unsigned int led_field, offdac_field; switch (chan->type) { case IIO_INTENSITY: switch (mask) { case IIO_CHAN_INFO_OFFSET: + offdac_field = afe4404_channel_offdacs[chan->address]; return regmap_field_write(afe->fields[offdac_field], val); } break; case IIO_CURRENT: switch (mask) { case IIO_CHAN_INFO_RAW: + led_field = afe4404_channel_leds[chan->address]; return regmap_field_write(afe->fields[led_field], val); } break; -- 2.17.1
2 1
0 0
[PATCH openEuler-1.0-LTS] serial: protect uart_port_dtr_rts() in uart_shutdown() too
by Yi Yang 01 Nov '24

01 Nov '24
From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 602babaa84d627923713acaf5f7e9a4369e77473 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREU CVE: CVE-2024-50058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Conflicts due to 5d4203990737("tty: Convert ->dtr_rts() to take bool argument") and 027b57170bf8("serial: core: Fix initializing and restoring termios speed") not merged] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 3faf643de752..537bcd7c4941 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -287,11 +287,13 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) - uport->cons->cflag = tty->termios.c_cflag; + if (uport) { + if (uart_console(uport) && tty) + uport->cons->cflag = tty->termios.c_cflag; - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] serial: protect uart_port_dtr_rts() in uart_shutdown() too
by Yi Yang 01 Nov '24

01 Nov '24
From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 602babaa84d627923713acaf5f7e9a4369e77473 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREU CVE: CVE-2024-50058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Conflicts due to 5d4203990737("tty: Convert ->dtr_rts() to take bool argument") not merged] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index c7adcf97e2a3..6d7d448d0fbf 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -286,14 +286,16 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) { - uport->cons->cflag = tty->termios.c_cflag; - uport->cons->ispeed = tty->termios.c_ispeed; - uport->cons->ospeed = tty->termios.c_ospeed; - } + if (uport) { + if (uart_console(uport) && tty) { + uport->cons->cflag = tty->termios.c_cflag; + uport->cons->ispeed = tty->termios.c_ispeed; + uport->cons->ospeed = tty->termios.c_ospeed; + } - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.25.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] serial: protect uart_port_dtr_rts() in uart_shutdown() too
by Yi Yang 01 Nov '24

01 Nov '24
From: "Jiri Slaby (SUSE)" <jirislaby(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 602babaa84d627923713acaf5f7e9a4369e77473 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREU CVE: CVE-2024-50058 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/tty/serial/serial_core.c [Conflicts due to 5d4203990737("tty: Convert ->dtr_rts() to take bool argument") not merged] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/serial_core.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 827bb6b2369e..47312fe902cb 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -286,14 +286,16 @@ static void uart_shutdown(struct tty_struct *tty, struct uart_state *state) /* * Turn off DTR and RTS early. */ - if (uport && uart_console(uport) && tty) { - uport->cons->cflag = tty->termios.c_cflag; - uport->cons->ispeed = tty->termios.c_ispeed; - uport->cons->ospeed = tty->termios.c_ospeed; - } + if (uport) { + if (uart_console(uport) && tty) { + uport->cons->cflag = tty->termios.c_cflag; + uport->cons->ispeed = tty->termios.c_ispeed; + uport->cons->ospeed = tty->termios.c_ospeed; + } - if (!tty || C_HUPCL(tty)) - uart_port_dtr_rts(uport, 0); + if (!tty || C_HUPCL(tty)) + uart_port_dtr_rts(uport, 0); + } uart_port_shutdown(port); } -- 2.25.1
2 1
0 0
[openeuler:OLK-5.10 18689/30000] drivers/ub/urma/ubcore/ubcore_dp.c:26:5: warning: no previous prototype for 'ubcore_post_jetty_send_wr'
by kernel test robot 01 Nov '24

01 Nov '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c78205e40443cde6028b0539f30a00fda4167edd commit: 33800c2820ab85fe02800e33f6b3287130278bdf [18689/30000] ub: ubcore add data plane ops api. config: arm64-randconfig-003-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010813.TGMdTWRa-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010813.TGMdTWRa-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/202411010813.TGMdTWRa-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/urma/ubcore/ubcore_dp.c:26:5: warning: no previous prototype for 'ubcore_post_jetty_send_wr' [-Wmissing-prototypes] 26 | int ubcore_post_jetty_send_wr(struct ubcore_jetty *jetty, const struct ubcore_jfs_wr *wr, | ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:42:5: warning: no previous prototype for 'ubcore_post_jetty_recv_wr' [-Wmissing-prototypes] 42 | int ubcore_post_jetty_recv_wr(struct ubcore_jetty *jetty, const struct ubcore_jfr_wr *wr, | ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:58:5: warning: no previous prototype for 'ubcore_post_jfs_wr' [-Wmissing-prototypes] 58 | int ubcore_post_jfs_wr(struct ubcore_jfs *jfs, const struct ubcore_jfs_wr *wr, | ^~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:74:5: warning: no previous prototype for 'ubcore_post_jfr_wr' [-Wmissing-prototypes] 74 | int ubcore_post_jfr_wr(struct ubcore_jfr *jfr, const struct ubcore_jfr_wr *wr, | ^~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/ubcore/ubcore_dp.c:90:5: warning: no previous prototype for 'ubcore_poll_jfc' [-Wmissing-prototypes] 90 | int ubcore_poll_jfc(struct ubcore_jfc *jfc, int cr_cnt, struct ubcore_cr *cr) | ^~~~~~~~~~~~~~~ drivers/ub/urma/ubcore/ubcore_dp.c:105:5: warning: no previous prototype for 'ubcore_rearm_jfc' [-Wmissing-prototypes] 105 | int ubcore_rearm_jfc(struct ubcore_jfc *jfc, bool solicited_only) | ^~~~~~~~~~~~~~~~ vim +/ubcore_post_jetty_send_wr +26 drivers/ub/urma/ubcore/ubcore_dp.c 25 > 26 int ubcore_post_jetty_send_wr(struct ubcore_jetty *jetty, const struct ubcore_jfs_wr *wr, 27 struct ubcore_jfs_wr **bad_wr) 28 { 29 struct ubcore_ops *dev_ops; 30 31 if (jetty == NULL || jetty->ub_dev == NULL || jetty->ub_dev->ops == NULL || 32 jetty->ub_dev->ops->post_jetty_send_wr == NULL || wr == NULL || bad_wr == NULL) { 33 ubcore_log_err("Invalid parameter"); 34 return -EINVAL; 35 } 36 37 dev_ops = jetty->ub_dev->ops; 38 return dev_ops->post_jetty_send_wr(jetty, wr, bad_wr); 39 } 40 EXPORT_SYMBOL(ubcore_post_jetty_send_wr); 41 > 42 int ubcore_post_jetty_recv_wr(struct ubcore_jetty *jetty, const struct ubcore_jfr_wr *wr, 43 struct ubcore_jfr_wr **bad_wr) 44 { 45 struct ubcore_ops *dev_ops; 46 47 if (jetty == NULL || jetty->ub_dev == NULL || jetty->ub_dev->ops == NULL || 48 jetty->ub_dev->ops->post_jetty_recv_wr == NULL || wr == NULL || bad_wr == NULL) { 49 ubcore_log_err("Invalid parameter"); 50 return -EINVAL; 51 } 52 53 dev_ops = jetty->ub_dev->ops; 54 return dev_ops->post_jetty_recv_wr(jetty, wr, bad_wr); 55 } 56 EXPORT_SYMBOL(ubcore_post_jetty_recv_wr); 57 > 58 int ubcore_post_jfs_wr(struct ubcore_jfs *jfs, const struct ubcore_jfs_wr *wr, 59 struct ubcore_jfs_wr **bad_wr) 60 { 61 struct ubcore_ops *dev_ops; 62 63 if (jfs == NULL || jfs->ub_dev == NULL || jfs->ub_dev->ops == NULL || 64 jfs->ub_dev->ops->post_jfs_wr == NULL || wr == NULL || bad_wr == NULL) { 65 ubcore_log_err("Invalid parameter"); 66 return -EINVAL; 67 } 68 69 dev_ops = jfs->ub_dev->ops; 70 return dev_ops->post_jfs_wr(jfs, wr, bad_wr); 71 } 72 EXPORT_SYMBOL(ubcore_post_jfs_wr); 73 > 74 int ubcore_post_jfr_wr(struct ubcore_jfr *jfr, const struct ubcore_jfr_wr *wr, 75 struct ubcore_jfr_wr **bad_wr) 76 { 77 struct ubcore_ops *dev_ops; 78 79 if (jfr == NULL || jfr->ub_dev == NULL || jfr->ub_dev->ops == NULL || 80 jfr->ub_dev->ops->post_jfr_wr == NULL || wr == NULL || bad_wr == NULL) { 81 ubcore_log_err("Invalid parameter"); 82 return -EINVAL; 83 } 84 85 dev_ops = jfr->ub_dev->ops; 86 return dev_ops->post_jfr_wr(jfr, wr, bad_wr); 87 } 88 EXPORT_SYMBOL(ubcore_post_jfr_wr); 89 > 90 int ubcore_poll_jfc(struct ubcore_jfc *jfc, int cr_cnt, struct ubcore_cr *cr) 91 { 92 struct ubcore_ops *dev_ops; 93 94 if (jfc == NULL || jfc->ub_dev == NULL || jfc->ub_dev->ops == NULL || 95 jfc->ub_dev->ops->poll_jfc == NULL || cr == NULL) { 96 ubcore_log_err("Invalid parameter"); 97 return -EINVAL; 98 } 99 100 dev_ops = jfc->ub_dev->ops; 101 return dev_ops->poll_jfc(jfc, cr_cnt, cr); 102 } 103 EXPORT_SYMBOL(ubcore_poll_jfc); 104 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 18663/30000] drivers/ub/urma/ubcore/ubcore_tp.c:40:17: warning: no previous prototype for 'ubcore_get_mtu'
by kernel test robot 01 Nov '24

01 Nov '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c78205e40443cde6028b0539f30a00fda4167edd commit: 832e9fe8cf1ed02211ff43bd4f3f16ddc2d69969 [18663/30000] ub: ubcore add create/delete tp table api config: arm64-randconfig-003-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010411.aKWhEHwD-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010411.aKWhEHwD-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/202411010411.aKWhEHwD-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/ub/urma/ubcore/ubcore_tp.c:40:17: warning: no previous prototype for 'ubcore_get_mtu' [-Wmissing-prototypes] 40 | enum ubcore_mtu ubcore_get_mtu(int mtu) | ^~~~~~~~~~~~~~ drivers/ub/urma/ubcore/ubcore_tp.c:75:19: warning: no previous prototype for 'ubcore_create_vtp' [-Wmissing-prototypes] 75 | struct ubcore_tp *ubcore_create_vtp(struct ubcore_device *dev, const union ubcore_eid *remote_eid, | ^~~~~~~~~~~~~~~~~ drivers/ub/urma/ubcore/ubcore_tp.c:83:5: warning: no previous prototype for 'ubcore_destroy_vtp' [-Wmissing-prototypes] 83 | int ubcore_destroy_vtp(struct ubcore_tp *vtp) | ^~~~~~~~~~~~~~~~~~ vim +/ubcore_get_mtu +40 drivers/ub/urma/ubcore/ubcore_tp.c c75b0bccca77778 Yizhen Fan 2023-09-14 39 c75b0bccca77778 Yizhen Fan 2023-09-14 @40 enum ubcore_mtu ubcore_get_mtu(int mtu) c75b0bccca77778 Yizhen Fan 2023-09-14 41 { c75b0bccca77778 Yizhen Fan 2023-09-14 42 mtu = mtu - UB_PROTOCOL_HEAD_BYTES; c75b0bccca77778 Yizhen Fan 2023-09-14 43 c75b0bccca77778 Yizhen Fan 2023-09-14 44 if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_8192)) c75b0bccca77778 Yizhen Fan 2023-09-14 45 return UBCORE_MTU_8192; c75b0bccca77778 Yizhen Fan 2023-09-14 46 if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_4096)) c75b0bccca77778 Yizhen Fan 2023-09-14 47 return UBCORE_MTU_4096; c75b0bccca77778 Yizhen Fan 2023-09-14 48 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_2048)) c75b0bccca77778 Yizhen Fan 2023-09-14 49 return UBCORE_MTU_2048; c75b0bccca77778 Yizhen Fan 2023-09-14 50 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_1024)) c75b0bccca77778 Yizhen Fan 2023-09-14 51 return UBCORE_MTU_1024; c75b0bccca77778 Yizhen Fan 2023-09-14 52 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_512)) c75b0bccca77778 Yizhen Fan 2023-09-14 53 return UBCORE_MTU_512; c75b0bccca77778 Yizhen Fan 2023-09-14 54 else if (mtu >= ubcore_mtu_enum_to_int(UBCORE_MTU_256)) c75b0bccca77778 Yizhen Fan 2023-09-14 55 return UBCORE_MTU_256; c75b0bccca77778 Yizhen Fan 2023-09-14 56 else c75b0bccca77778 Yizhen Fan 2023-09-14 57 return 0; c75b0bccca77778 Yizhen Fan 2023-09-14 58 } c75b0bccca77778 Yizhen Fan 2023-09-14 59 EXPORT_SYMBOL(ubcore_get_mtu); c75b0bccca77778 Yizhen Fan 2023-09-14 60 :::::: The code at line 40 was first introduced by commit :::::: c75b0bccca77778d5663004cb19d3dd31ef71f0a ub: ubcore add get_mtu and other APIs that will be used by the driver. :::::: TO: Yizhen Fan <fanyizhen(a)huawei.com> :::::: CC: fanyizhen1995 <en_0015767(a)163.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 15253/23924] arch/arm64/kernel/mpam/mpam_resctrl.c:358:1: warning: conflicting types for 'mpam_get_raw_resctrl_resource' due to enum/integer mismatch; have 'struct raw_resctrl_resource *(enum resctrl_resource_level)'
by kernel test robot 01 Nov '24

01 Nov '24
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: e73db5f1f4d00d788085541fcfcb33402ee9221c commit: a453ee059c9d7c7372b6f413ef152b9ea8ee800e [15253/23924] arm64/mpam: Init resctrl resources' info from resctrl_res selected config: arm64-randconfig-001-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010258.ysot0OR8-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010258.ysot0OR8-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/202411010258.ysot0OR8-lkp@intel.com/ All warnings (new ones prefixed by >>): >> arch/arm64/kernel/mpam/mpam_resctrl.c:358:1: warning: conflicting types for 'mpam_get_raw_resctrl_resource' due to enum/integer mismatch; have 'struct raw_resctrl_resource *(enum resctrl_resource_level)' [-Wenum-int-mismatch] 358 | mpam_get_raw_resctrl_resource(enum resctrl_resource_level level) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/arm64/kernel/mpam/mpam_resctrl.c:47: arch/arm64/kernel/mpam/mpam_internal.h:127:1: note: previous declaration of 'mpam_get_raw_resctrl_resource' with type 'struct raw_resctrl_resource *(u32)' {aka 'struct raw_resctrl_resource *(unsigned int)'} 127 | mpam_get_raw_resctrl_resource(u32 level); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c:784:5: warning: no previous prototype for 'cpus_ctrl_write' [-Wmissing-prototypes] 784 | int cpus_ctrl_write(struct rdtgroup *rdtgrp, cpumask_var_t newmask, | ^~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c:872:5: warning: no previous prototype for 'cpus_mon_write' [-Wmissing-prototypes] 872 | int cpus_mon_write(struct rdtgroup *rdtgrp, cpumask_var_t newmask, | ^~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c: In function 'rdt_last_cmd_printf': arch/arm64/kernel/mpam/mpam_resctrl.c:1016:9: warning: function 'rdt_last_cmd_printf' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] 1016 | seq_buf_vprintf(&last_cmd_status, fmt, ap); | ^~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c: At top level: arch/arm64/kernel/mpam/mpam_resctrl.c:1089:5: warning: no previous prototype for 'resctrl_ctrlmon_enable' [-Wmissing-prototypes] 1089 | int resctrl_ctrlmon_enable(struct kernfs_node *parent_kn, | ^~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/mpam/mpam_resctrl.c:1117:6: warning: no previous prototype for 'resctrl_ctrlmon_disable' [-Wmissing-prototypes] 1117 | void resctrl_ctrlmon_disable(struct kernfs_node *kn_mondata, | ^~~~~~~~~~~~~~~~~~~~~~~ vim +358 arch/arm64/kernel/mpam/mpam_resctrl.c 356 357 struct raw_resctrl_resource * > 358 mpam_get_raw_resctrl_resource(enum resctrl_resource_level level) 359 { 360 if (level >= RDT_NUM_RESOURCES) 361 return NULL; 362 363 return &raw_resctrl_resources_all[level]; 364 } 365 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 18659/30000] drivers/ub/urma/uburma/uburma_cmd.c:180:6: warning: no previous prototype for 'uburma_jetty_event_cb'
by kernel test robot 01 Nov '24

01 Nov '24
Hi Yizhen, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c78205e40443cde6028b0539f30a00fda4167edd commit: c3af5be3e72710b357d9f23a5bdcafe8f96d6dfd [18659/30000] ub: uburma add cmd create jetty implementation. config: arm64-randconfig-003-20241029 (https://download.01.org/0day-ci/archive/20241101/202411010152.inffSTWn-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241101/202411010152.inffSTWn-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/202411010152.inffSTWn-lkp@intel.com/ All warnings (new ones prefixed by >>): drivers/ub/urma/uburma/uburma_cmd.c:144:6: warning: no previous prototype for 'uburma_jfc_event_cb' [-Wmissing-prototypes] 144 | void uburma_jfc_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/urma/uburma/uburma_cmd.c:156:6: warning: no previous prototype for 'uburma_jfs_event_cb' [-Wmissing-prototypes] 156 | void uburma_jfs_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ drivers/ub/urma/uburma/uburma_cmd.c:168:6: warning: no previous prototype for 'uburma_jfr_event_cb' [-Wmissing-prototypes] 168 | void uburma_jfr_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~ >> drivers/ub/urma/uburma/uburma_cmd.c:180:6: warning: no previous prototype for 'uburma_jetty_event_cb' [-Wmissing-prototypes] 180 | void uburma_jetty_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) | ^~~~~~~~~~~~~~~~~~~~~ vim +/uburma_jetty_event_cb +180 drivers/ub/urma/uburma/uburma_cmd.c 179 > 180 void uburma_jetty_event_cb(struct ubcore_event *event, struct ubcore_ucontext *ctx) 181 { 182 struct uburma_jetty_uobj *jetty_uobj; 183 184 if (event->element.jetty == NULL) 185 return; 186 187 jetty_uobj = (struct uburma_jetty_uobj *)event->element.jetty->jetty_cfg.jetty_context; 188 uburma_write_async_event(ctx, event->element.jetty->urma_jetty, event->event_type, 189 &jetty_uobj->async_event_list, &jetty_uobj->async_events_reported); 190 } 191 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-5.10 19333/30000] fs/ext4/fast_commit.o: warning: objtool: __ext4_fc_track_unlink()+0x275: unreachable instruction
by kernel test robot 31 Oct '24

31 Oct '24
tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: c67d418d86fea7b8c2a11c7273229ffb0a7a57ed commit: f2c902d8c653f8021f9761092a27f7b9db42b662 [19333/30000] tracing: Make tracepoint lockdep check actually test something config: x86_64-buildonly-randconfig-001-20241030 (https://download.01.org/0day-ci/archive/20241031/202410312220.K72H6v5s-lkp@…) compiler: clang version 19.1.2 (https://github.com/llvm/llvm-project 7ba7d8e2f7b6445b60679da826210cdde29eaf8b) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241031/202410312220.K72H6v5s-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/202410312220.K72H6v5s-lkp@intel.com/ All warnings (new ones prefixed by >>): >> fs/ext4/fast_commit.o: warning: objtool: __ext4_fc_track_unlink()+0x275: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 457
  • 458
  • 459
  • 460
  • 461
  • 462
  • 463
  • ...
  • 1869
  • Older →

HyperKitty Powered by HyperKitty