linux-kernel - Re: [Y2038] [PATCH] aoe: Use 64-bit timestamp in frame

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5552A778.6070603@acm.org>
Date:	Tue, 12 May 2015 21:23:04 -0400
From:	Ed Cashin <ed.cashin@....org>
To:	Arnd Bergmann <arnd@...db.de>, y2038@...ts.linaro.org
CC:	Tina Ruchandani <ruchandani.tina@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [PATCH] aoe: Use 64-bit timestamp in frame

On 05/12/2015 07:14 AM, Arnd Bergmann wrote:
> On Tuesday 12 May 2015 11:44:21 Arnd Bergmann wrote:
>> There are of course multiple ways to do this. One way would be to
>> change the code to work on 32-bit nanoseconds instead of 32-bit
>> microseconds. This requires proving that the we cannot exceed
>> 4.29 seconds of round-trip time in calc_rttavg().
>> Is that a valid assumption or not?
>>
>> If not, we could replace do_gettimeofday() with ktime_get_ts64().
>> This will ensure we don't need a 64-bit division when converting
>> the ts64 to a 32-bit microsecond value, and combined with the
>> conversion is still no slower than do_gettimeofday(), and it
>> still avoids the double bookkeeping because it uses a monotonic
>> timebase that is robust against settimeofday.
> Two other approaches that occurred to me later:
>
> - introduce common ktime_get_ms(), ktime_get_us(), ktime_get_real_ms()
>    and ktime_get_real_is() interfaces, to match the other interfaces
>    we already provide. These could be done as efficiently or better
>    than what aoe does manually today.
>
> - change the timebase that is used for the computations in aoe to use
>    scaled nanoseconds instead of microseconds. Using
>
>    u32 time = ktime_get_ns() >> 10;
>
>    would give you a similar range and precision as microseconds, but
>    completely avoid integer division. You could also use a different
>    shift value to either extend the range beyond 71 minutes, or the
>    extend the precision to something below a microsecond. This would
>    be the most efficient implementation, but also require significant
>    changes to the driver.
>

That is an interesting idea.  People do care about aoe_deadsecs being
pretty accurate, so there would need to be a way to make that remain
accurate.  The driver will fail outstanding I/O to the target and mark it
as "down" after unsuccessfully retransmitting commands to the target
for a number of seconds equal to aoe_deadsecs.

As to the efficient ktime_get_us idea, that sounds appealing since you
mention that they would be efficient.

Thanks for the analysis.

-- 
   Ed
--
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/