1. Patchew
  2. linux
  3. View series

[PATCH] ceph: revalidate ki_pos for O_APPEND writes after cap acquisition

Xiubo Li via B4 Relay posted 1 patch 1 week ago
There is a newer version of this series
fs/ceph/file.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
[PATCH] ceph: revalidate ki_pos for O_APPEND writes after cap acquisition
Posted by Xiubo Li via B4 Relay 1 week ago 
From: Xiubo Li <xiubo.li@clyso.com>

For O_APPEND writes, ki_pos is set to the current EOF via
generic_write_checks() after fetching i_size from the MDS.  However,
ceph_get_caps() may need to wait for Fwx exclusive caps if the write
extends the file (endoff > i_max_size).  While waiting for Fwx, the
previous Fwx holder (another client) may have already extended the
file.  When the MDS grants us Fwx, the cap grant message updates the
local i_size, but ki_pos remains at the old EOF, causing the append
write to land at a stale offset and overwrite data from the other
client.

Fix by re-reading i_size_read(inode) after ceph_get_caps() returns.
At this point we hold Fwx exclusive caps, no other client can modify
the file, and i_size reflects the true EOF from the MDS cap grant.
No extra MDS round-trip is needed.  Only adjust ki_pos when the EOF
has actually changed.

Link: https://tracker.ceph.com/issues/7333
Signed-off-by: Xiubo Li <xiubo.li@clyso.com>
---
For O_APPEND writes, ki_pos is set to EOF via generic_write_checks()
after fetching i_size from the MDS via ceph_do_getattr().  However,
ceph_get_caps() may wait for Fwx exclusive caps (because endoff >
i_max_size).  During that wait, the previous Fwx holder may have
already extended the file.  When the MDS grants us Fwx, the local
i_size is updated via the cap grant message, but ki_pos is still
the old EOF, resulting in the append write overwriting data.

Fix by revalidating ki_pos against i_size_read(inode) after
ceph_get_caps() returns.  We now hold Fwx — no other client can
change the file, so i_size is stable and correct.

Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel if O_APPEND is specified")
Link: https://tracker.ceph.com/issues/7333
---
 fs/ceph/file.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 9d89d7fc1095..b35c9aee48dd 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -2491,6 +2491,32 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
 	if (err < 0)
 		goto out;
 
+	/*
+	 * For O_APPEND writes we may have waited for Fwx exclusive caps
+	 * while the previous Fwx holder (another client) extended the
+	 * file.  i_size has been updated via the cap grant message from
+	 * the MDS, but ki_pos is still the old EOF.  Re-read i_size here
+	 * (no extra MDS round-trip needed) and adjust ki_pos to the true
+	 * EOF.  Since we hold Fwx, no other client can change the file.
+	 */
+	if (iocb->ki_flags & IOCB_APPEND) {
+		loff_t cur_eof = i_size_read(inode);
+
+		if (cur_eof != pos) {
+			doutc(cl,
+			      "%p %llx.%llx O_APPEND: pos adjusted %lld -> %lld\n",
+			      inode, ceph_vinop(inode), pos, cur_eof);
+			iocb->ki_pos = cur_eof;
+			pos = cur_eof;
+			if (pos >= limit) {
+				err = -EFBIG;
+				goto out_caps;
+			}
+			iov_iter_truncate(from, limit - pos);
+			count = iov_iter_count(from);
+		}
+	}
+
 	err = file_update_time(file);
 	if (err)
 		goto out_caps;

---
base-commit: df47791ab9f12cd9144aca477ddae195f68072a5
change-id: 20260717-ceph-append-fix-9820e3b1a78c

Best regards,
--  
Xiubo Li <xiubo.li@clyso.com>
Re: [PATCH] ceph: revalidate ki_pos for O_APPEND writes after cap acquisition
Posted by Viacheslav Dubeyko 1 week ago 
On Fri, 2026-07-17 at 17:33 +0800, Xiubo Li via B4 Relay wrote:
> From: Xiubo Li <xiubo.li@clyso.com>
> 
> For O_APPEND writes, ki_pos is set to the current EOF via
> generic_write_checks() after fetching i_size from the MDS.  However,
> ceph_get_caps() may need to wait for Fwx exclusive caps if the write
> extends the file (endoff > i_max_size).  While waiting for Fwx, the
> previous Fwx holder (another client) may have already extended the
> file.  When the MDS grants us Fwx, the cap grant message updates the
> local i_size, but ki_pos remains at the old EOF, causing the append
> write to land at a stale offset and overwrite data from the other
> client.
> 
> Fix by re-reading i_size_read(inode) after ceph_get_caps() returns.
> At this point we hold Fwx exclusive caps, no other client can modify
> the file, and i_size reflects the true EOF from the MDS cap grant.
> No extra MDS round-trip is needed.  Only adjust ki_pos when the EOF
> has actually changed.
> 
> Link: https://tracker.ceph.com/issues/7333
> Signed-off-by: Xiubo Li <xiubo.li@clyso.com>
> ---
> For O_APPEND writes, ki_pos is set to EOF via generic_write_checks()
> after fetching i_size from the MDS via ceph_do_getattr().  However,
> ceph_get_caps() may wait for Fwx exclusive caps (because endoff >
> i_max_size).  During that wait, the previous Fwx holder may have
> already extended the file.  When the MDS grants us Fwx, the local
> i_size is updated via the cap grant message, but ki_pos is still
> the old EOF, resulting in the append write overwriting data.
> 
> Fix by revalidating ki_pos against i_size_read(inode) after
> ceph_get_caps() returns.  We now hold Fwx — no other client can
> change the file, so i_size is stable and correct.
> 
> Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel
> if O_APPEND is specified")
> Link: https://tracker.ceph.com/issues/7333

The patch has two --- separators. The Fixes and Link will be finally
dropped.

> ---
>  fs/ceph/file.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 9d89d7fc1095..b35c9aee48dd 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -2491,6 +2491,32 @@ static ssize_t ceph_write_iter(struct kiocb
> *iocb, struct iov_iter *from)
>  	if (err < 0)
>  		goto out;

ceph_get_caps() validated caps against the old endoff = pos + count.
After adjusting pos forward, the real write range is [cur_eof, cur_eof
+ count), which isn't re-validated against i_max_size. Could it be a
potential issue?

Thanks,
Slava.

>  
> +	/*
> +	 * For O_APPEND writes we may have waited for Fwx exclusive
> caps
> +	 * while the previous Fwx holder (another client) extended
> the
> +	 * file.  i_size has been updated via the cap grant message
> from
> +	 * the MDS, but ki_pos is still the old EOF.  Re-read i_size
> here
> +	 * (no extra MDS round-trip needed) and adjust ki_pos to the
> true
> +	 * EOF.  Since we hold Fwx, no other client can change the
> file.
> +	 */
> +	if (iocb->ki_flags & IOCB_APPEND) {
> +		loff_t cur_eof = i_size_read(inode);
> +
> +		if (cur_eof != pos) {
> +			doutc(cl,
> +			      "%p %llx.%llx O_APPEND: pos adjusted
> %lld -> %lld\n",
> +			      inode, ceph_vinop(inode), pos,
> cur_eof);
> +			iocb->ki_pos = cur_eof;
> +			pos = cur_eof;
> +			if (pos >= limit) {
> +				err = -EFBIG;
> +				goto out_caps;
> +			}
> +			iov_iter_truncate(from, limit - pos);
> +			count = iov_iter_count(from);
> +		}
> +	}
> +
>  	err = file_update_time(file);
>  	if (err)
>  		goto out_caps;
> 
> ---
> base-commit: df47791ab9f12cd9144aca477ddae195f68072a5
> change-id: 20260717-ceph-append-fix-9820e3b1a78c
> 
> Best regards,
> --  
> Xiubo Li <xiubo.li@clyso.com>
>
Re: [PATCH] ceph: revalidate ki_pos for O_APPEND writes after cap acquisition
Posted by Xiubo Li 1 week ago 
Hi Slava,

On Sat, 18 Jul 2026 at 01:35, Viacheslav Dubeyko <slava@dubeyko.com> wrote:
>
> On Fri, 2026-07-17 at 17:33 +0800, Xiubo Li via B4 Relay wrote:
> > From: Xiubo Li <xiubo.li@clyso.com>
> >
> > For O_APPEND writes, ki_pos is set to the current EOF via
> > generic_write_checks() after fetching i_size from the MDS.  However,
> > ceph_get_caps() may need to wait for Fwx exclusive caps if the write
> > extends the file (endoff > i_max_size).  While waiting for Fwx, the
> > previous Fwx holder (another client) may have already extended the
> > file.  When the MDS grants us Fwx, the cap grant message updates the
> > local i_size, but ki_pos remains at the old EOF, causing the append
> > write to land at a stale offset and overwrite data from the other
> > client.
> >
> > Fix by re-reading i_size_read(inode) after ceph_get_caps() returns.
> > At this point we hold Fwx exclusive caps, no other client can modify
> > the file, and i_size reflects the true EOF from the MDS cap grant.
> > No extra MDS round-trip is needed.  Only adjust ki_pos when the EOF
> > has actually changed.
> >
> > Link: https://tracker.ceph.com/issues/7333
> > Signed-off-by: Xiubo Li <xiubo.li@clyso.com>
> > ---
> > For O_APPEND writes, ki_pos is set to EOF via generic_write_checks()
> > after fetching i_size from the MDS via ceph_do_getattr().  However,
> > ceph_get_caps() may wait for Fwx exclusive caps (because endoff >
> > i_max_size).  During that wait, the previous Fwx holder may have
> > already extended the file.  When the MDS grants us Fwx, the local
> > i_size is updated via the cap grant message, but ki_pos is still
> > the old EOF, resulting in the append write overwriting data.
> >
> > Fix by revalidating ki_pos against i_size_read(inode) after
> > ceph_get_caps() returns.  We now hold Fwx — no other client can
> > change the file, so i_size is stable and correct.
> >
> > Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel
> > if O_APPEND is specified")
> > Link: https://tracker.ceph.com/issues/7333
>
> The patch has two --- separators. The Fixes and Link will be finally
> dropped.
>

I used the B4 and just added this to the cover letter. Let me fix it.

> > ---
> >  fs/ceph/file.c | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> > index 9d89d7fc1095..b35c9aee48dd 100644
> > --- a/fs/ceph/file.c
> > +++ b/fs/ceph/file.c
> > @@ -2491,6 +2491,32 @@ static ssize_t ceph_write_iter(struct kiocb
> > *iocb, struct iov_iter *from)
> >       if (err < 0)
> >               goto out;
>
> ceph_get_caps() validated caps against the old endoff = pos + count.
> After adjusting pos forward, the real write range is [cur_eof, cur_eof
> + count), which isn't re-validated against i_max_size. Could it be a
> potential issue?
>

Yeah, Good catch. We should fix this anyway. Let me fix it.

Thanks
Xiubo

> Thanks,
> Slava.
[......]

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.