2023-10-04 14:56:45

by Mukesh Ojha

[permalink] [raw]
Subject: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot

There could be following scenario where there is a ongoing reboot
is going from processA which tries to call all the reboot notifier
callback and one of them is firmware reboot call which tries to
abort all the ongoing firmware userspace request under fw_lock but
there could be another processB which tries to do request firmware,
which came just after abort done from ProcessA and ask for userspace
to load the firmware and this can stop the ongoing reboot ProcessA
to stall for next 60s(default timeout) which may not be expected
behaviour everyone like to see, instead we should abort any firmware
load request which came once firmware knows about the reboot through
notification.

ProcessA ProcessB

kernel_restart_prepare
blocking_notifier_call_chain
fw_shutdown_notify
kill_pending_fw_fallback_reqs
__fw_load_abort
fw_state_aborted request_firmware
__fw_state_set firmware_fallback_sysfs
... fw_load_from_user_helper
.. ...
. ..
usermodehelper_read_trylock
fw_load_sysfs_fallback
fw_sysfs_wait_timeout
usermodehelper_disable
__usermodehelper_disable
down_write()

Signed-off-by: Mukesh Ojha <[email protected]>
---
Changes from v1: https://lore.kernel.org/lkml/[email protected]/
- Renamed the flag to fw_load_abort.
- Kept the flag under fw_lock.
- Repharsed commit text.

drivers/base/firmware_loader/fallback.c | 6 +++++-
drivers/base/firmware_loader/firmware.h | 1 +
drivers/base/firmware_loader/main.c | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index bf68e3947814..b9f855d248ac 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -57,6 +57,10 @@ void kill_pending_fw_fallback_reqs(bool only_kill_custom)
if (!fw_priv->need_uevent || !only_kill_custom)
__fw_load_abort(fw_priv);
}
+
+ if (!only_kill_custom)
+ fw_load_abort = true;
+
mutex_unlock(&fw_lock);
}

@@ -86,7 +90,7 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs, long timeout)
}

mutex_lock(&fw_lock);
- if (fw_state_is_aborted(fw_priv)) {
+ if (fw_load_abort || fw_state_is_aborted(fw_priv)) {
mutex_unlock(&fw_lock);
retval = -EINTR;
goto out;
diff --git a/drivers/base/firmware_loader/firmware.h b/drivers/base/firmware_loader/firmware.h
index bf549d6500d7..015846e50dff 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -86,6 +86,7 @@ struct fw_priv {

extern struct mutex fw_lock;
extern struct firmware_cache fw_cache;
+extern bool fw_load_abort;

static inline bool __fw_state_check(struct fw_priv *fw_priv,
enum fw_status status)
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index b58c42f1b1ce..467ff1d439af 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -93,6 +93,7 @@ static inline struct fw_priv *to_fw_priv(struct kref *ref)
DEFINE_MUTEX(fw_lock);

struct firmware_cache fw_cache;
+bool fw_load_abort;

void fw_state_init(struct fw_priv *fw_priv)
{
--
2.7.4


2023-10-04 22:10:00

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot

Hi Mukesh,

kernel test robot noticed the following build warnings:

[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on driver-core/driver-core-next driver-core/driver-core-linus linus/master v6.6-rc4 next-20231004]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url: https://github.com/intel-lab-lkp/linux/commits/Mukesh-Ojha/firmware_loader-Abort-new-fw-load-request-once-firmware-core-knows-about-reboot/20231004-225910
base: driver-core/driver-core-testing
patch link: https://lore.kernel.org/r/1696431327-7369-1-git-send-email-quic_mojha%40quicinc.com
patch subject: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20231005/[email protected]/config)
compiler: m68k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231005/[email protected]/reproduce)

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 <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All warnings (new ones prefixed by >>):

In file included from drivers/base/firmware_loader/fallback.h:9,
from drivers/base/firmware_loader/fallback.c:11:
drivers/base/firmware_loader/sysfs.h:87:20: error: 'fw_load_abort' redeclared as different kind of symbol
87 | static inline void fw_load_abort(struct fw_sysfs *fw_sysfs)
| ^~~~~~~~~~~~~
In file included from drivers/base/firmware_loader/fallback.h:8:
drivers/base/firmware_loader/firmware.h:89:13: note: previous declaration of 'fw_load_abort' with type 'bool' {aka '_Bool'}
89 | extern bool fw_load_abort;
| ^~~~~~~~~~~~~
drivers/base/firmware_loader/fallback.c: In function 'kill_pending_fw_fallback_reqs':
drivers/base/firmware_loader/fallback.c:62:31: error: lvalue required as left operand of assignment
62 | fw_load_abort = true;
| ^
drivers/base/firmware_loader/fallback.c: In function 'fw_load_sysfs_fallback':
>> drivers/base/firmware_loader/fallback.c:93:13: warning: the address of 'fw_load_abort' will always evaluate as 'true' [-Waddress]
93 | if (fw_load_abort || fw_state_is_aborted(fw_priv)) {
| ^~~~~~~~~~~~~


vim +93 drivers/base/firmware_loader/fallback.c

66
67 /**
68 * fw_load_sysfs_fallback() - load a firmware via the sysfs fallback mechanism
69 * @fw_sysfs: firmware sysfs information for the firmware to load
70 * @timeout: timeout to wait for the load
71 *
72 * In charge of constructing a sysfs fallback interface for firmware loading.
73 **/
74 static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs, long timeout)
75 {
76 int retval = 0;
77 struct device *f_dev = &fw_sysfs->dev;
78 struct fw_priv *fw_priv = fw_sysfs->fw_priv;
79
80 /* fall back on userspace loading */
81 if (!fw_priv->data)
82 fw_priv->is_paged_buf = true;
83
84 dev_set_uevent_suppress(f_dev, true);
85
86 retval = device_add(f_dev);
87 if (retval) {
88 dev_err(f_dev, "%s: device_register failed\n", __func__);
89 goto err_put_dev;
90 }
91
92 mutex_lock(&fw_lock);
> 93 if (fw_load_abort || fw_state_is_aborted(fw_priv)) {
94 mutex_unlock(&fw_lock);
95 retval = -EINTR;
96 goto out;
97 }
98 list_add(&fw_priv->pending_list, &pending_fw_head);
99 mutex_unlock(&fw_lock);
100
101 if (fw_priv->opt_flags & FW_OPT_UEVENT) {
102 fw_priv->need_uevent = true;
103 dev_set_uevent_suppress(f_dev, false);
104 dev_dbg(f_dev, "firmware: requesting %s\n", fw_priv->fw_name);
105 kobject_uevent(&fw_sysfs->dev.kobj, KOBJ_ADD);
106 } else {
107 timeout = MAX_JIFFY_OFFSET;
108 }
109
110 retval = fw_sysfs_wait_timeout(fw_priv, timeout);
111 if (retval < 0 && retval != -ENOENT) {
112 mutex_lock(&fw_lock);
113 fw_load_abort(fw_sysfs);
114 mutex_unlock(&fw_lock);
115 }
116
117 if (fw_state_is_aborted(fw_priv)) {
118 if (retval == -ERESTARTSYS)
119 retval = -EINTR;
120 } else if (fw_priv->is_paged_buf && !fw_priv->data)
121 retval = -ENOMEM;
122
123 out:
124 device_del(f_dev);
125 err_put_dev:
126 put_device(f_dev);
127 return retval;
128 }
129

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

2023-10-05 01:55:05

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot

Hi Mukesh,

kernel test robot noticed the following build errors:

[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on driver-core/driver-core-next driver-core/driver-core-linus linus/master v6.6-rc4 next-20231004]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url: https://github.com/intel-lab-lkp/linux/commits/Mukesh-Ojha/firmware_loader-Abort-new-fw-load-request-once-firmware-core-knows-about-reboot/20231004-225910
base: driver-core/driver-core-testing
patch link: https://lore.kernel.org/r/1696431327-7369-1-git-send-email-quic_mojha%40quicinc.com
patch subject: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot
config: x86_64-rhel-8.3-rust (https://download.01.org/0day-ci/archive/20231005/[email protected]/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231005/[email protected]/reproduce)

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 <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

In file included from drivers/base/firmware_loader/fallback.c:11:
In file included from drivers/base/firmware_loader/fallback.h:9:
drivers/base/firmware_loader/sysfs.h:87:20: error: redefinition of 'fw_load_abort' as different kind of symbol
static inline void fw_load_abort(struct fw_sysfs *fw_sysfs)
^
drivers/base/firmware_loader/firmware.h:89:13: note: previous definition is here
extern bool fw_load_abort;
^
>> drivers/base/firmware_loader/fallback.c:113:16: error: called object type 'bool' (aka '_Bool') is not a function or function pointer
fw_load_abort(fw_sysfs);
~~~~~~~~~~~~~^
2 errors generated.
--
In file included from drivers/base/firmware_loader/sysfs.c:9:
drivers/base/firmware_loader/sysfs.h:87:20: error: redefinition of 'fw_load_abort' as different kind of symbol
static inline void fw_load_abort(struct fw_sysfs *fw_sysfs)
^
drivers/base/firmware_loader/firmware.h:89:13: note: previous definition is here
extern bool fw_load_abort;
^
>> drivers/base/firmware_loader/sysfs.c:218:16: error: called object type 'bool' (aka '_Bool') is not a function or function pointer
fw_load_abort(fw_sysfs);
~~~~~~~~~~~~~^
drivers/base/firmware_loader/sysfs.c:302:16: error: called object type 'bool' (aka '_Bool') is not a function or function pointer
fw_load_abort(fw_sysfs);
~~~~~~~~~~~~~^
3 errors generated.


vim +113 drivers/base/firmware_loader/fallback.c

d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 66
60fa74263cbeae1 drivers/base/firmware_loader/fallback.c Luis R. Rodriguez 2018-03-10 67 /**
c35f9cbb1df8f17 drivers/base/firmware_loader/fallback.c Andres Rodriguez 2018-05-10 68 * fw_load_sysfs_fallback() - load a firmware via the sysfs fallback mechanism
b93815d0f37e7c4 drivers/base/firmware_loader/fallback.c Andres Rodriguez 2018-04-25 69 * @fw_sysfs: firmware sysfs information for the firmware to load
60fa74263cbeae1 drivers/base/firmware_loader/fallback.c Luis R. Rodriguez 2018-03-10 70 * @timeout: timeout to wait for the load
60fa74263cbeae1 drivers/base/firmware_loader/fallback.c Luis R. Rodriguez 2018-03-10 71 *
60fa74263cbeae1 drivers/base/firmware_loader/fallback.c Luis R. Rodriguez 2018-03-10 72 * In charge of constructing a sysfs fallback interface for firmware loading.
60fa74263cbeae1 drivers/base/firmware_loader/fallback.c Luis R. Rodriguez 2018-03-10 73 **/
89287c169f8ff79 drivers/base/firmware_loader/fallback.c Kees Cook 2020-10-02 74 static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs, long timeout)
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 75 {
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 76 int retval = 0;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 77 struct device *f_dev = &fw_sysfs->dev;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 78 struct fw_priv *fw_priv = fw_sysfs->fw_priv;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 79
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 80 /* fall back on userspace loading */
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 81 if (!fw_priv->data)
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 82 fw_priv->is_paged_buf = true;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 83
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 84 dev_set_uevent_suppress(f_dev, true);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 85
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 86 retval = device_add(f_dev);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 87 if (retval) {
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 88 dev_err(f_dev, "%s: device_register failed\n", __func__);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 89 goto err_put_dev;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 90 }
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 91
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 92 mutex_lock(&fw_lock);
b30557dae4a363d drivers/base/firmware_loader/fallback.c Mukesh Ojha 2023-10-04 93 if (fw_load_abort || fw_state_is_aborted(fw_priv)) {
75d95e2e39b27f7 drivers/base/firmware_loader/fallback.c Anirudh Rayabharam 2021-07-28 94 mutex_unlock(&fw_lock);
75d95e2e39b27f7 drivers/base/firmware_loader/fallback.c Anirudh Rayabharam 2021-07-28 95 retval = -EINTR;
75d95e2e39b27f7 drivers/base/firmware_loader/fallback.c Anirudh Rayabharam 2021-07-28 96 goto out;
75d95e2e39b27f7 drivers/base/firmware_loader/fallback.c Anirudh Rayabharam 2021-07-28 97 }
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 98 list_add(&fw_priv->pending_list, &pending_fw_head);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 99 mutex_unlock(&fw_lock);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 100
89287c169f8ff79 drivers/base/firmware_loader/fallback.c Kees Cook 2020-10-02 101 if (fw_priv->opt_flags & FW_OPT_UEVENT) {
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 102 fw_priv->need_uevent = true;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 103 dev_set_uevent_suppress(f_dev, false);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 104 dev_dbg(f_dev, "firmware: requesting %s\n", fw_priv->fw_name);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 105 kobject_uevent(&fw_sysfs->dev.kobj, KOBJ_ADD);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 106 } else {
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 107 timeout = MAX_JIFFY_OFFSET;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 108 }
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 109
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 110 retval = fw_sysfs_wait_timeout(fw_priv, timeout);
bcfbd3523f3c6ee drivers/base/firmware_loader/fallback.c Junyong Sun 2020-03-03 111 if (retval < 0 && retval != -ENOENT) {
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 112 mutex_lock(&fw_lock);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 @113 fw_load_abort(fw_sysfs);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 114 mutex_unlock(&fw_lock);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 115 }
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 116
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 117 if (fw_state_is_aborted(fw_priv)) {
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 118 if (retval == -ERESTARTSYS)
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 119 retval = -EINTR;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 120 } else if (fw_priv->is_paged_buf && !fw_priv->data)
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 121 retval = -ENOMEM;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 122
75d95e2e39b27f7 drivers/base/firmware_loader/fallback.c Anirudh Rayabharam 2021-07-28 123 out:
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 124 device_del(f_dev);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 125 err_put_dev:
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 126 put_device(f_dev);
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 127 return retval;
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 128 }
d73f821c7aea16a drivers/base/firmware_fallback.c Luis R. Rodriguez 2018-03-10 129

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

2023-10-05 02:20:00

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot

Hi Mukesh,

kernel test robot noticed the following build errors:

[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on driver-core/driver-core-next driver-core/driver-core-linus linus/master v6.6-rc4 next-20231004]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url: https://github.com/intel-lab-lkp/linux/commits/Mukesh-Ojha/firmware_loader-Abort-new-fw-load-request-once-firmware-core-knows-about-reboot/20231004-225910
base: driver-core/driver-core-testing
patch link: https://lore.kernel.org/r/1696431327-7369-1-git-send-email-quic_mojha%40quicinc.com
patch subject: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot
config: um-allnoconfig (https://download.01.org/0day-ci/archive/20231005/[email protected]/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231005/[email protected]/reproduce)

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 <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

In file included from drivers/base/firmware_loader/main.c:21:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
547 | val = __raw_readb(PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
560 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
| ^
In file included from drivers/base/firmware_loader/main.c:21:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
573 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
| ^
In file included from drivers/base/firmware_loader/main.c:21:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
584 | __raw_writeb(value, PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
594 | __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
604 | __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
692 | readsb(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
700 | readsw(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:708:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
708 | readsl(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:717:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
717 | writesb(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:726:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
726 | writesw(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:735:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
735 | writesl(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
In file included from drivers/base/firmware_loader/main.c:45:
In file included from drivers/base/firmware_loader/fallback.h:9:
>> drivers/base/firmware_loader/sysfs.h:87:20: error: redefinition of 'fw_load_abort' as different kind of symbol
87 | static inline void fw_load_abort(struct fw_sysfs *fw_sysfs)
| ^
drivers/base/firmware_loader/firmware.h:89:13: note: previous definition is here
89 | extern bool fw_load_abort;
| ^
12 warnings and 1 error generated.


vim +/fw_load_abort +87 drivers/base/firmware_loader/sysfs.h

e0c11a8b985137 Russ Weight 2022-04-21 86
e0c11a8b985137 Russ Weight 2022-04-21 @87 static inline void fw_load_abort(struct fw_sysfs *fw_sysfs)
e0c11a8b985137 Russ Weight 2022-04-21 88 {
e0c11a8b985137 Russ Weight 2022-04-21 89 struct fw_priv *fw_priv = fw_sysfs->fw_priv;
e0c11a8b985137 Russ Weight 2022-04-21 90
e0c11a8b985137 Russ Weight 2022-04-21 91 __fw_load_abort(fw_priv);
e0c11a8b985137 Russ Weight 2022-04-21 92 }
e0c11a8b985137 Russ Weight 2022-04-21 93

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

2023-10-10 22:31:18

by Luis Chamberlain

[permalink] [raw]
Subject: Re: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot


Seems like you just have to fix the 0-day build issues.

Luis

2023-10-19 14:51:13

by Mukesh Ojha

[permalink] [raw]
Subject: Re: [PATCH v2] firmware_loader: Abort new fw load request once firmware core knows about reboot



On 10/11/2023 4:00 AM, Luis Chamberlain wrote:
>
> Seems like you just have to fix the 0-day build issues.

V3 was posted a day after that.


https://lore.kernel.org/lkml/[email protected]/

-Mukesh
>
> Luis