Re: [PATCH] crypto: caam: add backlogging support

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

 



> 

> ________________________________________
> From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, May 10, 2016 12:46 PM
> To: Catalin Vasile
> Cc: linux-crypto@xxxxxxxxxxxxxxx; linux-crypto-owner@xxxxxxxxxxxxxxx; Horia Ioan Geanta Neag; Alexandru Porosanu; Scott Wood; Catalin Vasile
> Subject: Re: [PATCH] crypto: caam: add backlogging support> 

> Catalin Vasile <cata.vasile@xxxxxxx> wrote:
> > caam_jr_enqueue() function returns -EBUSY once there are no more slots
> > available in the JR, but it doesn't actually save the current request.
> > This breaks the functionality of users that expect that even if there is
> > no more space for the request, it is at least queued for later
> > execution. In other words, all crypto transformations that request
> > backlogging (i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such
> > an example is dm-crypt. The current patch solves this issue by setting a
> > threshold after which caam_jr_enqueue() returns -EBUSY, but since the HW
> > job ring isn't actually full, the job is enqueued.
> >
> > Signed-off-by: Alexandru Porosanu <alexandru.porosanu@xxxxxxx>
> > Tested-by: Catalin Vasile <cata.vasile@xxxxxxx>> 

> This is not acceptable.  The request that triggers EBUSY must
> be allowed to queue.  As the number of tfms is unlimited you
> can't just put them onto the hardware queue and hope that it
> works out.>
Every request will be queued and eventually done.
The hardware equipment has a constraint on the number of tfms it can have.
Is there a requirement to support an infinite number of tfms on a device?

> You should use a software queue instead.> 

> Cheers,
> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

  Powered by Linux