From: Fengnan Chang changfengnan@bytedance.com
[ Upstream commit 88a80066af1617fab444776135d840467414beb6 ]
Like ftruncate and write, fallocate operations on the same file cannot be executed in parallel, so it is better to make fallocate be hashed work.
Signed-off-by: Fengnan Chang changfengnan@bytedance.com Link: https://lore.kernel.org/r/20250623110218.61490-1-changfengnan@bytedance.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should definitely be backported to stable kernel trees. Here's my extensive analysis:
## Why this is a critical bug fix:
1. **Data Integrity Issue**: The commit fixes a race condition where multiple fallocate operations on the same file could execute in parallel through io_uring. Looking at the implementation in io_uring/sync.c:107, fallocate calls `vfs_fallocate()` which modifies file allocation state. Without proper serialization, concurrent fallocate operations can cause: - Data corruption - Inconsistent file metadata - Filesystem-level race conditions in block allocation
2. **Consistency with Similar Operations**: By examining io_uring/opdef.c, I found that all other file-modifying operations already have `hash_reg_file = 1`: - IORING_OP_WRITEV - IORING_OP_WRITE_FIXED - IORING_OP_WRITE - IORING_OP_SPLICE - IORING_OP_TEE - IORING_OP_FTRUNCATE - IORING_OP_WRITEV_FIXED
3. **Clear Precedent**: When ftruncate support was added in commit b4bb1900c12e, it was correctly implemented with `hash_reg_file = 1` from the start. The fact that fallocate was missing this flag appears to be an oversight that this commit corrects.
## Why it's safe to backport:
1. **Minimal Change**: Single line addition with no architectural changes 2. **Well-Understood Fix**: The `hash_reg_file` mechanism is well- established and used by all similar operations 3. **No Breaking Changes**: The only effect is proper serialization of fallocate operations per-file, which is the correct and expected behavior 4. **Low Risk**: This change cannot introduce new bugs - it only prevents existing race conditions
## How it differs from the "NO" examples:
Unlike the provided similar commits which were: - Adding new features (io_uring fallocate support) - Performance optimizations (hashing changes, __read_mostly) - Code cleanup (removing unused fields, refactoring)
This commit fixes a **correctness bug** that can lead to data corruption in production systems using io_uring with fallocate operations.
The commit follows stable kernel rules perfectly: it's a critical bug fix that's minimal, contained, and addresses a real user-facing issue without introducing new functionality or risks.
io_uring/opdef.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/io_uring/opdef.c b/io_uring/opdef.c index 3b9c6489b8b6d..2d0a7db940fdb 100644 --- a/io_uring/opdef.c +++ b/io_uring/opdef.c @@ -202,6 +202,7 @@ const struct io_issue_def io_issue_defs[] = { }, [IORING_OP_FALLOCATE] = { .needs_file = 1, + .hash_reg_file = 1, .prep = io_fallocate_prep, .issue = io_fallocate, },