[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7b95165-f484-dd33-d9ca-03af725e1d1f@mellanox.com>
Date: Wed, 16 Nov 2016 15:30:10 -0500
From: Chris Metcalf <cmetcalf@...lanox.com>
To: John Stultz <john.stultz@...aro.org>
CC: Thomas Gleixner <tglx@...utronix.de>,
Salman Qazi <sqazi@...gle.com>, Paul Turner <pjt@...gle.com>,
Tony Lindgren <tony@...mide.com>,
Steven Miao <realmz6@...il.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clocksource_cyc2ns: avoid overflowing 64 bits
On 11/16/2016 3:00 PM, John Stultz wrote:
> On Wed, Nov 16, 2016 at 11:56 AM, Chris Metcalf <cmetcalf@...lanox.com> wrote:
>> On 11/16/2016 2:45 PM, John Stultz wrote:
>>> On Wed, Nov 16, 2016 at 11:30 AM, Chris Metcalf <cmetcalf@...lanox.com>
>>> wrote:
>>>> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
>>>> index 08398182f56e..5444429884b8 100644
>>>> --- a/include/linux/clocksource.h
>>>> +++ b/include/linux/clocksource.h
>>>> @@ -171,6 +171,10 @@ static inline u32 clocksource_hz2mult(u32 hz, u32
>>>> shift_constant)
>>>> *
>>>> * Converts cycles to nanoseconds, using the given mult and shift.
>>>> *
>>>> + * The code is optimized for performance and not intended to work
>>>> + * with absolute clocksource cycles, as it will easily overflow,
>>>> + * but just intended for relative (delta) clocksource cycles.
>>>> + *
>>>> * XXX - This could use some mult_lxl_ll() asm optimization
>>> Just as a heads up, it seems your working against an older kernel, as
>>> this didn't apply. Its simple enough to fix up, so I'll do so, but in
>>> the future, please submit patches against something close to Linus
>>> HEAD.
>>
>> Oops, sorry; it wasn't version skew (I'm at v4.9-rc4) but whitespace damage.
>> I assumed if I just pasted the patch into Thunderbird it would work, since
>> it had
>> no tabs. But bizarrely, if I look at the patch in the mailer, it shows a
>> two-space
>> prefix, but when I save the email to a file, it has a three-space prefix.
>> WTF?
> Yea. Not many mailers can be trusted with sending patches. I'd
> recommend git-send-email. :)
Yes, indeed. That is what I always do normally. But since I was
already part way through an email written interactively in my mailer,
I figured I'd be lazy and paste it in. Lesson learned...
That said, it is annoyingly difficult to pick up an in-progress email
and convert it into something you can edit in, say, Emacs. You end up
having to cut and paste the "To:" and "Cc:" and "Subject:" information
out of your mailer's helpful GUI and into Emacs in the standard RFC822
way that git send-email understands. I'm not sure there's a better
way, but at least I feel better now that I've complained about it :-)
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
Powered by blists - more mailing lists