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.) -- Dominique Martinet | Asmadeus