[PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[Chen Gang]

For do_div(), it need 'u64' type, which means the outside must be sure
of 'start' is not bigger than 'stop', or it will report warning.

Even if 'start' was really bigger than 'stop', it would print incorrect
information, but for kernel, it still can continue, so use WARN_ON() is
enough.

The related warning (with allmodconfig for unicore32):

    CC      kernel/power/hibernate.o
  kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
  kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast


Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 kernel/power/hibernate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..d5117d5 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -228,12 +228,13 @@ static void platform_recover(int platform_mode)
 void swsusp_show_speed(struct timeval *start, struct timeval *stop,
 			unsigned nr_pages, char *msg)
 {
-	s64 elapsed_centisecs64;
+	u64 elapsed_centisecs64;
 	int centisecs;
 	int k;
 	int kps;
 
 	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
+	WARN_ON((s64)elapsed_centisecs64 < 0);
 	do_div(elapsed_centisecs64, NSEC_PER_SEC / 100);
 	centisecs = elapsed_centisecs64;
 	if (centisecs == 0)
-- 
1.9.2.459.g68773ac

Re: [PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[Pavel Machek]

On Tue 2014-04-22 09:29:20, Chen Gang wrote:
> For do_div(), it need 'u64' type, which means the outside must be sure
> of 'start' is not bigger than 'stop', or it will report warning.
> 
> Even if 'start' was really bigger than 'stop', it would print incorrect
> information, but for kernel, it still can continue, so use WARN_ON() is
> enough.
> 
> The related warning (with allmodconfig for unicore32):
> 
>     CC      kernel/power/hibernate.o
>   kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
>   kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast
> 
> 

Certainly better, but

> -	s64 elapsed_centisecs64;
> +	u64 elapsed_centisecs64;
>  	int centisecs;
>  	int k;
>  	int kps;
>  
>  	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
> +	WARN_ON((s64)elapsed_centisecs64 < 0);
>  	do_div(elapsed_centisecs64, NSEC_PER_SEC / 100);
>  	centisecs = elapsed_centisecs64;

...do we need to do the WARN_ON()? Only result of underflow will be
very long elapsed time reported... that does not sound too
bad. ... and it will be quite obvious what went wrong.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[Chen Gang]

On 04/22/2014 03:21 PM, Pavel Machek wrote:
> On Tue 2014-04-22 09:29:20, Chen Gang wrote:
>> For do_div(), it need 'u64' type, which means the outside must be sure
>> of 'start' is not bigger than 'stop', or it will report warning.
>>
>> Even if 'start' was really bigger than 'stop', it would print incorrect
>> information, but for kernel, it still can continue, so use WARN_ON() is
>> enough.
>>
>> The related warning (with allmodconfig for unicore32):
>>
>>     CC      kernel/power/hibernate.o
>>   kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
>>   kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast
>>
>>
> 
> Certainly better, but
> 
>> -	s64 elapsed_centisecs64;
>> +	u64 elapsed_centisecs64;
>>  	int centisecs;
>>  	int k;
>>  	int kps;
>>  
>>  	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
>> +	WARN_ON((s64)elapsed_centisecs64 < 0);
>>  	do_div(elapsed_centisecs64, NSEC_PER_SEC / 100);
>>  	centisecs = elapsed_centisecs64;
> 
> ...do we need to do the WARN_ON()? Only result of underflow will be
> very long elapsed time reported... that does not sound too
> bad. ... and it will be quite obvious what went wrong.
> 									Pavel
> 

Hmm... that sounds reasonable to me.  If no any other reply within 2
days, I shall send patch v3 for it.

BTW: sorry, I guess I can not finish allmodconfig for unicore32 within
this month (2014-04-30) -- at present I only finish 40-50%, I
will/should try to finish it within next month.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[Chen Gang]

On 04/22/2014 03:56 PM, Chen Gang wrote:
> On 04/22/2014 03:21 PM, Pavel Machek wrote:
>> On Tue 2014-04-22 09:29:20, Chen Gang wrote:
>>> For do_div(), it need 'u64' type, which means the outside must be sure
>>> of 'start' is not bigger than 'stop', or it will report warning.
>>>
>>> Even if 'start' was really bigger than 'stop', it would print incorrect
>>> information, but for kernel, it still can continue, so use WARN_ON() is
>>> enough.
>>>
>>> The related warning (with allmodconfig for unicore32):
>>>
>>>     CC      kernel/power/hibernate.o
>>>   kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
>>>   kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast
>>>
>>>
>>
>> Certainly better, but
>>
>>> -	s64 elapsed_centisecs64;
>>> +	u64 elapsed_centisecs64;
>>>  	int centisecs;
>>>  	int k;
>>>  	int kps;
>>>  
>>>  	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
>>> +	WARN_ON((s64)elapsed_centisecs64 < 0);

How about to use one line comments instead of WARN_ON()?

	/*
	 * If "(s64)elapsed_centisecs64 < 0", it will print long elapsed
	 * time, it is obvious enough to user for what went wrong.
	 */

>>>  	do_div(elapsed_centisecs64, NSEC_PER_SEC / 100);
>>>  	centisecs = elapsed_centisecs64;
>>
>> ...do we need to do the WARN_ON()? Only result of underflow will be
>> very long elapsed time reported... that does not sound too
>> bad. ... and it will be quite obvious what went wrong.
>> 									Pavel
>>
> 
> Hmm... that sounds reasonable to me.  If no any other reply within 2
> days, I shall send patch v3 for it.
> 
> BTW: sorry, I guess I can not finish allmodconfig for unicore32 within
> this month (2014-04-30) -- at present I only finish 40-50%, I
> will/should try to finish it within next month.
> 
> 
> Thanks.
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[Rafael J. Wysocki]

On Tuesday, April 22, 2014 05:52:36 PM Chen Gang wrote:
> On 04/22/2014 03:56 PM, Chen Gang wrote:
> > On 04/22/2014 03:21 PM, Pavel Machek wrote:
> >> On Tue 2014-04-22 09:29:20, Chen Gang wrote:
> >>> For do_div(), it need 'u64' type, which means the outside must be sure
> >>> of 'start' is not bigger than 'stop', or it will report warning.
> >>>
> >>> Even if 'start' was really bigger than 'stop', it would print incorrect
> >>> information, but for kernel, it still can continue, so use WARN_ON() is
> >>> enough.
> >>>
> >>> The related warning (with allmodconfig for unicore32):
> >>>
> >>>     CC      kernel/power/hibernate.o
> >>>   kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
> >>>   kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast
> >>>
> >>>
> >>
> >> Certainly better, but
> >>
> >>> -	s64 elapsed_centisecs64;
> >>> +	u64 elapsed_centisecs64;
> >>>  	int centisecs;
> >>>  	int k;
> >>>  	int kps;
> >>>  
> >>>  	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
> >>> +	WARN_ON((s64)elapsed_centisecs64 < 0);
> 
> How about to use one line comments instead of WARN_ON()?
> 
> 	/*
> 	 * If "(s64)elapsed_centisecs64 < 0", it will print long elapsed
> 	 * time, it is obvious enough to user for what went wrong.
> 	 */

And will the users actually read this comment?

Please just change the type to silence the warning.  And you can change all of
the other local variables in that function to unsigned int when you're at it.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning

[Chen Gang]

On 04/22/2014 07:29 PM, Rafael J. Wysocki wrote:
> On Tuesday, April 22, 2014 05:52:36 PM Chen Gang wrote:
>> On 04/22/2014 03:56 PM, Chen Gang wrote:
>>> On 04/22/2014 03:21 PM, Pavel Machek wrote:
>>>> On Tue 2014-04-22 09:29:20, Chen Gang wrote:
>>>>> For do_div(), it need 'u64' type, which means the outside must be sure
>>>>> of 'start' is not bigger than 'stop', or it will report warning.
>>>>>
>>>>> Even if 'start' was really bigger than 'stop', it would print incorrect
>>>>> information, but for kernel, it still can continue, so use WARN_ON() is
>>>>> enough.
>>>>>
>>>>> The related warning (with allmodconfig for unicore32):
>>>>>
>>>>>     CC      kernel/power/hibernate.o
>>>>>   kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
>>>>>   kernel/power/hibernate.c:237: warning: comparison of distinct pointer types lacks a cast
>>>>>
>>>>>
>>>>
>>>> Certainly better, but
>>>>
>>>>> -	s64 elapsed_centisecs64;
>>>>> +	u64 elapsed_centisecs64;
>>>>>  	int centisecs;
>>>>>  	int k;
>>>>>  	int kps;
>>>>>  
>>>>>  	elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
>>>>> +	WARN_ON((s64)elapsed_centisecs64 < 0);
>>
>> How about to use one line comments instead of WARN_ON()?
>>
>> 	/*
>> 	 * If "(s64)elapsed_centisecs64 < 0", it will print long elapsed
>> 	 * time, it is obvious enough to user for what went wrong.
>> 	 */
> 
> And will the users actually read this comment?
> 

For subtractions, normally, need signed number, or may let code readers
notice about it. When the code readers read this comment, they will
understand, and save their time to think of.

Normally, it is not good to add comment within a function, except the
code is not written in a normal way, and need some comments to avoid
wasting readers' time.

> Please just change the type to silence the warning.  And you can change all of
> the other local variables in that function to unsigned int when you're at it.
> 

It is fine to me -- change all of the other local variables to unsigned int.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed