linux-kernel - Re: [PATCH] [RESEND] aoe: use ktime

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: <7b4d1840-103f-dfb8-3918-678fdc93d816@kernel.dk>
Date:   Wed, 17 Jan 2018 08:41:42 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Arnd Bergmann <arnd@...db.de>, "Ed L. Cashin" <ed.cashin@....org>
Cc:     Tina Ruchandani <ruchandani.tina@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RESEND] aoe: use ktime_t instead of timeval

On 1/17/18 8:30 AM, Arnd Bergmann wrote:
> From: Tina Ruchandani <ruchandani.tina@...il.com>
> 
> 'struct frame' uses two variables to store the sent timestamp - 'struct
> timeval' and jiffies. jiffies is used to avoid discrepancies caused by
> updates to system time. 'struct timeval' is deprecated because it uses
> 32-bit representation for seconds which will overflow in year 2038.
> 
> This patch does the following:
> - Replace the use of 'struct timeval' and jiffies with ktime_t, which
>   is the recommended type for timestamping
> - ktime_t provides both long range (like jiffies) and high resolution
>   (like timeval). Using ktime_get (monotonic time) instead of wall-clock
>   time prevents any discprepancies caused by updates to system time.
> 
> [updates by Arnd below]
> The original patch from Tina never went anywhere as we discussed how
> to keep the impact on performance minimal. I've started over now but
> arrived at basically the same patch that she had originally, except for
> an slightly improved tsince_hr() function. I'm making it more robust
> against overflows, and also optimize explicitly for the common case
> in which a frame is less than 4.2 seconds old, using only a 32-bit
> division in that case.
> 
> This should make the new version more efficient than the old code,
> since we replace the existing two 32-bit division in do_gettimeofday()
> plus one multiplication with a single single 32-bit division in
> tsince_hr() and drop the double bookkeeping. It's also more efficient
> than the ktime_get_us() API we discussed before, since that would
> also rely on multiple divisions.

Applied, thanks Arnd/Tina.

-- 
Jens Axboe