[U-Boot,RFC,v2] u-boot: remove driver lookup loop from env_save()

Message ID 1531392726-1693-1-git-send-email-nicholas.faustini@azcomtech.com
State New
Headers show
Series
  • [U-Boot,RFC,v2] u-boot: remove driver lookup loop from env_save()
Related show

Commit Message

Nicholas Faustini July 12, 2018, 10:52 a.m.
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(-)

Comments

Simon Goldschmidt July 12, 2018, 11:02 a.m. | #1
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();
>
Nicholas Faustini July 12, 2018, 12:32 p.m. | #2
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();
> >
Simon Goldschmidt July 13, 2018, 7:37 a.m. | #3
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();
>>>
>

Patch

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();