[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2006161052540.28052@file01.intranet.prod.int.rdu2.redhat.com>
Date: Tue, 16 Jun 2020 11:01:00 -0400 (EDT)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
cc: "David S. Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org, Mike Snitzer <msnitzer@...hat.com>,
Milan Broz <mbroz@...hat.com>, dm-devel@...hat.com,
linux-kernel@...r.kernel.org
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
Powered by blists - more mailing lists