[PATCH] time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()

[PATCH] time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()

[Boris Ostrovsky]

With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in update_vsyscall()
may lose upper bits or, worse, add them since compiler will do this:
	(u64)(tk->wall_to_monotonic.tv_nsec << tk->shift)
instead of
	((u64)tk->wall_to_monotonic.tv_nsec << tk->shift)

So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up
with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in
the subsequent 'while' loop.

We need explicit cast.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: stable@vger.kernel.org
---
 arch/x86/kernel/vsyscall_gtod.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_gtod.c b/arch/x86/kernel/vsyscall_gtod.c
index f9c6e56..9531fbb 100644
--- a/arch/x86/kernel/vsyscall_gtod.c
+++ b/arch/x86/kernel/vsyscall_gtod.c
@@ -43,7 +43,7 @@ void update_vsyscall(struct timekeeper *tk)
 	vdata->monotonic_time_sec	= tk->xtime_sec
 					+ tk->wall_to_monotonic.tv_sec;
 	vdata->monotonic_time_snsec	= tk->xtime_nsec
-					+ (tk->wall_to_monotonic.tv_nsec
+					+ ((u64)tk->wall_to_monotonic.tv_nsec
 						<< tk->shift);
 	while (vdata->monotonic_time_snsec >=
 					(((u64)NSEC_PER_SEC) << tk->shift)) {
-- 
1.7.1

Re: [PATCH] time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()

[H. Peter Anvin]

On 05/09/2014 08:11 AM, Boris Ostrovsky wrote:
> With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
> systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in update_vsyscall()
> may lose upper bits or, worse, add them since compiler will do this:
> 	(u64)(tk->wall_to_monotonic.tv_nsec << tk->shift)
> instead of
> 	((u64)tk->wall_to_monotonic.tv_nsec << tk->shift)
> 
> So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up
> with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in
> the subsequent 'while' loop.
> 
> We need explicit cast.
> 
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: stable@vger.kernel.org

This is needed in stable only for v3.14, right?

	-hpa

Re: [PATCH] time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()

[Boris Ostrovsky]

On 05/09/2014 11:43 AM, H. Peter Anvin wrote:
> On 05/09/2014 08:11 AM, Boris Ostrovsky wrote:
>> With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
>> systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in update_vsyscall()
>> may lose upper bits or, worse, add them since compiler will do this:
>> 	(u64)(tk->wall_to_monotonic.tv_nsec << tk->shift)
>> instead of
>> 	((u64)tk->wall_to_monotonic.tv_nsec << tk->shift)
>>
>> So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up
>> with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in
>> the subsequent 'while' loop.
>>
>> We need explicit cast.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Cc: stable@vger.kernel.org
> This is needed in stable only for v3.14, right?

I suspect anything that has commit 650ea024 needs to be fixed. I see 
this code, for example, in 3.12 (it used to be in vsyscall_64.c).

-boris

Re: [PATCH] time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()

[H. Peter Anvin]

On 05/09/2014 08:59 AM, Boris Ostrovsky wrote:
> On 05/09/2014 11:43 AM, H. Peter Anvin wrote:
>> On 05/09/2014 08:11 AM, Boris Ostrovsky wrote:
>>> With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
>>> systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in
>>> update_vsyscall()
>>> may lose upper bits or, worse, add them since compiler will do this:
>>>     (u64)(tk->wall_to_monotonic.tv_nsec << tk->shift)
>>> instead of
>>>     ((u64)tk->wall_to_monotonic.tv_nsec << tk->shift)
>>>
>>> So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up
>>> with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in
>>> the subsequent 'while' loop.
>>>
>>> We need explicit cast.
>>>
>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Cc: stable@vger.kernel.org
>> This is needed in stable only for v3.14, right?
> 
> I suspect anything that has commit 650ea024 needs to be fixed. I see
> this code, for example, in 3.12 (it used to be in vsyscall_64.c).
> 

But you're talking about 32-bit platforms.  Vsyscalls aren't used on
x86-32 until 3.14.  Am I missing something?

	-hpa

Re: [PATCH] time: Cast tv_nsec to u64 for proper shifting in update_vsyscall()

[Boris Ostrovsky]

On 05/09/2014 12:03 PM, H. Peter Anvin wrote:
> On 05/09/2014 08:59 AM, Boris Ostrovsky wrote:
>> On 05/09/2014 11:43 AM, H. Peter Anvin wrote:
>>> On 05/09/2014 08:11 AM, Boris Ostrovsky wrote:
>>>> With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit
>>>> systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in
>>>> update_vsyscall()
>>>> may lose upper bits or, worse, add them since compiler will do this:
>>>>      (u64)(tk->wall_to_monotonic.tv_nsec << tk->shift)
>>>> instead of
>>>>      ((u64)tk->wall_to_monotonic.tv_nsec << tk->shift)
>>>>
>>>> So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up
>>>> with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in
>>>> the subsequent 'while' loop.
>>>>
>>>> We need explicit cast.
>>>>
>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> Cc: stable@vger.kernel.org
>>> This is needed in stable only for v3.14, right?
>> I suspect anything that has commit 650ea024 needs to be fixed. I see
>> this code, for example, in 3.12 (it used to be in vsyscall_64.c).
>>
> But you're talking about 32-bit platforms.  Vsyscalls aren't used on
> x86-32 until 3.14.  Am I missing something?

Oh, yes, of course. I was just looking at code without thinking. 3.14 
only then.

-boris