summaryrefslogtreecommitdiff
path: root/tools/lib/python
diff options
context:
space:
mode:
authorJoanne Koong <joannelkoong@gmail.com>2026-09-03 21:56:51 -0700
committerMiklos Szeredi <mszeredi@redhat.com>2026-09-25 12:36:30 +0200
commitd0a079b5b94bf5e10f1c00bd092eda0333782037 (patch)
treef2d6de9f8fc6f8f0e0797b95b0df27318f2e6ee5 /tools/lib/python
parent4c72635f913850512d5fa74bf3eb7db3670398cf (diff)
fuse: zero the correct range on a short read reply
When a read reply is shorter than the requested range, fuse_copy_folio() zeroes everything in the folio outside the copied bytes. However, for folios with block sizes smaller than the folio size, this can clear blocks outside the requested range which are uptodate, or dirty and have not yet been written back. Move the zeroing logic into fuse_copy_folios(), since descs[i].length needs to be used, and clear only the tail of the requested range that the server did not send. The range is also no longer cleared upfront in the non cs->skip_folio_copy case. This is fine since a failed copy leaves those blocks non-uptodate, so the uncopied bytes are never visible. This also matches the pre-existing behavior in the non-short-read case (a failed copy doesn't zero out the range in the folio). This lets the zeroing logic stay the same regardless of whether the folio copy is skipped or not. Fixes: a4c9ab1d4975 ("fuse: use iomap for buffered writes") Reported-by: Sashiko <sashiko-bot@kernel.org> Reported-by: Kanishka De Silva <kpskanna1915@gmail.com> Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions