[REGRESSION] dm_crypt essiv ciphers do not use async driver mv-aes-cbc anymore
Mikulas Patocka
mpatocka at redhat.com
Wed Nov 1 12:47:18 UTC 2023
On Wed, 1 Nov 2023, Linux regression tracking (Thorsten Leemhuis) wrote:
> > #regzbot introduced: b8aa7dc5c753
>
> BTW: Eric, thx for this.
>
> Boris, Arnaud, Srujana, and Mikulas, could you maybe comment on this? I
> understand that this is not some everyday regression due to deadlock
> risk, but it nevertheless would be good to get this resolved somehow to
> stay in line with our "no regressions" rule.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
Hi
The driver drivers/crypto/marvell/cesa/cipher.c uses GFP_ATOMIC
allocations (see mv_cesa_skcipher_dma_req_init). So, it is not really safe
to use it for dm-crypt.
GFP_ATOMIC allocations may fail anytime (for example, they fill fail if
the machine receives too many network packets in a short timeframe and
runs temporarily out of memory). And when the GFP_ATOMIC allocation fails,
you get a write I/O error and data corruption.
It could be possible to change it to use GFP_NOIO allocations, then we
would risk deadlock instead of data corruption. The best thing would be to
convert the driver to use mempools.
Mikulas
More information about the dm-devel
mailing list