All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: David Howells <dhowells@redhat.com>
Cc: Christian Brauner <christian@brauner.io>,
	Jeff Layton <jlayton@kernel.org>,
	Gao Xiang <hsiangkao@linux.alibaba.com>,
	Steve French <smfrench@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Marc Dionne <marc.dionne@auristor.com>,
	Paulo Alcantara <pc@manguebit.com>,
	Shyam Prasad N <sprasad@microsoft.com>,
	Tom Talpey <tom@talpey.com>,
	Eric Van Hensbergen <ericvh@kernel.org>,
	Ilya Dryomov <idryomov@gmail.com>,
	linux-cachefs@redhat.com, linux-afs@lists.infradead.org,
	linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org,
	ceph-devel@vger.kernel.org, v9fs@lists.linux.dev,
	linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Latchesar Ionkov <lucho@ionkov.net>,
	Christian Schoenebeck <linux_oss@crudebyte.com>
Subject: Re: [PATCH 4/5] 9p: Always update remote_i_size in stat2inode
Date: Thu, 4 Jan 2024 04:42:24 +0900	[thread overview]
Message-ID: <ZZW4oEuzCx-7AYpo@codewreck.org> (raw)
In-Reply-To: <20240103145935.384404-5-dhowells@redhat.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Dominique Martinet <asmadeus@codewreck.org>
To: David Howells <dhowells@redhat.com>
Cc: Latchesar Ionkov <lucho@ionkov.net>,
	Christian Schoenebeck <linux_oss@crudebyte.com>,
	linux-mm@kvack.org, Marc Dionne <marc.dionne@auristor.com>,
	linux-afs@lists.infradead.org, Paulo Alcantara <pc@manguebit.com>,
	linux-cifs@vger.kernel.org, Matthew Wilcox <willy@infradead.org>,
	Steve French <smfrench@gmail.com>,
	linux-cachefs@redhat.com, Gao Xiang <hsiangkao@linux.alibaba.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	Shyam Prasad N <sprasad@microsoft.com>,
	Tom Talpey <tom@talpey.com>,
	ceph-devel@vger.kernel.org,
	Eric Van Hensbergen <ericvh@kernel.org>,
	Christian Brauner <christian@brauner.io>,
	linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
	v9fs@lists.linux.dev, Jeff Layton <jlayton@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH 4/5] 9p: Always update remote_i_size in stat2inode
Date: Thu, 4 Jan 2024 04:42:24 +0900	[thread overview]
Message-ID: <ZZW4oEuzCx-7AYpo@codewreck.org> (raw)
In-Reply-To: <20240103145935.384404-5-dhowells@redhat.com>

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

  reply	other threads:[~2024-01-03 19:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-03 14:59 [PATCH 0/5] netfs, cachefiles, 9p: Additional patches David Howells
2024-01-03 14:59 ` David Howells
2024-01-03 14:59 ` [PATCH 1/5] cachefiles: Fix __cachefiles_prepare_write() David Howells
2024-01-03 14:59   ` David Howells
2024-01-07 16:09   ` Simon Horman
2024-01-07 16:09     ` Simon Horman
2024-01-08 22:31     ` David Howells
2024-01-08 22:31       ` David Howells
2024-01-09  8:32       ` Simon Horman
2024-01-09  8:32         ` Simon Horman
2024-01-03 14:59 ` [PATCH 2/5] 9p: Fix initialisation of netfs_inode for 9p David Howells
2024-01-03 14:59   ` David Howells
2024-01-03 14:59 ` [PATCH 3/5] 9p: Do a couple of cleanups David Howells
2024-01-03 14:59   ` David Howells
2024-01-03 19:45   ` Dominique Martinet
2024-01-03 19:45     ` Dominique Martinet
2024-01-03 14:59 ` [PATCH 4/5] 9p: Always update remote_i_size in stat2inode David Howells
2024-01-03 14:59   ` David Howells
2024-01-03 19:42   ` Dominique Martinet [this message]
2024-01-03 19:42     ` Dominique Martinet
2024-01-03 14:59 ` [PATCH 5/5] 9p: Use length of data written to the server in preference to error David Howells
2024-01-03 14:59   ` David Howells
2024-01-03 19:46   ` Dominique Martinet
2024-01-03 19:46     ` Dominique Martinet
2024-01-03 15:47 ` [PATCH 6/5] netfs: Rearrange netfs_io_subrequest to put request pointer first David Howells
2024-01-03 15:47   ` David Howells
2024-01-03 21:15 ` [PATCH 7/5] netfs: Fix proc/fs/fscache symlink to point to "netfs" not "../netfs" David Howells
2024-01-03 21:15   ` David Howells
2024-01-05 10:33 ` [PATCH 0/5] netfs, cachefiles, 9p: Additional patches Christian Brauner
2024-01-05 10:33   ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZZW4oEuzCx-7AYpo@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=christian@brauner.io \
    --cc=dhowells@redhat.com \
    --cc=ericvh@kernel.org \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=marc.dionne@auristor.com \
    --cc=netdev@vger.kernel.org \
    --cc=pc@manguebit.com \
    --cc=smfrench@gmail.com \
    --cc=sprasad@microsoft.com \
    --cc=tom@talpey.com \
    --cc=v9fs@lists.linux.dev \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.