| Message ID | 1589926645-32686-1-git-send-email-iuliana.prodan@nxp.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: engine - do not requeue in case of fatal error | expand |
On 5/20/2020 1:17 AM, Iuliana Prodan wrote: > Now, in crypto-engine, if hardware queue is full (-ENOSPC), > requeue request regardless of MAY_BACKLOG flag. > If hardware throws any other error code (like -EIO, -EINVAL, > -ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into > crypto-engine's queue, since the others can be dropped. > The latter case can be fatal error, so those cannot be recovered from. > For example, in CAAM driver, -EIO is returned in case the job descriptor > is broken, so there is no possibility to fix the job descriptor. > Therefore, these errors might be fatal error, so we shouldn’t > requeue the request. This will just be pass back and forth between > crypto-engine and hardware. > > Fixes: 6a89f492f8e5 ("crypto: engine - support for parallel requests based on retry mechanism") > Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reported-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Thanks, Horia
On Wed, May 20, 2020 at 01:17:25AM +0300, Iuliana Prodan wrote: > Now, in crypto-engine, if hardware queue is full (-ENOSPC), > requeue request regardless of MAY_BACKLOG flag. > If hardware throws any other error code (like -EIO, -EINVAL, > -ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into > crypto-engine's queue, since the others can be dropped. > The latter case can be fatal error, so those cannot be recovered from. > For example, in CAAM driver, -EIO is returned in case the job descriptor > is broken, so there is no possibility to fix the job descriptor. > Therefore, these errors might be fatal error, so we shouldn’t > requeue the request. This will just be pass back and forth between > crypto-engine and hardware. > > Fixes: 6a89f492f8e5 ("crypto: engine - support for parallel requests based on retry mechanism") > Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> > --- > crypto/crypto_engine.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) Patch applied. Thanks.
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c index 412149e..3655d9d 100644 --- a/crypto/crypto_engine.c +++ b/crypto/crypto_engine.c @@ -169,13 +169,10 @@ static void crypto_pump_requests(struct crypto_engine *engine, /* * If hardware queue is full (-ENOSPC), requeue request * regardless of backlog flag. - * If hardware throws any other error code, - * requeue only backlog requests. * Otherwise, unprepare and complete the request. */ if (!engine->retry_support || - ((ret != -ENOSPC) && - !(async_req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG))) { + (ret != -ENOSPC)) { dev_err(engine->dev, "Failed to do one request from queue: %d\n", ret);
Now, in crypto-engine, if hardware queue is full (-ENOSPC), requeue request regardless of MAY_BACKLOG flag. If hardware throws any other error code (like -EIO, -EINVAL, -ENOMEM, etc.) only MAY_BACKLOG requests are enqueued back into crypto-engine's queue, since the others can be dropped. The latter case can be fatal error, so those cannot be recovered from. For example, in CAAM driver, -EIO is returned in case the job descriptor is broken, so there is no possibility to fix the job descriptor. Therefore, these errors might be fatal error, so we shouldn’t requeue the request. This will just be pass back and forth between crypto-engine and hardware. Fixes: 6a89f492f8e5 ("crypto: engine - support for parallel requests based on retry mechanism") Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> --- crypto/crypto_engine.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)