Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Iuliana Prodan <iuliana.prodan@nxp.com>
To:     Bastian Krause <bst@pengutronix.de>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Horia Geanta <horia.geanta@nxp.com>,
        Aymen Sghaier <aymen.sghaier@nxp.com>
CC:     "David S. Miller" <davem@davemloft.net>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Gary Hook <gary.hook@amd.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: Re: [PATCH 08/12] crypto: caam - support crypto_engine framework for
 SKCIPHER algorithms
Thread-Topic: [PATCH 08/12] crypto: caam - support crypto_engine framework for
 SKCIPHER algorithms
Thread-Index: AQHVnZa0/lOdW2TUXUqvGjTaL30gkA==
Date:   Wed, 11 Dec 2019 12:20:11 +0000
Message-ID: <VI1PR04MB44458A1566067B5456337AEE8C5A0@VI1PR04MB4445.eurprd04.prod.outlook.com>
References: <1574029845-22796-1-git-send-email-iuliana.prodan@nxp.com>
 <1574029845-22796-9-git-send-email-iuliana.prodan@nxp.com>
 <c0fa1e68-107d-f9ee-fbf2-0d0e6ef8d39d@pengutronix.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d72f027-6742-4f12-ab74-08d77e34786f
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 12:20:11.8498
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rseVABsPJDtP3vBH49bMzGt+mRNwZvxAi48wMOh9bjnpn9NgghziOfy65bVOEw4AlGOfZ5TdfJlgbOIgvruTNw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5359
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

Hi,=0A=
=0A=
On 12/10/2019 5:27 PM, Bastian Krause wrote:=0A=
> =0A=
> Hi Iulia,=0A=
> =0A=
> On 11/17/19 11:30 PM, Iuliana Prodan wrote:=0A=
>> Integrate crypto_engine into CAAM, to make use of the engine queue.=0A=
>> Add support for SKCIPHER algorithms.=0A=
>>=0A=
>> This is intended to be used for CAAM backlogging support.=0A=
>> The requests, with backlog flag (e.g. from dm-crypt) will be listed=0A=
>> into crypto-engine queue and processed by CAAM when free.=0A=
>> This changes the return codes for caam_jr_enqueue:=0A=
>> -EINPROGRESS if OK, -EBUSY if request is backlogged,=0A=
>> -ENOSPC if the queue is full, -EIO if it cannot map the caller's=0A=
>> descriptor, -EINVAL if crypto_tfm not supported by crypto_engine.=0A=
>>=0A=
>> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>=0A=
>> Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>=0A=
>> Reviewed-by: Horia Geant=E3 <horia.geanta@nxp.com>=0A=
>> ---=0A=
>>   drivers/crypto/caam/Kconfig   |  1 +=0A=
>>   drivers/crypto/caam/caamalg.c | 84 +++++++++++++++++++++++++++++++++++=
--------=0A=
>>   drivers/crypto/caam/intern.h  |  2 ++=0A=
>>   drivers/crypto/caam/jr.c      | 51 ++++++++++++++++++++++++--=0A=
>>   4 files changed, 122 insertions(+), 16 deletions(-)=0A=
>>=0A=
>> diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig=
=0A=
>> index 87053e4..1930e19 100644=0A=
>> --- a/drivers/crypto/caam/Kconfig=0A=
>> +++ b/drivers/crypto/caam/Kconfig=0A=
>> @@ -33,6 +33,7 @@ config CRYPTO_DEV_FSL_CAAM_DEBUG=0A=
>>   =0A=
...=0A=
>>   =0A=
>> +static int skcipher_do_one_req(struct crypto_engine *engine, void *areq=
)=0A=
>> +{=0A=
>> +	struct skcipher_request *req =3D skcipher_request_cast(areq);=0A=
>> +	struct caam_ctx *ctx =3D crypto_skcipher_ctx(crypto_skcipher_reqtfm(re=
q));=0A=
>> +	struct caam_skcipher_req_ctx *rctx =3D skcipher_request_ctx(req);=0A=
>> +	struct caam_jr_request_entry *jrentry;=0A=
>> +	u32 *desc =3D rctx->edesc->hw_desc;=0A=
>> +	int ret;=0A=
>> +=0A=
>> +	jrentry =3D &rctx->edesc->jrentry;=0A=
>> +	jrentry->bklog =3D true;=0A=
>> +=0A=
>> +	ret =3D caam_jr_enqueue_no_bklog(ctx->jrdev, desc,=0A=
>> +				       rctx->skcipher_op_done, jrentry);=0A=
>> +=0A=
>> +	if (ret !=3D -EINPROGRESS) {=0A=
>> +		skcipher_unmap(ctx->jrdev, rctx->edesc, req);=0A=
>> +		kfree(rctx->edesc);=0A=
>> +	} else {=0A=
>> +		ret =3D 0;=0A=
>> +	}=0A=
>> +=0A=
>> +	return ret;=0A=
> =0A=
> While testing this on a i.MX6 DualLite I see -ENOSPC being returned here=
=0A=
> after a couple of GiB of data being encrypted (via dm-crypt with LUKS=0A=
> extension). This results in these messages from crypto_engine:=0A=
> =0A=
>    caam_jr 2101000.jr0: Failed to do one request from queue: -28=0A=
> =0A=
> And later..=0A=
> =0A=
>    Buffer I/O error on device dm-0, logical block 59392=0A=
>    JBD2: Detected IO errors while flushing file data on dm-0-8=0A=
> =0A=
> Reproducible with something like this:=0A=
> =0A=
>    echo "testkey" | cryptsetup luksFormat \=0A=
>      --cipher=3Daes-cbc-essiv:sha256 \=0A=
>      --key-file=3D- \=0A=
>      --key-size=3D256 \=0A=
>      /dev/mmcblk1p8=0A=
>    echo "testkey" | cryptsetup open \=0A=
>      --type luks \=0A=
>      --key-file=3D- \=0A=
>      /dev/mmcblk1p8 data=0A=
> =0A=
>    mkfs.ext4 /dev/mapper/data=0A=
>    mount /dev/mapper/data /mnt=0A=
> =0A=
>    set -x=0A=
>    while [ true ]; do=0A=
>      dd if=3D/dev/zero of=3D/mnt/big_file bs=3D1M count=3D1024=0A=
>      sync=0A=
>    done=0A=
> =0A=
> Any ideas?=0A=
> =0A=
=0A=
Thanks for testing this!=0A=
I reproduced this issue on imx6dl, _but_ only with the bypass sw queue =0A=
patch. It only reproduces on some targets, e.g. on imx7d I don't get the =
=0A=
-ENOSPC error. So, I believe there is a timing issue between =0A=
crypto-engine and CAAM driver, both sending requests to CAAM hw.=0A=
I'm debugging this and I'll let you know my findings.=0A=
=0A=
Best regards,=0A=
Iulia=0A=