From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 30 Jun 2020 05:09:57 +0200 (CEST) Date: Tue, 30 Jun 2020 13:09:44 +1000 From: Herbert Xu Message-ID: <20200630030944.GA20706@gondor.apana.org.au> References: <20200626210302.1813-1-ignat@cloudflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Damien Le Moal Cc: Ignat Korchagin , "agk@redhat.com" , "snitzer@redhat.com" , "dm-devel@redhat.com" , "dm-crypt@saout.de" , "linux-kernel@vger.kernel.org" , "ebiggers@kernel.org" , "mpatocka@redhat.com" , "kernel-team@cloudflare.com" 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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt