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.
>
> W
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 mar
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Tue, Jun 09, 2020 at 01:11:05PM -0400, Mikulas Patocka wrote:
> >
> > Do you have another idea how to solve this problem?
>
> I think the better approach would be to modify the drivers to not
> allocate any memory. In general, any memory needed by t
On Tue, Jun 09, 2020 at 01:11:05PM -0400, Mikulas Patocka wrote:
>
> Do you have another idea how to solve this problem?
I think the better approach would be to modify the drivers to not
allocate any memory. In general, any memory needed by the driver
to fulfil a request *should* be allocated wit
Hi
I've found out that a lot of hardware crypto drivers use GFP_ATOMIC. Some
of them switch between GFP_ATOMIC and GFP_KERNEL based on the flag
CRYPTO_TFM_REQ_MAY_SLEEP.
dm-crypt and dm-integrity don't use CRYPTO_TFM_REQ_MAY_SLEEP (because
GFP_KERNEL allocation requests can recurse back to the
