[QUESTION] Crypto queue handling

[Marek Vasut <marex@denx.de>]

Hello,

I'm digging in crypto/algapi.c , in the crypto_enqueue_request() function. I 
don't quite understand how the backlog mechanism should work. According to [1], 
I suspect it should limit the amount of requests in the queue to $max_qlen and 
allow one more request to be enqueued into the $backlog ; and if there is more 
requests than $max_qlen, it should start dropping the requests ?

Inspecting the code, I see these situations:
1) qlen < max_qlen
   -> The request is enqueued, qlen is increased , returns -EINPROGRESS
2) qlen >= max_qlen
   -> The crypto_enqueue_request() returns -EBUSY in this case
   2a) request->flags has CRYPTO_TFM_REQ_MAY_BACKLOG unset
       => Request is not enqueued , qlen is not increased
   2b) request->flags has CRYPTO_TFM_REQ_MAY_BACKLOG set
       => Request is enqueued , qlen is increased

Therefore, I suspect if 2b) case happens repeatedly, the queue will grow 
indefinitelly. I'm not sure if this can happen, but I suspect that's really 
possible. My understanding is that the driver will call crypto_enqueue_request() 
and propagate it's return value to the upper layers. They upper layet can 
generate such a request that has CRYPTO_TFM_REQ_MAY_BACKLOG set .

But how shall the upper layers handle the -EBUSY return value from the crypto 
API calls? Shall they stop saturating the crypto API with requests ? How can the 
upper layers determine when can they resume sending crypto requests ? Shall they 
just try calling crypto_enqueue_request() again to see if it still returns -
EBUSY ?

Sorry if this is an obvious question and thanks for the help!

[1] http://permalink.gmane.org/gmane.linux.kernel.cryptoapi/735

Best regards,
Marek Vasut