On Monday 15 February 2016 08:00:50 Dave Chinner wrote:
> On Sat, Feb 13, 2016 at 05:46:11PM -0800, Deepa Dinamani wrote:
> > On Sat, Feb 13, 2016 at 2:08 PM, Dave Chinner wrote:
> > > On Fri, Feb 12, 2016 at 01:36:05AM -0800, Deepa Dinamani wrote:
> So, excuse me if I made
On Sat, Feb 13, 2016 at 05:46:11PM -0800, Deepa Dinamani wrote:
> On Sat, Feb 13, 2016 at 2:08 PM, Dave Chinner wrote:
> > On Fri, Feb 12, 2016 at 01:36:05AM -0800, Deepa Dinamani wrote:
> >> The VFS inode timestamps are not y2038 safe as they use
> >> struct timespec. These
On Fri, Feb 12, 2016 at 01:36:05AM -0800, Deepa Dinamani wrote:
> The VFS inode timestamps are not y2038 safe as they use
> struct timespec. These will be changed to use struct timespec64
> instead and that is y2038 safe.
> But, since the above data type conversion will break the end
> file
>> static inline void ceph_encode_timespec(struct ceph_timespec *tv,
>> const struct timespec *ts)
>> {
>> tv->tv_sec = cpu_to_le32((u32)ts->tv_sec);
>> tv->tv_nsec = cpu_to_le32((u32)ts->tv_nsec);
>> }
Pointed to decode function change in
The VFS inode timestamps are not y2038 safe as they use
struct timespec. These will be changed to use struct timespec64
instead and that is y2038 safe.
But, since the above data type conversion will break the end
file systems, use vfs_time aliases here to access inode times.
These timestamps are