diff mbox series

[4/5] 9p: Always update remote_i_size in stat2inode

Message ID 20240103145935.384404-5-dhowells@redhat.com (mailing list archive)
State New
Headers show
Series netfs, cachefiles, 9p: Additional patches | expand

Commit Message

David Howells Jan. 3, 2024, 2:59 p.m. UTC
Always update remote_i_size in v9fs_stat2inode*() if the size is available,
even if we are asked not to update i_isize

Suggested-by: Dominique Martinet <asmadeus@codewreck.org>
Link: https://lore.kernel.org/r/ZZVctju5TEjS218p@codewreck.org/
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Van Hensbergen <ericvh@kernel.org>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: Christian Schoenebeck <linux_oss@crudebyte.com>
cc: v9fs@lists.linux.dev
cc: linux-cachefs@redhat.com
cc: linux-fsdevel@vger.kernel.org
---
 fs/9p/vfs_inode_dotl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Dominique Martinet Jan. 3, 2024, 7:42 p.m. UTC | #1
David Howells wrote on Wed, Jan 03, 2024 at 02:59:28PM +0000:
> Always update remote_i_size in v9fs_stat2inode*() if the size is available,
> even if we are asked not to update i_isize

Sorry -- hold on for this patch, let's drop it for now and take it more
slowly through next cycle.

I had mostly forgotten about V9FS_STAT2INODE_KEEP_ISIZE and not paying
enough attention yesterday evening, but it's not innocent -- I assume
netfs will do the right thing if we update the *remote* i_size when
there is cached data, but the inode's i_size cannot be updated as
easily.

It's hard to notice because the comment got split in 5e3cc1ee1405a7
("9p: use inode->i_lock to protect i_size_write() under 32-bit"), but
v9fs_refresh_inode* still have it:
        /*      
         * We don't want to refresh inode->i_size,
         * because we may have cached data
         */

I assume refreshing i_size at a bad time would act like a truncation
of cached memory.

(To answer the other thread's comment that v9fs_i_size_write is useless;
it's far from obvious enough but I'm afraid it is needed:
- include/linux/fs.h has a comment saying i_size_write does need locking
around it for 32bit to avoid breaking i_size_seqcount; that's still true
in today's tree.
- we could use any lock as long as it's coherent within the 9p
subsystem, but we don't need a whole mutex so i_lock it is.)
diff mbox series

Patch

diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
index 3505227e1704..aa3a77bb5e86 100644
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -684,10 +684,10 @@  v9fs_stat2inode_dotl(struct p9_stat_dotl *stat, struct inode *inode,
 			mode |= inode->i_mode & ~S_IALLUGO;
 			inode->i_mode = mode;
 		}
-		if (!(flags & V9FS_STAT2INODE_KEEP_ISIZE) &&
-		    stat->st_result_mask & P9_STATS_SIZE) {
+		if (stat->st_result_mask & P9_STATS_SIZE) {
 			v9inode->netfs.remote_i_size = stat->st_size;
-			v9fs_i_size_write(inode, stat->st_size);
+			if (!(flags & V9FS_STAT2INODE_KEEP_ISIZE))
+				v9fs_i_size_write(inode, stat->st_size);
 		}
 		if (stat->st_result_mask & P9_STATS_BLOCKS)
 			inode->i_blocks = stat->st_blocks;