summaryrefslogtreecommitdiff
path: root/scripts/lib/kdoc/kdoc_re.py
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@kernel.org>2025-07-09 12:09:02 -0700
committerMikulas Patocka <mpatocka@redhat.com>2025-07-31 15:39:55 +0200
commitbdf253d580d7d30e7620844c63a5013fe7ba3f87 (patch)
treeb249a8be3f19e38b235a517b329f39e1c850bc3f /scripts/lib/kdoc/kdoc_re.py
parent6e11952a6abc4641dc8ae63f01b318b31b44e8db (diff)
dm-verity: remove support for asynchronous hashes
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-ebiggers@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. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_re.py')
0 files changed, 0 insertions, 0 deletions