Re: [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues

From: Damien Le Moal
Date: Mon Jun 29 2020 - 23:45:53 EST


On 2020/06/30 12:09, Herbert Xu wrote:
> 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.

OK. Thanks for the information. So it sounds like this patch still needs some
more fixes.

>
> Cheers,
>


--
Damien Le Moal
Western Digital Research