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
On Friday, June 10, 2016 10:03:14 PM CEST Deepa Dinamani wrote:
> On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann wrote:
> >
> > In an earlier version, you had a small optimization to
> > use ktime_get_real_seconds() instead of current_kernel_time()
> > when the granularity is
On Fri, Jun 10, 2016 at 3:21 PM, Arnd Bergmann 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
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.
>
>
On Thu, Jun 9, 2016 at 12:35 AM, Jan Kara wrote:
>
> You create line longer than 80 characters for affs and reiserfs. Please
> wrap those lines properly.
No, please do *NOT* do things like that.
These kind of mechanical patches should
(a) be as mechanical as possible (and see
On Wed, Jun 08, 2016 at 10:04:45PM -0700, 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.
[...]
>
On Wed 08-06-16 22:04:45, 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()