On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann arnd@arndb.de wrote:
On Wednesday, June 8, 2016 10:04:45 PM CEST Deepa Dinamani wrote:
CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will be transitioned to use 64 bit time along with vfs in a separate patch. There is no plan to transistion CURRENT_TIME_SEC to use y2038 safe time interfaces.
current_fs_time() will also be extended to use superblock range checking parameters when range checking is introduced.
This works because alloc_super() fills in the the s_time_gran in super block to NSEC_PER_SEC.
Also note that filesystem specific times like the birthtime, creation time that were using same interfaces to obtain time retain same logistics.
Signed-off-by: Deepa Dinamani deepa.kernel@gmail.com
one question:
In an earlier version, you had a small optimization to use ktime_get_real_seconds() instead of current_kernel_time() when the granularity is seconds.
Do you still plan to send that one, or did you decide we don't need it?
I was actually planning to use get_seconds() instead of current_kernel_time(). And, transition both along with vfs to y2038 safe apis. Difference between ktime_get_real_seconds() and current_kernel_time64() is not much because they both require sequence counter.
It didn't make sense to me to optimize current_fs_time() for seconds only, and not optimize for 1ns granularity also. I plan to make changes to the function depending on how we end up using timespec_trunc() after the addition of range checking.
Thanks for the guidance on inclusion of reviewers. I'll follow this approach when I post v2 of the series.
-Deepa