On Tue, Jun 30, 2020 at 02:51:17AM +0000, Damien Le Moal wrote: > > > @@ -1463,12 +1465,12 @@ static void crypt_alloc_req_skcipher(struct crypt_config *cc, > > * requests if driver request queue is full. > > */ > > skcipher_request_set_callback(ctx->r.req, > > - CRYPTO_TFM_REQ_MAY_BACKLOG, > > + nobacklog ? 0 : CRYPTO_TFM_REQ_MAY_BACKLOG, > > kcryptd_async_done, dmreq_of_req(cc, ctx->r.req)); > > Will not specifying CRYPTO_TFM_REQ_MAY_BACKLOG always cause the crypto API to > return -EBUSY ? From the comment above the skcipher_request_set_callback(), it > seems that this will be the case only if the skcipher diver queue is full. So in > other word, keeping the kcryptd_async_done() callback and executing the skcipher > request through crypt_convert() and crypt_convert_block_skcipher() may still end > up being an asynchronous operation. Can you confirm this and is it what you > intended to implement ? The purpose of MAY_BACKLOG is to make the crypto request reliable. It has nothing to do with whether the request will be synchronous or not. Without the backlog flag, if the hardware queue is full the request will simply be dropped, which is appropriate in the network stack with IPsec where congestion can be dealt with at the source. Block layer on the other hand should always use the backlog flag and stop sending more requests to the crypto API until the congestion goes away. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
