[U-Boot] [RFC PATCH v2] u-boot: remove driver lookup loop from env_save()
When called with ENVOP_SAVE, env_get_location() only returns the gd->env_load_location variable without actually checking for the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when the low-level drv->save() call fails.
The env_save() function should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini nicholas.faustini@azcomtech.com ---
Changes in v2: - Restore gd->env_load_location to the highest priority location when env_load() fails
env/env.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/env/env.c b/env/env.c index 5c0842a..18eb78d 100644 --- a/env/env.c +++ b/env/env.c @@ -205,22 +205,24 @@ int env_load(void) return 0; }
+ env_get_location(ENVOP_LOAD, 0); + return -ENODEV; }
int env_save(void) { struct env_driver *drv; - int prio;
- for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) { + drv = env_driver_lookup(ENVOP_SAVE, 0); + if (drv) { int ret;
if (!drv->save) - continue; + return -ENODEV;
if (!env_has_inited(drv->location)) - continue; + return -ENODEV;
printf("Saving Environment to %s... ", drv->name); ret = drv->save();
On 12.07.2018 12:52, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only returns the gd->env_load_location variable without actually checking for the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when the low-level drv->save() call fails.
The env_save() function should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini nicholas.faustini@azcomtech.com
Changes in v2:
Restore gd->env_load_location to the highest priority location when env_load() fails
env/env.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/env/env.c b/env/env.c index 5c0842a..18eb78d 100644 --- a/env/env.c +++ b/env/env.c @@ -205,22 +205,24 @@ int env_load(void) return 0; }
- env_get_location(ENVOP_LOAD, 0);
A comment why this is required would be good, I guess.
return -ENODEV; }
int env_save(void) { struct env_driver *drv;
int prio;
for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE, prio)); prio++) {
- drv = env_driver_lookup(ENVOP_SAVE, 0);
Thinking again about this, would it make more sense to store 'env_load_prio' in 'gd' after successful load? That way, 'env_get_location()' would be more straightforward (no special case for ENVOP_SAVE) and here in 'env_save()' we could just write something like this:
drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);
Simon
if (drv) { int ret;
if (!drv->save)
continue;
return -ENODEV;if (!env_has_inited(drv->location))
continue;
return -ENODEV;printf("Saving Environment to %s... ", drv->name); ret = drv->save();
On gio, 2018-07-12 at 13:02 +0200, Simon Goldschmidt wrote:
On 12.07.2018 12:52, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only returns the gd->env_load_location variable without actually checking for the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when the low-level drv->save() call fails.
The env_save() function should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini nicholas.faustini@azcomtech.com
Changes in v2:
- Restore gd->env_load_location to the highest priority location
when env_load() fails
env/env.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/env/env.c b/env/env.c index 5c0842a..18eb78d 100644 --- a/env/env.c +++ b/env/env.c @@ -205,22 +205,24 @@ int env_load(void) return 0; }
- env_get_location(ENVOP_LOAD, 0);
A comment why this is required would be good, I guess.
Sure, I thought the same but eventually I didn't put it. Will do in the next version.
return -ENODEV; } int env_save(void) { struct env_driver *drv;
- int prio;
- for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE,
prio)); prio++) {
- drv = env_driver_lookup(ENVOP_SAVE, 0);
Thinking again about this, would it make more sense to store 'env_load_prio' in 'gd' after successful load? That way, 'env_get_location()' would be more straightforward (no special case for ENVOP_SAVE) and here in 'env_save()' we could just write something like this:
drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);
I really like the 'env_load_prio' idea. But I also like having the special case for ENVOP_SAVE in env_get_location() as it enforces the fact that the location of 'save' is bound to the location of previous 'load'. I however don't have a strong opinion on this. I could even remove the whole switch() statement if we introduce 'env_load_prio'.
Also, I have some doubts about what it should be returned when !drv-
save and !env_has_inited(drv->location) (below)... I put -ENODEV but I
don't like it so much.
Simon
- if (drv) {
int ret; if (!drv->save)
continue;
return -ENODEV;if (!env_has_inited(drv->location))
continue;
return -ENODEV;printf("Saving Environment to %s... ", drv-
name);
ret = drv->save();
On 12.07.2018 14:32, Nicholas wrote:
On gio, 2018-07-12 at 13:02 +0200, Simon Goldschmidt wrote:
On 12.07.2018 12:52, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only returns the gd->env_load_location variable without actually checking for the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when the low-level drv->save() call fails.
The env_save() function should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini nicholas.faustini@azcomtech.com
Changes in v2:
- Restore gd->env_load_location to the highest priority location
when env_load() fails
env/env.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/env/env.c b/env/env.c index 5c0842a..18eb78d 100644 --- a/env/env.c +++ b/env/env.c @@ -205,22 +205,24 @@ int env_load(void) return 0; }
- env_get_location(ENVOP_LOAD, 0);
A comment why this is required would be good, I guess.
Sure, I thought the same but eventually I didn't put it. Will do in the next version.
return -ENODEV; }
int env_save(void) { struct env_driver *drv;
int prio;
for (prio = 0; (drv = env_driver_lookup(ENVOP_SAVE,
prio)); prio++) {
- drv = env_driver_lookup(ENVOP_SAVE, 0);
Thinking again about this, would it make more sense to store 'env_load_prio' in 'gd' after successful load? That way, 'env_get_location()' would be more straightforward (no special case for ENVOP_SAVE) and here in 'env_save()' we could just write something like this:
drv = env_driver_lookup(ENVOP_SAVE, gd->env_load_prio);
I really like the 'env_load_prio' idea. But I also like having the special case for ENVOP_SAVE in env_get_location() as it enforces the fact that the location of 'save' is bound to the location of previous 'load'. I however don't have a strong opinion on this. I could even remove the whole switch() statement if we introduce 'env_load_prio'.
Me neither. I just thought it would be strange if env_get_location() was always called with prio 0.
Also, I have some doubts about what it should be returned when !drv-
save and !env_has_inited(drv->location) (below)... I put -ENODEV but I
don't like it so much.
I guess that's OK since it was like that before. And after all, the only place where the return value of env_save() is checked (do_env_save()), the exact error is ignored.
Simon
Simon
- if (drv) {
int ret;
if (!drv->save)
continue;
return -ENODEV;if (!env_has_inited(drv->location))
continue;
return -ENODEV;printf("Saving Environment to %s... ", drv-
name);
ret = drv->save();
participants (3)
-
Nicholas -
Nicholas Faustini
-
Simon Goldschmidt