summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorHao-Qun Huang <alvinhuang0603@gmail.com>2026-07-08 14:54:39 +0800
committerJaegeuk Kim <jaegeuk@kernel.org>2026-08-04 00:18:36 +0000
commit28c1ef094e7c86977d9bf570dc0362fc54e36437 (patch)
treed79165bfffa63e92be64880f10c19bfc49f93d10 /tools/perf/scripts/python/stackcollapse.py
parentf8a4108800254d6f7b2755515fbbd9d0caac561e (diff)
f2fs: reject overlapping move range after len expansion
F2FS_IOC_MOVE_RANGE treats a zero length as a request to move data from pos_in to EOF. However, the same-file overlap check runs before that expansion, so a request with len == 0 bypasses the overlap rejection added for same-file moves. For example, with a four-block file, moving from block 0 to block 1 with len == 0 is accepted by the old check because pos_in + len is still pos_in at that point. The code then expands len to cover the rest of the file and calls __exchange_data_block() on overlapping source and destination ranges in the same inode, which is the data-corruption case the overlap check was meant to reject. Move the overlap check after the source range has been validated and len == 0 has been expanded, so it sees the effective length. This is a no-op for non-zero len (the value is unchanged there) and keeps the existing early return for identical positions. Fixes: d95fd91c1ac1 ("f2fs: exclude special cases for f2fs_move_file_range") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Hao-Qun Huang <alvinhuang0603@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions