linux-kernel - Re: [PATCH 05/27] ext4: refactor ext4_zero

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: <0b45ce3d-fd20-4df2-9c04-f956b96bf6a2@huaweicloud.com>
Date: Fri, 6 Dec 2024 16:09:26 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: Jan Kara <jack@...e.cz>
Cc: linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, tytso@....edu, adilger.kernel@...ger.ca,
 ritesh.list@...il.com, hch@...radead.org, djwong@...nel.org,
 david@...morbit.com, zokeefe@...gle.com, yi.zhang@...wei.com,
 chengzhihao1@...wei.com, yukuai3@...wei.com, yangerkun@...wei.com
Subject: Re: [PATCH 05/27] ext4: refactor ext4_zero_range()

On 2024/12/4 19:52, Jan Kara wrote:
> On Tue 22-10-24 19:10:36, Zhang Yi wrote:
>> From: Zhang Yi <yi.zhang@...wei.com>
>>
>> The current implementation of ext4_zero_range() contains complex
>> position calculations and stale error tags. To improve the code's
>> clarity and maintainability, it is essential to clean up the code and
>> improve its readability, this can be achieved by: a) simplifying and
>> renaming variables, making the style the same as ext4_punch_hole(); b)
>> eliminating unnecessary position calculations, writing back all data in
>> data=journal mode, and drop page cache from the original offset to the
>> end, rather than using aligned blocks; c) renaming the stale out_mutex
>> tags.
>>
>> Signed-off-by: Zhang Yi <yi.zhang@...wei.com>
> 
> ...
> 
>> -		goto out_mutex;
>> -
>> -	/* Preallocate the range including the unaligned edges */
>> -	if (partial_begin || partial_end) {
>> -		ret = ext4_alloc_file_blocks(file,
>> -				round_down(offset, 1 << blkbits) >> blkbits,
>> -				(round_up((offset + len), 1 << blkbits) -
>> -				 round_down(offset, 1 << blkbits)) >> blkbits,
>> -				new_size, flags);
>> -		if (ret)
>> -			goto out_mutex;
>> -
>> -	}
> 
> So I think we should keep this first ext4_alloc_file_blocks() call before
> we truncate the page cache. Otherwise if ext4_alloc_file_blocks() fails due
> to ENOSPC, we have already lost the dirty data originally in the zeroed
> range. All the other failure modes are kind of catastrophic anyway, so they
> are fine after dropping the page cache. But this is can be quite common and
> should be handled more gracefully.
> 

Ha, right, I missed this error case, I will revise it.

Thanks,
Yi.