[PATCH 1/1] ubifs: avoid possible NULL dereference

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/1] ubifs: avoid possible NULL dereference

Heinrich Schuchardt
If 'file' cannot be allocated due to an out of memory
situation, do not dereference it.

When debugging this patch also avoids a misleading message
"cannot find next direntry, error %d" in case of an out of
memory situation. It is sufficent to write
"%s: Error, no memory for malloc!\n" in this case.

Reported-by: Alex Sadovsky <[hidden email]>
Signed-off-by: Heinrich Schuchardt <[hidden email]>
---
 fs/ubifs/ubifs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 4465523d5f..313dee0579 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
  dir = kzalloc(sizeof(struct inode), 0);
  if (!file || !dentry || !dir) {
  printf("%s: Error, no memory for malloc!\n", __func__);
- err = -ENOMEM;
- goto out;
+ goto out_nomem;
  }
 
  dir->i_sb = sb;
@@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
  err = PTR_ERR(dent);
  goto out;
  }
-
  file->f_pos = key_hash_flash(c, &dent->key);
  file->private_data = dent;
 
@@ -463,6 +461,7 @@ out:
 
 out_free:
  kfree(file->private_data);
+out_nomem:
  free(file);
  free(dentry);
  free(dir);
--
2.11.0

_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Ladislav Michl
On Tue, Nov 21, 2017 at 07:45:03PM +0100, Heinrich Schuchardt wrote:

> If 'file' cannot be allocated due to an out of memory
> situation, do not dereference it.
>
> When debugging this patch also avoids a misleading message
> "cannot find next direntry, error %d" in case of an out of
> memory situation. It is sufficent to write
> "%s: Error, no memory for malloc!\n" in this case.
>
> Reported-by: Alex Sadovsky <[hidden email]>
> Signed-off-by: Heinrich Schuchardt <[hidden email]>
> ---
>  fs/ubifs/ubifs.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> index 4465523d5f..313dee0579 100644
> --- a/fs/ubifs/ubifs.c
> +++ b/fs/ubifs/ubifs.c
> @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>   dir = kzalloc(sizeof(struct inode), 0);
>   if (!file || !dentry || !dir) {
>   printf("%s: Error, no memory for malloc!\n", __func__);
> - err = -ENOMEM;
> - goto out;
> + goto out_nomem;
>   }
>  
>   dir->i_sb = sb;
> @@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>   err = PTR_ERR(dent);
>   goto out;
>   }
> -
>   file->f_pos = key_hash_flash(c, &dent->key);
>   file->private_data = dent;
>
 
This hunk should be probably droped.

> @@ -463,6 +461,7 @@ out:
>  
>  out_free:
>   kfree(file->private_data);

Now question is why is file->private_data ever assigned as it seems nothing
works with it.

> +out_nomem:
>   free(file);
>   free(dentry);
>   free(dir);
> --
> 2.11.0
>
> _______________________________________________
> U-Boot mailing list
> [hidden email]
> https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Wolfgang Denk
In reply to this post by Heinrich Schuchardt
Dear Heinrich,

In message <[hidden email]> you wrote:

> If 'file' cannot be allocated due to an out of memory
> situation, do not dereference it.
>
> When debugging this patch also avoids a misleading message
> "cannot find next direntry, error %d" in case of an out of
> memory situation. It is sufficent to write
> "%s: Error, no memory for malloc!\n" in this case.
>
> Reported-by: Alex Sadovsky <[hidden email]>
> Signed-off-by: Heinrich Schuchardt <[hidden email]>
> ---
>  fs/ubifs/ubifs.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> index 4465523d5f..313dee0579 100644
> --- a/fs/ubifs/ubifs.c
> +++ b/fs/ubifs/ubifs.c
> @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>   dir = kzalloc(sizeof(struct inode), 0);
>   if (!file || !dentry || !dir) {
>   printf("%s: Error, no memory for malloc!\n", __func__);
> - err = -ENOMEM;
> - goto out;
> + goto out_nomem;
>   }
>  
>   dir->i_sb = sb;
> @@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>   err = PTR_ERR(dent);
>   goto out;
>   }
> -
>   file->f_pos = key_hash_flash(c, &dent->key);
>   file->private_data = dent;
>  
> @@ -463,6 +461,7 @@ out:
>  
>  out_free:
>   kfree(file->private_data);
> +out_nomem:
>   free(file);
>   free(dentry);
>   free(dir);

Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
is no indivcation that an error happened.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Ladislav Michl
On Tue, Nov 21, 2017 at 10:16:40PM +0100, Wolfgang Denk wrote:

> Dear Heinrich,
>
> In message <[hidden email]> you wrote:
> > If 'file' cannot be allocated due to an out of memory
> > situation, do not dereference it.
> >
> > When debugging this patch also avoids a misleading message
> > "cannot find next direntry, error %d" in case of an out of
> > memory situation. It is sufficent to write
> > "%s: Error, no memory for malloc!\n" in this case.
> >
> > Reported-by: Alex Sadovsky <[hidden email]>
> > Signed-off-by: Heinrich Schuchardt <[hidden email]>
> > ---
> >  fs/ubifs/ubifs.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > index 4465523d5f..313dee0579 100644
> > --- a/fs/ubifs/ubifs.c
> > +++ b/fs/ubifs/ubifs.c
> > @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
> >   dir = kzalloc(sizeof(struct inode), 0);
> >   if (!file || !dentry || !dir) {
> >   printf("%s: Error, no memory for malloc!\n", __func__);
> > - err = -ENOMEM;
> > - goto out;
> > + goto out_nomem;
> >   }
> >  
> >   dir->i_sb = sb;
> > @@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
> >   err = PTR_ERR(dent);
> >   goto out;
> >   }
> > -
> >   file->f_pos = key_hash_flash(c, &dent->key);
> >   file->private_data = dent;
> >  
> > @@ -463,6 +461,7 @@ out:
> >  
> >  out_free:
> >   kfree(file->private_data);
> > +out_nomem:
> >   free(file);
> >   free(dentry);
> >   free(dir);
>
> Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
> is no indivcation that an error happened.

It is not obvious from the patch, but value of err is later discarded.
It serves sole purpose of printing debug notice.

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
> There are no data that cannot be plotted on a straight  line  if  the
> axis are chosen correctly.
> _______________________________________________
> U-Boot mailing list
> [hidden email]
> https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Heinrich Schuchardt
In reply to this post by Wolfgang Denk


On 11/21/2017 10:16 PM, Wolfgang Denk wrote:

> Dear Heinrich,
>
> In message <[hidden email]> you wrote:
>> If 'file' cannot be allocated due to an out of memory
>> situation, do not dereference it.
>>
>> When debugging this patch also avoids a misleading message
>> "cannot find next direntry, error %d" in case of an out of
>> memory situation. It is sufficent to write
>> "%s: Error, no memory for malloc!\n" in this case.
>>
>> Reported-by: Alex Sadovsky <[hidden email]>
>> Signed-off-by: Heinrich Schuchardt <[hidden email]>
>> ---
>>   fs/ubifs/ubifs.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
>> index 4465523d5f..313dee0579 100644
>> --- a/fs/ubifs/ubifs.c
>> +++ b/fs/ubifs/ubifs.c
>> @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>>   dir = kzalloc(sizeof(struct inode), 0);
>>   if (!file || !dentry || !dir) {
>>   printf("%s: Error, no memory for malloc!\n", __func__);
>> - err = -ENOMEM;
>> - goto out;
>> + goto out_nomem;
>>   }
>>  
>>   dir->i_sb = sb;
>> @@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>>   err = PTR_ERR(dent);
>>   goto out;
>>   }
>> -
>>   file->f_pos = key_hash_flash(c, &dent->key);
>>   file->private_data = dent;
>>  
>> @@ -463,6 +461,7 @@ out:
>>  
>>   out_free:
>>   kfree(file->private_data);
>> +out_nomem:
>>   free(file);
>>   free(dentry);
>>   free(dir);
>
> Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
> is no indivcation that an error happened.

err is a local variable it is not returned by the function. It is only
used to show a debug message which does not make sense in this case.

The "inidcation" is returning 0 and
printf("%s: Error, no memory for malloc!\n", __func__)

Best regards

Heinrich

>
> Best regards,
>
> Wolfgang Denk
>
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Heinrich Schuchardt
In reply to this post by Ladislav Michl


On 11/21/2017 09:23 PM, Ladislav Michl wrote:

> On Tue, Nov 21, 2017 at 07:45:03PM +0100, Heinrich Schuchardt wrote:
>> If 'file' cannot be allocated due to an out of memory
>> situation, do not dereference it.
>>
>> When debugging this patch also avoids a misleading message
>> "cannot find next direntry, error %d" in case of an out of
>> memory situation. It is sufficent to write
>> "%s: Error, no memory for malloc!\n" in this case.
>>
>> Reported-by: Alex Sadovsky <[hidden email]>
>> Signed-off-by: Heinrich Schuchardt <[hidden email]>
>> ---
>>   fs/ubifs/ubifs.c | 5 ++---
>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
>> index 4465523d5f..313dee0579 100644
>> --- a/fs/ubifs/ubifs.c
>> +++ b/fs/ubifs/ubifs.c
>> @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>>   dir = kzalloc(sizeof(struct inode), 0);
>>   if (!file || !dentry || !dir) {
>>   printf("%s: Error, no memory for malloc!\n", __func__);
>> - err = -ENOMEM;
>> - goto out;
>> + goto out_nomem;
>>   }
>>  
>>   dir->i_sb = sb;
>> @@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>>   err = PTR_ERR(dent);
>>   goto out;
>>   }
>> -
>>   file->f_pos = key_hash_flash(c, &dent->key);
>>   file->private_data = dent;
>>
>    
> This hunk should be probably droped.
>
>> @@ -463,6 +461,7 @@ out:
>>  
>>   out_free:
>>   kfree(file->private_data);
>
> Now question is why is file->private_data ever assigned as it seems nothing
> works with it.

Good catch.

Do we need file and dentry at all in the function?

Unfortunately the file cannot be compiled on x86 cf.
https://lists.denx.de/pipermail/u-boot/2017-November/312166.html

Best regards

Heinrich


>
>> +out_nomem:
>>   free(file);
>>   free(dentry);
>>   free(dir);
>> --
>> 2.11.0
>>
>> _______________________________________________
>> U-Boot mailing list
>> [hidden email]
>> https://lists.denx.de/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Ladislav Michl
On Tue, Nov 21, 2017 at 10:29:51PM +0100, Heinrich Schuchardt wrote:

>
>
> On 11/21/2017 09:23 PM, Ladislav Michl wrote:
> > On Tue, Nov 21, 2017 at 07:45:03PM +0100, Heinrich Schuchardt wrote:
> > > If 'file' cannot be allocated due to an out of memory
> > > situation, do not dereference it.
> > >
> > > When debugging this patch also avoids a misleading message
> > > "cannot find next direntry, error %d" in case of an out of
> > > memory situation. It is sufficent to write
> > > "%s: Error, no memory for malloc!\n" in this case.
> > >
> > > Reported-by: Alex Sadovsky <[hidden email]>
> > > Signed-off-by: Heinrich Schuchardt <[hidden email]>
> > > ---
> > >   fs/ubifs/ubifs.c | 5 ++---
> > >   1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > > index 4465523d5f..313dee0579 100644
> > > --- a/fs/ubifs/ubifs.c
> > > +++ b/fs/ubifs/ubifs.c
> > > @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
> > >   dir = kzalloc(sizeof(struct inode), 0);
> > >   if (!file || !dentry || !dir) {
> > >   printf("%s: Error, no memory for malloc!\n", __func__);
> > > - err = -ENOMEM;
> > > - goto out;
> > > + goto out_nomem;
> > >   }
> > >   dir->i_sb = sb;
> > > @@ -424,7 +423,6 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
> > >   err = PTR_ERR(dent);
> > >   goto out;
> > >   }
> > > -
> > >   file->f_pos = key_hash_flash(c, &dent->key);
> > >   file->private_data = dent;
> > >
> > This hunk should be probably droped.
> >
> > > @@ -463,6 +461,7 @@ out:
> > >   out_free:
> > >   kfree(file->private_data);
> >
> > Now question is why is file->private_data ever assigned as it seems nothing
> > works with it.
>
> Good catch.
>
> Do we need file and dentry at all in the function?

Does not seem so. Also what f_pos is good for is unclear.

> Unfortunately the file cannot be compiled on x86 cf.
> https://lists.denx.de/pipermail/u-boot/2017-November/312166.html

I could give it a try on ARM board. Care to cook an untested patch?

> Best regards
>
> Heinrich
>
>
> >
> > > +out_nomem:
> > >   free(file);
> > >   free(dentry);
> > >   free(dir);
> > > --
> > > 2.11.0
> > >
> > > _______________________________________________
> > > U-Boot mailing list
> > > [hidden email]
> > > https://lists.denx.de/listinfo/u-boot
> >
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Wolfgang Denk
In reply to this post by Ladislav Michl
Dear Ladislav,

In message <20171121212222.ryicwv6tyh5rye2e@lenoch> you wrote:

> > >
> > > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > > index 4465523d5f..313dee0579 100644
> > > --- a/fs/ubifs/ubifs.c
> > > +++ b/fs/ubifs/ubifs.c
> > > @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
> > >   dir = kzalloc(sizeof(struct inode), 0);
> > >   if (!file || !dentry || !dir) {
> > >   printf("%s: Error, no memory for malloc!\n", __func__);
> > > - err = -ENOMEM;
> > > - goto out;
> > > + goto out_nomem;
> > >   }
...
> > Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
> > is no indivcation that an error happened.
>
> It is not obvious from the patch, but value of err is later discarded.
> It serves sole purpose of printing debug notice.

So apparently we have a number of places in U-Boot where fatal
errors (running out of memory) are just ignored and we continue as
if nothing happened?

THis is short-sighted at best. One day Pump Six will fail.

This is giving me the creepes.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [hidden email]
Why don't you have a Linux partition installed so you can be  working
in  a  programmer-friendly environment instead of a keep-gates'-bank-
account-happy one? :-)                            -- Tom Christiansen
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Ladislav Michl
On Wed, Nov 22, 2017 at 09:09:36AM +0100, Wolfgang Denk wrote:

> Dear Ladislav,
>
> In message <20171121212222.ryicwv6tyh5rye2e@lenoch> you wrote:
> > > >
> > > > diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
> > > > index 4465523d5f..313dee0579 100644
> > > > --- a/fs/ubifs/ubifs.c
> > > > +++ b/fs/ubifs/ubifs.c
> > > > @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
> > > >   dir = kzalloc(sizeof(struct inode), 0);
> > > >   if (!file || !dentry || !dir) {
> > > >   printf("%s: Error, no memory for malloc!\n", __func__);
> > > > - err = -ENOMEM;
> > > > - goto out;
> > > > + goto out_nomem;
> > > >   }
> ...
> > > Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
> > > is no indivcation that an error happened.
> >
> > It is not obvious from the patch, but value of err is later discarded.
> > It serves sole purpose of printing debug notice.
>
> So apparently we have a number of places in U-Boot where fatal
> errors (running out of memory) are just ignored and we continue as
> if nothing happened?

While I have to admit this code is not an example of clean coding,
it prints notice when trying to manipulate with file.

fs/ubifs/ubifs.c as whole needs to be revisited, above patch just
caused shit hitting the fan.

> THis is short-sighted at best. One day Pump Six will fail.
>
> This is giving me the creepes.

I was just pointing to the fact, that above mentioned patch does not
make it any worse. Btw, initial commit is even more amazing:

+       if (file)
+               free(file);
+       if (dentry)
+               free(dentry);
+       if (dir)
+               free(dir);
+
+       if (file->private_data)
+               kfree(file->private_data);
+       file->private_data = NULL;
+       file->f_pos = 2;
+       return 0;

.oO(I guess it is safe not pointing where above snippet is comming from,
but will review whole file as I'm going to use it for new board I have to
suport)

Best regards,
        ladis
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/1] ubifs: avoid possible NULL dereference

Heiko Schocher denx
Hello Ladislav,

Sorry for digging into it so late...

Am 22.11.2017 um 09:25 schrieb Ladislav Michl:

> On Wed, Nov 22, 2017 at 09:09:36AM +0100, Wolfgang Denk wrote:
>> Dear Ladislav,
>>
>> In message <20171121212222.ryicwv6tyh5rye2e@lenoch> you wrote:
>>>>>
>>>>> diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
>>>>> index 4465523d5f..313dee0579 100644
>>>>> --- a/fs/ubifs/ubifs.c
>>>>> +++ b/fs/ubifs/ubifs.c
>>>>> @@ -403,8 +403,7 @@ static int ubifs_finddir(struct super_block *sb, char *dirname,
>>>>>   dir = kzalloc(sizeof(struct inode), 0);
>>>>>   if (!file || !dentry || !dir) {
>>>>>   printf("%s: Error, no memory for malloc!\n", __func__);
>>>>> - err = -ENOMEM;
>>>>> - goto out;
>>>>> + goto out_nomem;
>>>>>   }
>> ...
>>>> Should you not keep the "err = -ENOMEM;" setting?  Otherwise there
>>>> is no indivcation that an error happened.
>>>
>>> It is not obvious from the patch, but value of err is later discarded.
>>> It serves sole purpose of printing debug notice.
>>
>> So apparently we have a number of places in U-Boot where fatal
>> errors (running out of memory) are just ignored and we continue as
>> if nothing happened?
>
> While I have to admit this code is not an example of clean coding,
> it prints notice when trying to manipulate with file.
>
> fs/ubifs/ubifs.c as whole needs to be revisited, above patch just
> caused shit hitting the fan.

Yes, full ack ... we do need here a full review of this code.

>> THis is short-sighted at best. One day Pump Six will fail.
>>
>> This is giving me the creepes.
>
> I was just pointing to the fact, that above mentioned patch does not
> make it any worse. Btw, initial commit is even more amazing:
>
> +       if (file)
> +               free(file);
> +       if (dentry)
> +               free(dentry);
> +       if (dir)
> +               free(dir);
> +
> +       if (file->private_data)
> +               kfree(file->private_data);
> +       file->private_data = NULL;
> +       file->f_pos = 2;
> +       return 0;
>
> .oO(I guess it is safe not pointing where above snippet is comming from,
> but will review whole file as I'm going to use it for new board I have to
> suport)

Many thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: [hidden email]
_______________________________________________
U-Boot mailing list
[hidden email]
https://lists.denx.de/listinfo/u-boot