fuse uses 64-bit seconds for inode timestamps in the user interface,
which will work basically forever, but the VFS uses struct timespec
for timestamps, which is only good until 2038 on 32-bit CPUs.

This gets us one small step closer to lifting the VFS limit by using
struct inode_time in fuse.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Cc: Miklos Szeredi <mik...@szeredi.hu>
Cc: fuse-de...@lists.sourceforge.net
---
 fs/fuse/inode.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 754dcf2..58f138e 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -203,7 +203,7 @@ void fuse_change_attributes(struct inode *inode, struct 
fuse_attr *attr,
        struct fuse_inode *fi = get_fuse_inode(inode);
        bool is_wb = fc->writeback_cache;
        loff_t oldsize;
-       struct timespec old_mtime;
+       struct inode_time old_mtime;
 
        spin_lock(&fc->lock);
        if ((attr_version != 0 && fi->attr_version > attr_version) ||
@@ -232,7 +232,7 @@ void fuse_change_attributes(struct inode *inode, struct 
fuse_attr *attr,
                        truncate_pagecache(inode, attr->size);
                        inval = true;
                } else if (fc->auto_inval_data) {
-                       struct timespec new_mtime = {
+                       struct inode_time new_mtime = {
                                .tv_sec = attr->mtime,
                                .tv_nsec = attr->mtimensec,
                        };
@@ -241,7 +241,7 @@ void fuse_change_attributes(struct inode *inode, struct 
fuse_attr *attr,
                         * Auto inval mode also checks and invalidates if mtime
                         * has changed.
                         */
-                       if (!timespec_equal(&old_mtime, &new_mtime))
+                       if (!inode_time_equal(&old_mtime, &new_mtime))
                                inval = true;
                }
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to