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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 13 Jan 2020 14:35:08 -0500 From: "Theodore Y. Ts'o" <tytso@....edu> To: Eric Biggers <ebiggers@...nel.org> Cc: linux-ext4@...r.kernel.org, linux-fscrypt@...r.kernel.org Subject: Re: [PATCH] ext4: re-enable extent zeroout optimization on encrypted files On Thu, Dec 26, 2019 at 10:11:14AM -0600, Eric Biggers wrote: > From: Eric Biggers <ebiggers@...gle.com> > > For encrypted files, commit 36086d43f657 ("ext4 crypto: fix bugs in > ext4_encrypted_zeroout()") disabled the optimization where when a write > occurs to the middle of an unwritten extent, the head and/or tail of the > extent (when they aren't too large) are zeroed out, turned into an > initialized extent, and merged with the part being written to. This > optimization helps prevent fragmentation of the extent tree. > > However, disabling this optimization also made fscrypt_zeroout_range() > nearly impossible to test, as now it's only reachable via the very rare > case in ext4_split_extent_at() where allocating a new extent tree block > fails due to ENOSPC. 'gce-xfstests -c ext4/encrypt -g auto' doesn't > even hit this at all. > > It's preferable to avoid really rare cases that are hard to test. > > That commit also cited data corruption in xfstest generic/127 as a > reason to disable the extent zeroout optimization, but that's no longer > reproducible anymore. It also cited fscrypt_zeroout_range() having poor > performance, but I've written a patch to fix that. > > Therefore, re-enable the extent zeroout optimization on encrypted files. > > Signed-off-by: Eric Biggers <ebiggers@...gle.com> Thanks, applied. - Ted
Powered by blists - more mailing lists