[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALAqxLWwJBLD8Z0qJhnk0x4t+KbDi5k98HNQLvYEUCZ5ioCYHw@mail.gmail.com>
Date: Wed, 6 May 2015 14:43:07 -0700
From: John Stultz <john.stultz@...aro.org>
To: Nicolas Pitre <nicolas.pitre@...aro.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Josh Boyer <jwboyer@...hat.com>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Trevor Cordes <trevor@...nopolis.ca>
Subject: Re: [RFC][PATCH v2] ktime: Fix ktime_divns to do signed division
On Wed, May 6, 2015 at 1:11 PM, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> On Wed, 6 May 2015, John Stultz wrote:
>
>> It was noted that the 32bit implementation of ktime_divns()
>> was doing unsigned division and didn't properly handle
>> negative values.
>>
>> This patch fixes the problem by checking and preserving
>> the sign bit, and then reapplying it if appropriate after
>> the division, it also changes the return type to a s64
>> to make it more obvious this is expected.
>>
> [...]
>>
>> -# define ktime_divns(kt, div) (u64)((kt).tv64 / (div))
>> +static inline s64 ktime_divns(const ktime_t kt, s64 div)
>> +{
>> + /*
>> + * 32-bit implementation cannot handle negative divisors,
>> + * so catch them on 64bit as well.
>> + */
>> + BUG_ON(div < 0);
>> + return (u64)((kt).tv64 / (div))
>
> You forgot to remove the u64 cast?
Thanks for catching that!
> Is there a reason why it was there originally?
I assume because nanoseconds are usually though of as unsigned. It was
introduced way back in the original hrtimer core code:
c0a3132963db68f1fbbd0e316b73de100fee3f08
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists