netdev - Re: [PATCH 4/5] 9p: Always update remote_i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZZW4oEuzCx-7AYpo@codewreck.org>
Date: Thu, 4 Jan 2024 04:42:24 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: David Howells <dhowells@...hat.com>
Cc: Christian Brauner <christian@...uner.io>,
	Jeff Layton <jlayton@...nel.org>,
	Gao Xiang <hsiangkao@...ux.alibaba.com>,
	Steve French <smfrench@...il.com>,
	Matthew Wilcox <willy@...radead.org>,
	Marc Dionne <marc.dionne@...istor.com>,
	Paulo Alcantara <pc@...guebit.com>,
	Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
	Eric Van Hensbergen <ericvh@...nel.org>,
	Ilya Dryomov <idryomov@...il.com>, linux-cachefs@...hat.com,
	linux-afs@...ts.infradead.org, linux-cifs@...r.kernel.org,
	linux-nfs@...r.kernel.org, ceph-devel@...r.kernel.org,
	v9fs@...ts.linux.dev, linux-erofs@...ts.ozlabs.org,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Latchesar Ionkov <lucho@...kov.net>,
	Christian Schoenebeck <linux_oss@...debyte.com>
Subject: Re: [PATCH 4/5] 9p: Always update remote_i_size in stat2inode

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