On Thu, Jul 10, 2025 at 10:28:55AM +0200, Milan Broz wrote: > On 7/9/25 9:09 PM, Eric Biggers wrote: > > The support for asynchronous hashes in dm-verity has outlived its > > usefulness. It adds significant code complexity and opportunity for > > bugs. I don't know of anyone using it in practice. (The original > > submitter of the code possibly was, but that was 8 years ago.) Data I > > recently collected for en/decryption shows that using off-CPU crypto > > "accelerators" is consistently much slower than the CPU > > (https://lore.kernel.org/r/20250704070322.20692-1-ebigg...@kernel.org/), > > even on CPUs that lack dedicated cryptographic instructions. Similar > > results are likely to be seen for hashing. > > > > I already removed support for asynchronous hashes from fsverity two > > years ago, and no one ever complained. > > > > Moreover, neither dm-verity, fsverity, nor fscrypt has ever actually > > used the asynchronous crypto algorithms in a truly asynchronous manner. > > The lack of interest in such optimizations provides further evidence > > that it's only the CPU-based crypto that actually matters. > > > > Historically, it's also been common for people to forget to enable the > > optimized SHA-256 code, which could contribute to an off-CPU crypto > > engine being perceived as more useful than it really is. In 6.16 I > > fixed that: the optimized SHA-256 code is now enabled by default. > > > > Therefore, let's drop the support for asynchronous hashes in dm-verity. > > > > Tested with verity-compat-test. > > Hi, > > I shortly tested it with veritysetup too, also on 32bit. > And I like this patch (I wish we can remove the async thing from the dmcrypt > too...)
IMO we should do it for dm-crypt too, though it's going to be a slightly tougher sell there because it actually goes through the trouble of using the async API "properly". - Eric
