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. 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
