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: <12673353.5lG2WgRb0V@wuerfel>
Date:	Sun, 26 Oct 2014 21:34:19 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Thomas Gleixner <tglx@...utronix.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 Saturday 25 October 2014 19:32:09 Thomas Gleixner wrote:
> 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
> Date:	Yesterday 19:32:09
> 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.

We have around 20 drivers using ktime_get_ts() or getrawmonotonic().
If we had a 'struct monotonic_timespec', we could trivially convert
them, otherwise we have to look at each one individually to figure
out what they should use, in particular if they would have noticeably
worse performance by moving to ktime_get_ts64 or getrawmonotonic64.

The way to do that would be to add 

#define monotonic_timespec timespec

now, and rename timespec to monotonic_timespec after we are done
converting all other in-kernel users of timespec. There are probably
a few drivers that today use do_gettimeofday or getnstimeofday that
could be converted to use ktime_get_ts using a 32-bit
monotonic_timespec.

The alternative to that would be to make them all use ktime_t, which
might be more efficient but also more work to do.

> > - 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.

I think I like the u32 approach better than ktime_t, but it's a
very mild preference. I'll wait for your reply on the monotonic_time_t/
monotonic_timespec comments above. Maybe John has an opinion as well.

Heena, could you prepare a new patch using u32 once we have worked out
the ktime_sec implementation?

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