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
| ||
|
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.
Powered by blists - more mailing lists