diff options
| author | Xiubo Li <xiubo.li@clyso.com> | 2026-07-21 13:06:53 +0800 |
|---|---|---|
| committer | Ilya Dryomov <idryomov@gmail.com> | 2026-08-26 19:57:27 +0200 |
| commit | d2a8d446a09c74c8ddfe108b50dd791c889983fc (patch) | |
| tree | f4ef7d96246a8ac7cd455f3962fc506dd36b315c /tools/perf/scripts/python/stackcollapse.py | |
| parent | a354d7eaa1a57f1532c8072a424cc2d339a73cc0 (diff) | |
ceph: revalidate ki_pos for O_APPEND writes after cap acquisition
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.
After adjusting ki_pos forward, the write range [pos, pos+count) may
now exceed the i_max_size that was validated by ceph_get_caps() for
the old range. Re-check against i_max_size and truncate the write
if necessary to stay within the MDS-granted limit.
Link: https://tracker.ceph.com/issues/7333
Fixes: 8e4473bb50a1 ("ceph: do not execute direct write in parallel if O_APPEND is specified")
Signed-off-by: Xiubo Li <xiubo.li@clyso.com>
Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions
