summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2026-10-29 13:25:25 +0100
committerChristian Brauner <brauner@kernel.org>2026-10-29 13:25:25 +0100
commitd4a952a954c81f123cd32f2ebba0c6c9fdd41a05 (patch)
tree8b97e768a2f4990bf13f7c73e4c73c5b193d06ff /tools/lib/python/kdoc/python_version.py
parent0f4a9e682f7fa5becc3af7204606d9bf4780e425 (diff)
parenteb8ab8c23e71c6ae77dedc45de2a57a61558e5d5 (diff)
Merge patch series "iomap: fixes for short copies and integrity bio sizes"
Christian Brauner <brauner@kernel.org> says: Two iomap fixes that came out of Josef's AI bug scans. The first one is old. For a buffered write into a hole, an unwritten extent or past EOF __iomap_write_begin() marks the zeroed blocks uptodate before the copy from userspace. If the copy comes up short the uncopied part of the write stays behind in an uptodate block: ftruncate(fd, 4096); pwrite(fd, p, 3000, 100); /* 16 bytes at p, then PROT_NONE */ pread(fd, buf, 4096, 0); That returns 2984 bytes of whatever was in the page before. Willy reported this in 2024 and Zhang Yi posted a fix but it never got merged. I went with the same fix. Josef's version zeroed the partially written blocks completely and only marked those uptodate. That works too but it's a lot more code for the same result. Willy suggested back then to drop the uptodate marking from __iomap_write_begin() completely. I didn't do that. Blocks that were read from disk are valid and keeping them uptodate means a retried short copy doesn't have to read them again. The second one is from v7.1. When the filesystem handles the integrity metadata the bio size check wraps if a single chunk is larger than max_integrity_io_size(). That limit is capped by the maximum segment size, so it's 64 KiB on lpfc and qla2xxx, and XFS writeback of a large preallocated file happily builds a single 300 MiB bio and overruns the 2 MiB integrity buffer. Note that a single chunk above the limit still gets a bio of its own. That's fine with 4k pages. But with 64k pages a folio can be 128 MiB which needs 4 MiB of PI with 16 bytes of metadata per 512 byte interval. That's not new though and needs a separate fix. Both are tested in a VM. Without the first patch the short copy reproducer leaks on XFS with 4k and 1k blocks and on ext4 with buffered iomap, and an fsx-like checker with faulting user buffers fails within a few hundred operations. With it both pass. The second patch was tested with scsi_debug DIF/DIX patched to a 64 KiB maximum segment size. * patches from https://patch.msgid.link/20261029-work-iomap-ai-fixes-v1-0-7eda63bc1b13@kernel.org: iomap: keep large chunks from defeating the bio cap iomap: don't mark unwritten parts of a folio uptodate Link: https://patch.msgid.link/20261029-work-iomap-ai-fixes-v1-0-7eda63bc1b13@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions