Message ID | 1455269766-2994-3-git-send-email-deepa.kernel@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
diff --git a/fs/cifs/cache.c b/fs/cifs/cache.c index 6c665bf..f0892ac 100644 --- a/fs/cifs/cache.c +++ b/fs/cifs/cache.c @@ -221,8 +221,8 @@ const struct fscache_cookie_def cifs_fscache_super_index_def = { * Auxiliary data attached to CIFS inode within the cache */ struct cifs_fscache_inode_auxdata { - struct timespec last_write_time; - struct timespec last_change_time; + struct vfs_time last_write_time; + struct vfs_time last_change_time; u64 eof; };
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. aux data timestamps are only used to read in inode timestamps. Hence, they need to change data type along with vfs times. struct timespec64 is the same as struct timespec on 64 bit systems. So it is a no-op on 64 bit systems. The buffer length(datalen) passed in to read in auxdata in cifs_fscache_inode_get_aux() and cifs_fscache_inode_check_aux() should be big enough for the data type change from struct timespec to struct timespec64 to be safe on 32 bit systems. Following provide support for safe usage on 32 bit systems: 1. datalen already accounts for struct timespec64 on 64 bit systems. 2. datalen passed in is a constant with sufficient space to accommodate auxdata. 3. The keylen subtracted from datalen is a constant and also leaves in sufficient space for increase. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> --- fs/cifs/cache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)