kernel/git/stable/linux.git/fs/ext4, branch linux-7.1.y

ext4: zero out whole block for clean edges in WRITE_ZEROES

2026-09-02T12:32:35+00:00

[ Upstream commit a5179156ac1d9a6646da42254e4c461e1fc20096 ] FALLOC_FL_WRITE_ZEROES requires that all blocks in the requested range end up as written extents with zeroed content. For unaligned edges that were already allocated, ext4_zero_partial_blocks() zeros them directly. However, for unaligned edges whose underlying extent is a clean unwritten extent or a hole, the extent type remains unwritten after partial zeroing, which does not align with the semantics of WRITE_ZEROES. Therefore, when ext4_zero_partial_blocks() skips partial zeroing, it indicates that the corresponding edges are clean unwritten extents or holes. In this case, we need to expand the aligned allocation range outward to cover such edges, so that ext4_alloc_file_blocks() can correctly allocate blocks for the unaligned range. Edges that were partial-zeroed (i.e., written or dirty) are left untouched. Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-8-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: track partial-zero outcome per edge in ext4_zero_partial_blocks()

2026-09-02T12:32:35+00:00

[ Upstream commit 4c1f6931395ad026415cbdb924ffc240f86eb557 ] Replace the single bool did_zero output of ext4_zero_partial_blocks() with a bitmask that records which edge (start, end, or both in the single-block case) was actually partial-zeroed. This allows callers to distinguish which edges have been zeroed, preparing for unaligned FALLOC_FL_WRITE_ZEROES handling in later patches. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-7-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Stable-dep-of: a5179156ac1d ("ext4: zero out whole block for clean edges in WRITE_ZEROES") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: write back partial-zeroed edges in WRITE_ZEROES

2026-09-02T12:32:35+00:00

[ Upstream commit d19d239ada9b7c92d086a1f051b7566538ee0089 ] FALLOC_FL_WRITE_ZEROES requires that all blocks in the requested range end up as written extents with zeroed content. For unaligned edges that were partial-zeroed in dirty unwritten or delalloc state, the buffer is left dirty while the underlying extent may not yet be converted to written. As a result, a subsequent SYNC write to this range would still trigger metadata changes, which violates the semantics of WRITE_ZEROES. Fix this by calling filemap_write_and_wait_range() for partial-zeroed edges to flush out the zeroed data and ensure the extent conversion is complete. Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-9-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: move partial block zeroing earlier in ext4_zero_range()

2026-09-02T12:32:35+00:00

[ Upstream commit b16e9d27a643a3cf8907c994d25ed52717f36418 ] In ext4_zero_range(), move the ext4_zero_partial_blocks() call, which handles unaligned edges, into the same branch where the unaligned range is preallocated, immediately after ext4_alloc_file_blocks(). This is safe because there is no dependency between partial block handling and the subsequent full block handling. This change will be used by later patches that handle unaligned FALLOC_FL_WRITE_ZEROES operations, which will need to check the partial zeroed result. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260714080044.4038124-5-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Stable-dep-of: d19d239ada9b ("ext4: write back partial-zeroed edges in WRITE_ZEROES") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: protect WRITE_ZEROES written extents with orphan list

2026-09-02T12:32:35+00:00

[ Upstream commit f7237a775c8f3e99e0e77b7c10fb626815fb2877 ] In ext4_alloc_file_blocks(), the WRITE_ZEROES path converts unwritten extents to written in one transaction, while i_disksize is updated to cover them only in a later transaction. A crash in between leaves written extents beyond i_disksize on disk, which fsck will complain about. To fix this, add the inode to the orphan list in the same handle that does the conversion, and remove it once i_disksize has caught up. Also add a sanity check to ensure conversion does not extend beyond EOF. Since ext4_alloc_file_blocks() is called from the fallocate() path, partial allocation is safe. On partial conversion failure, advance i_disksize only up to the boundary of successfully converted blocks, so that orphan cleanup sees a consistent state. Document this behavior in the function comment. Reported-by: Jan Kara Closes: https://lore.kernel.org/linux-ext4/3f6ao5amv7glbgigndtegcucgo3n34ij3lau6l3da3hgdxgn3v@ev66wv3r5umt/ Fixes: f4265b8d32c4 ("ext4: add FALLOC_FL_WRITE_ZEROES support") Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260729085918.3336221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: export converted block count from ext4_convert_unwritten_extents()

2026-09-02T12:32:35+00:00

[ Upstream commit 5b3dcb924a38ecd2c0d828ff30c357357eda1da8 ] ext4_convert_unwritten_extents() currently returns only a success or a failure indication. A zero return means all requested blocks were converted, and a negative value means the conversion failed. However, some blocks may have already been converted when the function fails partway through, and callers have no way to learn how many were done. The WRITE_ZEROES caller in ext4_alloc_file_blocks() needs this information to decide whether to add the inode to the orphan list before updating i_disksize to cover the already-converted written extents, so that a crash before i_disksize catches up can be recovered via orphan truncation. Switch the function to pass out the number of converted blocks through the new output parameter @converted, which will be used by later patches. Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260729085918.3336221-2-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Stable-dep-of: f7237a775c8f ("ext4: protect WRITE_ZEROES written extents with orphan list") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ext4: fix incorrect function call when initializing s_resgid

2026-08-27T12:34:36+00:00

commit c87abbab6147dcc5aa1fd8f2a61734d58d8b99ec upstream. In __ext4_fill_super(), s_resgid is initialized by calling ext4_get_resuid() instead of ext4_get_resgid(), resulting in the reserved GID being set to the same value as the reserved UID rather than the value stored in the superblock. Fixes: 12c84dd4d308 ("ext4: add support for 32-bit default reserved uid and gid values") Cc: stable@vger.kernel.org Signed-off-by: Jiazi Liu Reviewed-by: Ritesh Harjani (IBM) Link: https://patch.msgid.link/20260727104103.28916-1-liujiazi@amazon.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman

ext4: don't enable DAX on new encrypted files

2026-08-27T12:34:36+00:00

commit da32af420d6d466e247c43ac0b829edeac7ae0ad upstream. Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with "-o dax=always". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when "-o dax=always" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too. Reported-by: Disha Goel Reported-by: Ojaswin Mujoo Closes: https://lore.kernel.org/r/20260723085648.1500357-1-ojaswin@linux.ibm.com Fixes: 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Tested-by: Disha Goel Reviewed-by: Ojaswin Mujoo Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260730175212.36923-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman

ext4: propagate errors from fast commit range replay

2026-08-27T12:34:36+00:00

commit d8b8dd3530bf41e14b118702cdaf9de64bb96885 upstream. ext4_fc_replay() stops replaying fast commit tags only when a tag handler returns a negative error. However, ext4_fc_replay_add_range() and ext4_fc_replay_del_range() currently return 0 from their common exit paths even after internal failures. This hides errors from ext4_fc_record_modified_inode(), ext4_map_blocks(), ext4_find_extent(), ext4_ext_insert_extent(), ext4_ext_replay_update_ex(), and ext4_ext_remove_space(). As a result, a failed ADD_RANGE or DEL_RANGE replay can be treated as successful and the replay code may continue with subsequent fast commit tags. This is particularly problematic for DEL_RANGE because it may already have marked blocks as free before ext4_ext_remove_space() fails. If the error is swallowed, replay may continue from a partially applied range operation. Return the saved error from the common exit paths and make the ERR_PTR() cases in ADD_RANGE store PTR_ERR() before jumping to out. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@vger.kernel.org Signed-off-by: Guanghui Yang <3497809730@qq.com> Reviewed-by: Jan Kara Link: https://patch.msgid.link/tencent_E3622146846A84C75C31C7D32AC4D5AD0605@qq.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman

ext4: avoid tail write_begin walk for uptodate folios

2026-08-27T12:34:36+00:00

commit d09811183db2891776dbf0c0f1094540e29938f6 upstream. Ext4 buffered writes into large folios also pay a full buffer_head walk in ext4_block_write_begin(). For a small overwrite of an existing cached folio, the folio is already uptodate and the write only needs to prepare the buffers through the written range. Walking the suffix still makes the write_begin cost proportional to the folio size. Before ext4 enabled large folios for regular files, the same loop was bounded by a single page of buffers. That commit made the existing full-folio walk visible as a regression for cached small overwrites. The suffix walk is needed for non-uptodate folios, where ext4 may have to submit reads for partial blocks, preserve new-buffer cleanup, and run error zeroing. Keep those folios on the old full walk. For already-uptodate folios, keep the walk starting at the first buffer rather than seeking directly to from. This preserves the existing prefix buffer state handling. Stop once block_start reaches the end of the write range, because the skipped suffix would only repeat the outside-range uptodate handling for buffers beyond @to. On current master, the libMicro ext4 large-folio overwrite test shows the following full-series result. Results are median usecs/call over 10 runs, lower is better: case nofix this series improvement write_u1k 1.418 0.3405 76.0% write_u10k 1.887 0.4175 77.9% pwrite_u1k 1.6775 0.3390 79.8% pwrite_u10k 1.9035 0.4130 78.3% Fixes: 7ac67301e82f0 ("ext4: enable large folio for regular file") Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jan Kara Signed-off-by: Jia Zhu Link: https://patch.msgid.link/20260609035202.90669-3-zhujia.zj@bytedance.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman