linux-kernel - Re: [PATCH v5] timekeeping: Added a function to return tv_sec portion of ktime_get

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: <alpine.DEB.2.11.1410251903000.5308@nanos>
Date:	Sat, 25 Oct 2014 19:32:09 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Heena Sirwani <heenasirwani@...il.com>,
	linux-kernel@...r.kernel.org, john.stultz@...aro.org
Subject: Re: [PATCH v5] timekeeping: Added a function to return tv_sec portion
 of ktime_get_ts64()

On Sat, 25 Oct 2014, Arnd Bergmann wrote:
> On Saturday 25 October 2014 17:22:23 Thomas Gleixner wrote:
> > Hmm. Thinking more about it. That's actually overkill. For ktime_sec a
> > 32bit value is plenty enough unless we care about systems with more
> > than 136 years uptime. So if we calculate the seconds value of ktime,
> > i.e. CLOCK_MONOTONIC, in the update function, we can read it on both
> > 32 and 64bit w/o the seqcount loop.
> 
> Ah, very good point. That opens the question which type that function
> should return. I really want to remove all uses of time_t from the
> kernel, mostly so we know when we're done with this. However as you
> say we know that we only need a 32-bit value here. Some possible
> ideas:
> 
> - use time64_t here anyway and accept the slight inefficiency in return
>   for clarity

Probably the simplest option.

> - introduce a monotonic_time_t (we probably also want a struct
>   monotonic_timespec if we do that) which is basically the old time_t
>   but is known to be y2038 safe because we only ever use it to store
>   monotonic times.

Not sure whether its worth the trouble.

> - return u32 and use the same type in the callers instead of
>   time_t/time64_t/monotonic_time_t.

Works as well. I have no immediate preference.
 
> > Where we really need the above readout mechanism is get_seconds() as
> > that will break in 2038 on 32bit. So there you need to change the
> > return value from unsigned long to time64_t and change the
> > implementation as above just xtime_sec instead of ktime_sec.
> 
> Heena already posted a first draft of that patch to the opw internal
> mailing list, I found a small issue that needs to be resolved and
> then she can post the new version to you for review.

Great!

Thanks,

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