Re: [PATCH v2] initcall: break loop immediately on failure
On Tue, Mar 05, 2024 at 02:55:13PM +, Caleb Connolly wrote: > The current ordering always results in func pointing to the next > function in the init_sequence. e.g. if fdtdec_setup() fails, ret will > be set to the error code, then func will be updated to point to > initf_malloc(), only then is ret checked and the loop broken. The end > result of this is that the "initcall failed at ..." error will point you > to initf_malloc(), when the error actually occured in fdtdec_setup()! > > This can be quite confusing and result in a lot of time wasted debugging > code that has nothing to do with the failure (ask me how I know :P). > > Adjust the for loop to check ret immediately after the call and break > early so that func will correctly reference the failed function. > > Signed-off-by: Caleb Connolly > Reviewed-by: Dan Carpenter Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] initcall: break loop immediately on failure
On Tue, Mar 05, 2024 at 02:55:13PM +, Caleb Connolly wrote: > The current ordering always results in func pointing to the next > function in the init_sequence. e.g. if fdtdec_setup() fails, ret will > be set to the error code, then func will be updated to point to > initf_malloc(), only then is ret checked and the loop broken. The end > result of this is that the "initcall failed at ..." error will point you > to initf_malloc(), when the error actually occured in fdtdec_setup()! > > This can be quite confusing and result in a lot of time wasted debugging > code that has nothing to do with the failure (ask me how I know :P). > > Adjust the for loop to check ret immediately after the call and break > early so that func will correctly reference the failed function. > > Signed-off-by: Caleb Connolly > --- > Changes in v2: > - Don't drop the initialisation of ret (thanks Dan!). > - Link to v1: > https://lore.kernel.org/u-boot/20240219183519.2183405-1-caleb.conno...@linaro.org/ > > Cc: Dan Carpenter Awesome. Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter
[PATCH v2] initcall: break loop immediately on failure
The current ordering always results in func pointing to the next
function in the init_sequence. e.g. if fdtdec_setup() fails, ret will
be set to the error code, then func will be updated to point to
initf_malloc(), only then is ret checked and the loop broken. The end
result of this is that the "initcall failed at ..." error will point you
to initf_malloc(), when the error actually occured in fdtdec_setup()!
This can be quite confusing and result in a lot of time wasted debugging
code that has nothing to do with the failure (ask me how I know :P).
Adjust the for loop to check ret immediately after the call and break
early so that func will correctly reference the failed function.
Signed-off-by: Caleb Connolly
---
Changes in v2:
- Don't drop the initialisation of ret (thanks Dan!).
- Link to v1:
https://lore.kernel.org/u-boot/20240219183519.2183405-1-caleb.conno...@linaro.org/
Cc: Dan Carpenter
---
lib/initcall.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/initcall.c b/lib/initcall.c
index ce317af213ab..c8e2b0f6a386 100644
--- a/lib/initcall.c
+++ b/lib/initcall.c
@@ -54,9 +54,9 @@ int initcall_run_list(const init_fnc_t init_sequence[])
enum event_t type;
init_fnc_t func;
int ret = 0;
- for (ptr = init_sequence; func = *ptr, !ret && func; ptr++) {
+ for (ptr = init_sequence; func = *ptr, func; ptr++) {
type = initcall_is_event(func);
if (type) {
if (!CONFIG_IS_ENABLED(EVENT))
@@ -70,8 +70,10 @@ int initcall_run_list(const init_fnc_t init_sequence[])
debug("initcall: %p\n", (char *)func - reloc_ofs);
}
ret = type ? event_notify_null(type) : func();
+ if (ret)
+ break;
}
if (ret) {
if (CONFIG_IS_ENABLED(EVENT)) {
--
2.44.0
