On 01.11.23 13:47, Mikulas Patocka wrote: > 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. >> > > 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. Thx, now I understand things better. I also had a small hope that my prodding here might motivate someone to look into this, but that didn't happen. Well, that's how it is. I'm not totally sure if this regression was handled like Linus would have want it to be handled. But I guess it's not worth bringing him in -- among others because it took so long for somebody to complain. I'll thus strop tracking this now. #regzbot resolve: tricky situation that remains unresolved for now Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
