Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: Jd288VGPAwgy4b4TdXOPE/95tmXIVnzoIGOHasWlIv2cKXFbazBZbqFFinPbjLr8ZZ1hOJAgDo
 OvetUAfhr7+/DOMTGWC9S4FI85E0uOgPdekdqCFdq6l6nQUtQVcMXtnUblvNP5xry6QfEX1cx4
 HwYaavGL9CB2cqLS6rUhPRG1Cuf404zVC6UIdJk+t6ADOehNBqCarhx9vo4tLS4Ka5Ywhlgw4o
 KaIsiEg2yyY0XQeEosMsJ24uknLhxAUjV4U9/crPSspgmBWleLSK9rVsavqSIaFcC+uQXB/OJH
 BGw=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     Ignat Korchagin <ignat@cloudflare.com>,
        "agk@redhat.com" <agk@redhat.com>,
        "snitzer@redhat.com" <snitzer@redhat.com>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>,
        "dm-crypt@saout.de" <dm-crypt@saout.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "ebiggers@kernel.org" <ebiggers@kernel.org>,
        "mpatocka@redhat.com" <mpatocka@redhat.com>,
        "kernel-team@cloudflare.com" <kernel-team@cloudflare.com>
Subject: Re: [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt
 workqueues
Thread-Topic: [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt
 workqueues
Thread-Index: AQHWS/06zZqSdIYp0k2e+HMuy61K4w==
Date:   Tue, 30 Jun 2020 03:45:48 +0000
Message-ID: <CY4PR04MB37518C4BF580DABEDB1BD8F2E76F0@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <20200626210302.1813-1-ignat@cloudflare.com>
 <CY4PR04MB375127DC313F70875CAAC841E76F0@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200630030944.GA20706@gondor.apana.org.au>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ff93a97-1b8c-4bc0-8105-08d81ca813eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 03:45:48.5560
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PZrfZNnXCRHjVE8zUcSF+f4uxIu8w4jMQS0vFuS646oghFwsQz6UPR5B5+E4J2Qu5i7ht8XPA0+FXKkTcrilKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB0422
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/06/30 12:09, Herbert Xu wrote:=0A=
> On Tue, Jun 30, 2020 at 02:51:17AM +0000, Damien Le Moal wrote:=0A=
>>=0A=
>>> @@ -1463,12 +1465,12 @@ static void crypt_alloc_req_skcipher(struct cry=
pt_config *cc,=0A=
>>>  	 * requests if driver request queue is full.=0A=
>>>  	 */=0A=
>>>  	skcipher_request_set_callback(ctx->r.req,=0A=
>>> -	    CRYPTO_TFM_REQ_MAY_BACKLOG,=0A=
>>> +	    nobacklog ? 0 : CRYPTO_TFM_REQ_MAY_BACKLOG,=0A=
>>>  	    kcryptd_async_done, dmreq_of_req(cc, ctx->r.req));=0A=
>>=0A=
>> Will not specifying CRYPTO_TFM_REQ_MAY_BACKLOG always cause the crypto A=
PI to=0A=
>> return -EBUSY ? From the comment above the skcipher_request_set_callback=
(), it=0A=
>> seems that this will be the case only if the skcipher diver queue is ful=
l. So in=0A=
>> other word, keeping the kcryptd_async_done() callback and executing the =
skcipher=0A=
>> request through crypt_convert() and crypt_convert_block_skcipher() may s=
till end=0A=
>> up being an asynchronous operation. Can you confirm this and is it what =
you=0A=
>> intended to implement ?=0A=
> =0A=
> The purpose of MAY_BACKLOG is to make the crypto request reliable.=0A=
> It has nothing to do with whether the request will be synchronous=0A=
> or not.=0A=
> =0A=
> Without the backlog flag, if the hardware queue is full the request=0A=
> will simply be dropped, which is appropriate in the network stack=0A=
> with IPsec where congestion can be dealt with at the source.=0A=
> =0A=
> Block layer on the other hand should always use the backlog flag=0A=
> and stop sending more requests to the crypto API until the congestion=0A=
> goes away.=0A=
=0A=
OK. Thanks for the information. So it sounds like this patch still needs so=
me=0A=
more fixes.=0A=
=0A=
> =0A=
> Cheers,=0A=
> =0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=