On Tue, 23 Sep 2025, Herbert Xu wrote:
> If authenc gets EBUSY from the ahash, then the ahash is responsible
> for sending an EINPROGRESS notification. I just checked the authenc
> code and it does pass the notification back up to the caller (which
> is dm-crypt).
>
> So if EINPROGRESS is not being received, then it's a bug in the
> ahash layer or the underlying ahash algorithm.
static void authenc_request_complete(struct aead_request *req, int err)
{
if (err != -EINPROGRESS)
aead_request_complete(req, err);
}
This prevents -EINPROGRESS from reaching dm-crypt. If I remove the
condition "err != -EINPROGRESS", the deadlock goes away. Though, removing
it may break other things - we may send -EINPROGRESS twice, first for the
hash and then for the decryption.
> Which phmac implementation was this?
It was pseudo_phmac out-of-tree module sent by Harald Freudenberger. He
CC'd you, so you should have it as an attachment in your inbox.
The following scripts creates the buggy device mapper device:
#!/bin/sh -ex
sync
modprobe crypto_engine
insmod ~/c/phmac/pseudo_phmac/phmac.ko
modprobe brd rd_size=1048576
dmsetup create cr_dif --table '0 2031880 integrity 1:0 32768 32 J 7
block_size:4096 interleave_sectors:32768 buffer_sectors:128
journal_sectors:16368 journal_watermark:50 commit_time:10000 fix_padding'
dmsetup create cr --table '0 2031880 crypt
capi:authenc(phmac(sha256),xts(aes))-plain64
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0 252:0 0 2 integrity:32:aead sector_size:4096'
dd if=/dev/zero of=/dev/mapper/cr bs=1M oflag=direct status=progress
> Cheers,
Mikulas
