Skip to content

Commit c6bfd72

Browse files
OjaswinMtytso
authored andcommitted
ext4: clarify handling of unwritten bh in __ext4_block_zero_page_range()
As an optimization, I was trying to work on exiting early from this function if dealing with unwritten extent since they anyways read 0. However, it was realised that there are certain code paths that can end up calling ext4_block_zero_page_range() for an unwritten bh that might still have data in pagecache. In this case, we can't exit early and we do require to process the bh and zero out the pagecache to ensure that a writeback can't kick in at a later time and flush the stale pagecache to disk. Since, adding the logic to exit early for unwritten bh was turning out to be much more nuanced and the current code already handles it well, just add a comment to explicitly document this behavior. Suggested-by: Jan Kara <[email protected]> Signed-off-by: Ojaswin Mujoo <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/d859b7ae5fe42e6626479b91ed9f4da3aae4c597.1698856309.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]>
1 parent 9257336 commit c6bfd72

File tree

1 file changed

+6
-0
lines changed

1 file changed

+6
-0
lines changed

fs/ext4/inode.c

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3630,6 +3630,12 @@ void ext4_set_aops(struct inode *inode)
36303630
inode->i_mapping->a_ops = &ext4_aops;
36313631
}
36323632

3633+
/*
3634+
* Here we can't skip an unwritten buffer even though it usually reads zero
3635+
* because it might have data in pagecache (eg, if called from ext4_zero_range,
3636+
* ext4_punch_hole, etc) which needs to be properly zeroed out. Otherwise a
3637+
* racing writeback can come later and flush the stale pagecache to disk.
3638+
*/
36333639
static int __ext4_block_zero_page_range(handle_t *handle,
36343640
struct address_space *mapping, loff_t from, loff_t length)
36353641
{

0 commit comments

Comments
 (0)