On Saturday, June 25, 2016 2:37:24 PM CEST Deepa Dinamani wrote:
> The series is aimed at getting rid of CURRENT_TIME, CURRENT_TIME_SEC macros
> and replacing current_fs_time() with current_time().
> The macros are not y2038 safe. There is no plan to transition them into being
> y2038 safe.
> ktime_get_* api's can be used in their place. And, these are y2038 safe.
>
> CURRENT_TIME will be deleted after 4.8 rc1 as there is a dependency function
> time64_to_tm() for one of the CURRENT_TIME occurance.
>
> Thanks to Arnd Bergmann for all the guidance and discussions.
>
> Patches 3-5 were mostly generated using coccinelle.
>
> All filesystem timestamps use current_fs_time() for right granularity as
> mentioned in the respective commit texts of patches. This has a changed
> signature, renamed to current_time() and moved to the fs/inode.c.
>
> This series also serves as a preparatory series to transition vfs to 64 bit
> timestamps as outlined here: https://lkml.org/lkml/2016/2/12/104 .
>
> As per Linus's suggestion in https://lkml.org/lkml/2016/5/24/663 , all the
> inode timestamp changes have been squashed into a single patch. Also,
> current_time() now is used as a single generic vfs filesystem timestamp api.
> It also takes struct inode* as argument instead of struct super_block*.
> Posting all patches together in a bigger series so that the big picture is
> clear.
>
> As per the suggestion in https://lwn.net/Articles/672598/, CURRENT_TIME macro
> bug fixes are being handled in a series separate from transitioning vfs to use.
>
Everything in this version looks good to me. Please add
Reviewed-by: Arnd Bergmann <[email protected]>
and send a pull request to Al Viro, based on the latest linux-4.7-rc release.
Arnd