Messages in this thread | | | Date | Tue, 16 Jun 2020 11:01:00 -0400 (EDT) | From | Mikulas Patocka <> | Subject | Re: crypto API and GFP_ATOMIC |
| |
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 10, 2020 at 08:02:23AM -0400, Mikulas Patocka wrote: > > > > Yes, fixing the drivers would be the best - but you can hardly find any > > person who has all the crypto hardware and who is willing to rewrite all > > the drivers for it. > > We don't have to rewrite them straight away. We could mark the > known broken ones (or the known working ones) and then dm-crypt > can allocate only those using the types/mask to crypto_alloc. > > Cheers,
I triaged the drivers in drivers/crypto and unfortunatelly, most of them do memory allocation in the encryption routine. Some of the do GFP_KERNEL allocation even in the absence of CRYPTO_TFM_REQ_MAY_SLEEP.
I'm sending the patches:
The first patch adds a new flag CRYPTO_ALG_ALLOCATES_MEMORY.
The second patch passes CRYPTO_ALG_ALLOCATES_MEMORY through the crypto API stack (please check it - I am not an expert in this area).
The third patch sets CRYPTO_ALG_ALLOCATES_MEMORY on drivers that allocate memory in the encrypt/decrypt routine.
The fourth patch fixes the drivers that use GFP_KERNEL in non-blocking context.
Mikulas
| |