Re: [PATCH -next v5 05/32] ext4: set EXT4_MAP_NEW flag for delayed allocated blocks

On 8/14/2026 6:08 PM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The newly introduced EXT4_MAP_NEW flag is completely ignored by its only caller, rendering the patch ineffective (dead code) and failing to resolve the underlying bug.
> --
> 
> --- Patch [5]: [PATCH -next v5 05/32] ext4: set EXT4_MAP_NEW flag for delayed allocated blocks ---
> commit f71e7357d8a5fa9c83f4d4fc004cfa3640d60291
> Author: Zhang Yi <[email protected]>
> 
> ext4: set EXT4_MAP_NEW flag for delayed allocated blocks
> 
> This commit sets the EXT4_MAP_NEW flag in ext4_da_map_blocks() to indicate
> when a new delayed allocation block has been inserted. This aims to allow
> callers to distinguish newly created delayed extents from existing ones.
> 
> Link: https://lore.kernel.org/linux-ext4/[email protected]/
> 
>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>> index 7601fe3618b1f..9dbece14ae569 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
>> @@ -1990,7 +1990,7 @@ static int ext4_da_map_blocks(struct inode *inode, struct ext4_map_blocks *map)
>>   		}
>>   	}
>>   
>> -	map->m_flags |= EXT4_MAP_DELAYED;
>> +	map->m_flags |= EXT4_MAP_DELAYED | EXT4_MAP_NEW;
> 
> [Severity: High]
> Does this code actually allow callers to use the newly added flag?
> 
> Looking at ext4_da_get_block_prep(), which calls ext4_da_map_blocks(),
> it unconditionally intercepts EXT4_MAP_DELAYED, sets BH_New, and returns
> early without checking EXT4_MAP_NEW:
> 
> fs/ext4/inode.c:ext4_da_get_block_prep() {
>      ...
> 	if (map.m_flags & EXT4_MAP_DELAYED) {
> 		map_bh(bh, inode->i_sb, invalid_block);
> 		set_buffer_new(bh);
> 		set_buffer_delay(bh);
> 		return 0;
> 	}
>      ...
> }
> 
> Because EXT4_MAP_DELAYED is always set alongside EXT4_MAP_NEW, this branch is
> always taken, and set_buffer_new(bh) is unconditionally called. The code never
> seems to evaluate map.m_flags & EXT4_MAP_NEW.
> 
> Is it possible this patch is incomplete and the underlying issue remains
> unfixed because the new flag is ignored?
> 

The 15th patch ("ext4: implement buffered write path using iomap")
will use this flag, so it's fine. I'll add a note in the commit message
as well, just to keep Sashiko from complaining again.

Thanks,
Yi.

>>   	retval = ext4_insert_delayed_blocks(inode, map->m_lblk, map->m_len);
>>   	if (!retval)
>>   		map->m_seq = READ_ONCE(EXT4_I(inode)->i_es_seq);
>