All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Tingmao Wang <m@maowtm.org>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
	Eric Van Hensbergen <ericvh@kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>,
	v9fs@lists.linux.dev
Subject: Re: [PATCH 1/1] fs/9p: Do not open remote file with APPEND mode when writeback cache is used
Date: Mon, 3 Nov 2025 08:07:29 +0900	[thread overview]
Message-ID: <aQfkMUncxteb9aPW@codewreck.org> (raw)
In-Reply-To: <ed2d3f0045f538e8ddbd2d0a151e31767dda87e8.1762115015.git.m@maowtm.org>

Tingmao Wang wrote on Sun, Nov 02, 2025 at 08:24:39PM +0000:
> When page cache is used, writebacks are done on a page granularity, and it
> is expected that the underlying filesystem (such as v9fs) should respect
> the write position.  However, currently v9fs will passthrough O_APPEND to
> the server even on cached mode.  This causes data corruption if a sync or
> fstat gets between two writes to the same file.

Ugh.. I'd never expect O_APPEND to have any effect on the server tbh,
9p writes are "pwrite"-like, the offset is always specified -- there is
no plain write(fid, data) call -- so O_APPEND should have nothing to do
with the remote :/

(well, man pwrite(2) does say this... So that explains the behavior if
qemu respects the flag:
BUGS
   POSIX requires that opening a file with the O_APPEND flag should have
   no effect on the location at which pwrite() writes data. However, on
   Linux, if a file is opened with O_APPEND, pwrite() appends data to the
   end of the file, regardless of the value of offset. 
)

I guess I can see this being useful if multiple clients are involved in
cacheless mode, but I agree any kind of data cache should strip this
flag.
(I think this didn't cause problem in other cache modes because writes
through the page cache happen on a writeback fid that's opened with
fixed (no O_APPEND) flags?...)


> diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
> index 612a230bc012..ff95dfb30583 100644
> --- a/fs/9p/vfs_file.c
> +++ b/fs/9p/vfs_file.c
> @@ -43,14 +43,18 @@ int v9fs_file_open(struct inode *inode, struct file *file)
>  	struct v9fs_session_info *v9ses;
>  	struct p9_fid *fid;
>  	int omode;
> +	int o_append;
>  
>  	p9_debug(P9_DEBUG_VFS, "inode: %p file: %p\n", inode, file);
>  	v9ses = v9fs_inode2v9ses(inode);
> -	if (v9fs_proto_dotl(v9ses))
> +	if (v9fs_proto_dotl(v9ses)) {
>  		omode = v9fs_open_to_dotl_flags(file->f_flags);
> -	else
> +		o_append = P9_DOTL_APPEND;
> +	} else {
>  		omode = v9fs_uflags2omode(file->f_flags,
>  					v9fs_proto_dotu(v9ses));
> +		o_append = P9_OAPPEND;
> +	}
>  	fid = file->private_data;
>  	if (!fid) {
>  		fid = v9fs_fid_clone(file_dentry(file));
> @@ -61,6 +65,11 @@ int v9fs_file_open(struct inode *inode, struct file *file)
>  			int writeback_omode = (omode & ~P9_OWRITE) | P9_ORDWR;
>  
>  			p9_debug(P9_DEBUG_CACHE, "write-only file with writeback enabled, try opening O_RDWR\n");
> +			if (omode & o_append) {
> +				writeback_omode &= ~o_append;
> +				p9_debug(P9_DEBUG_CACHE, "removing append from open mode in writeback cache mode\n");
> +			}

I wouldn't bother with the debug message, just clear it like P9_OWRITE:
   int writebeack_omode = (omode & ~(P9_OWRITE|o_append)) | P9_ORDWR;

(same for other hunks)
-- 
Dominique Martinet | Asmadeus

  reply	other threads:[~2025-11-02 23:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02 20:24 [PATCH 0/1] fs/9p: Do not open remote file with APPEND mode when writeback cache is used Tingmao Wang
2025-11-02 20:24 ` [PATCH 1/1] " Tingmao Wang
2025-11-02 23:07   ` Dominique Martinet [this message]
2025-11-02 23:56     ` [PATCH v2] fs/9p: Don't " Tingmao Wang
2025-11-03  7:34       ` Dominique Martinet
2025-11-10 13:25         ` Christian Schoenebeck
2025-11-10 14:22       ` Christian Schoenebeck
2025-11-02 23:58     ` [PATCH 1/1] fs/9p: Do not " Tingmao Wang

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=aQfkMUncxteb9aPW@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=ericvh@kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=m@maowtm.org \
    --cc=v9fs@lists.linux.dev \
    /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.