linux-ext4 - Re: [PATCH v2 07/13] ext4: drop extent cache before splitting extent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b42dd2b9-f04e-4c0c-9fb1-5a46fb450e5e@huaweicloud.com>
Date: Sat, 29 Nov 2025 09:36:08 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Cc: linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, tytso@....edu, adilger.kernel@...ger.ca,
 jack@...e.cz, yi.zhang@...wei.com, yizhang089@...il.com,
 libaokun1@...wei.com, yangerkun@...wei.com
Subject: Re: [PATCH v2 07/13] ext4: drop extent cache before splitting extent

On 11/28/2025 4:16 PM, Ojaswin Mujoo wrote:
> On Thu, Nov 27, 2025 at 03:27:26PM +0800, Zhang Yi wrote:
>> On 11/26/2025 8:24 PM, Ojaswin Mujoo wrote:
>>> On Fri, Nov 21, 2025 at 02:08:05PM +0800, Zhang Yi wrote:
>>>> From: Zhang Yi <yi.zhang@...wei.com>
>>>>
[...]
>>>>
>>>> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
>>>> index 2b5aec3f8882..9bb80af4b5cf 100644
>>>> --- a/fs/ext4/extents.c
>>>> +++ b/fs/ext4/extents.c
>>>> @@ -3367,6 +3367,12 @@ static struct ext4_ext_path *ext4_split_extent(handle_t *handle,
>>>>  	ee_len = ext4_ext_get_actual_len(ex);
>>>>  	unwritten = ext4_ext_is_unwritten(ex);
>>>>  
>>>> +	/*
>>>> +	 * Drop extent cache to prevent stale unwritten extents remaining
>>>> +	 * after zeroing out.
>>>> +	 */
>>>> +	ext4_es_remove_extent(inode, ee_block, ee_len);
>>>> +
> 
> Okay this makes sense, there are many different combinations of how the
> on disk extents might turn out and if will become complicated to keep
> the es in sync to those, so this seems simpler.
> 
> There might be a small performance penalty of dropping the es here tho
> but idk if it's anything measurable. As a middle ground do you think it
> makes more sense to drop the es cache in ext4_split_extent_at() instead,
> when we know we are about to go for zeroout. Since the default non
> zeroout path seems to be okay?
> 
> Regards,
> ojaswin
> 
> 

Yes, this makes sense to me! I will move it to ext4_split_extent_at()
in my next iteration.

Thanks,
Yi.

> 
>>>>  	/* Do not cache extents that are in the process of being modified. */
>>>>  	flags |= EXT4_EX_NOCACHE;
>>>>  
>>>> -- 
>>>> 2.46.1
>>>>
>>