Re: [REGRESSION] dm_crypt essiv ciphers do not use async driver mv-aes-cbc anymore

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux