From: Bastian Krause <bst@pengutronix.de>
To: Iuliana Prodan <iuliana.prodan@nxp.com>,
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
Date: Wed, 11 Dec 2019 14:33:41 +0100 [thread overview]
Message-ID: <56aa6894-6df9-1ade-6c22-cccb99172d2a@pengutronix.de> (raw)
In-Reply-To: <VI1PR04MB44458A1566067B5456337AEE8C5A0@VI1PR04MB4445.eurprd04.prod.outlook.com>
Hi,
On 12/11/19 1:20 PM, Iuliana Prodan wrote:
> On 12/10/2019 5:27 PM, Bastian Krause wrote:
>> On 11/17/19 11:30 PM, Iuliana Prodan wrote:
>>> Integrate crypto_engine into CAAM, to make use of the engine queue.
>>> Add support for SKCIPHER algorithms.
>>>
>>> This is intended to be used for CAAM backlogging support.
>>> The requests, with backlog flag (e.g. from dm-crypt) will be listed
>>> into crypto-engine queue and processed by CAAM when free.
>>> This changes the return codes for caam_jr_enqueue:
>>> -EINPROGRESS if OK, -EBUSY if request is backlogged,
>>> -ENOSPC if the queue is full, -EIO if it cannot map the caller's
>>> descriptor, -EINVAL if crypto_tfm not supported by crypto_engine.
>>>
>>> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
>>> Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
>>> Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
>>> ---
>>> drivers/crypto/caam/Kconfig | 1 +
>>> drivers/crypto/caam/caamalg.c | 84 +++++++++++++++++++++++++++++++++++--------
>>> drivers/crypto/caam/intern.h | 2 ++
>>> drivers/crypto/caam/jr.c | 51 ++++++++++++++++++++++++--
>>> 4 files changed, 122 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
>>> index 87053e4..1930e19 100644
>>> --- a/drivers/crypto/caam/Kconfig
>>> +++ b/drivers/crypto/caam/Kconfig
>>> @@ -33,6 +33,7 @@ config CRYPTO_DEV_FSL_CAAM_DEBUG
>>>
> ...
>>>
>>> +static int skcipher_do_one_req(struct crypto_engine *engine, void *areq)
>>> +{
>>> + struct skcipher_request *req = skcipher_request_cast(areq);
>>> + struct caam_ctx *ctx = crypto_skcipher_ctx(crypto_skcipher_reqtfm(req));
>>> + struct caam_skcipher_req_ctx *rctx = skcipher_request_ctx(req);
>>> + struct caam_jr_request_entry *jrentry;
>>> + u32 *desc = rctx->edesc->hw_desc;
>>> + int ret;
>>> +
>>> + jrentry = &rctx->edesc->jrentry;
>>> + jrentry->bklog = true;
>>> +
>>> + ret = caam_jr_enqueue_no_bklog(ctx->jrdev, desc,
>>> + rctx->skcipher_op_done, jrentry);
>>> +
>>> + if (ret != -EINPROGRESS) {
>>> + skcipher_unmap(ctx->jrdev, rctx->edesc, req);
>>> + kfree(rctx->edesc);
>>> + } else {
>>> + ret = 0;
>>> + }
>>> +
>>> + return ret;
>>
>> While testing this on a i.MX6 DualLite I see -ENOSPC being returned here
>> after a couple of GiB of data being encrypted (via dm-crypt with LUKS
>> extension). This results in these messages from crypto_engine:
>>
>> caam_jr 2101000.jr0: Failed to do one request from queue: -28
>>
>> And later..
>>
>> Buffer I/O error on device dm-0, logical block 59392
>> JBD2: Detected IO errors while flushing file data on dm-0-8
>>
>> Reproducible with something like this:
>>
>> echo "testkey" | cryptsetup luksFormat \
>> --cipher=aes-cbc-essiv:sha256 \
>> --key-file=- \
>> --key-size=256 \
>> /dev/mmcblk1p8
>> echo "testkey" | cryptsetup open \
>> --type luks \
>> --key-file=- \
>> /dev/mmcblk1p8 data
>>
>> mkfs.ext4 /dev/mapper/data
>> mount /dev/mapper/data /mnt
>>
>> set -x
>> while [ true ]; do
>> dd if=/dev/zero of=/mnt/big_file bs=1M count=1024
>> sync
>> done
>>
>> Any ideas?
>>
>
> Thanks for testing this!
Sure :)
> I reproduced this issue on imx6dl, _but_ only with the bypass sw queue
> patch. It only reproduces on some targets, e.g. on imx7d I don't get the
> -ENOSPC error. So, I believe there is a timing issue between
> crypto-engine and CAAM driver, both sending requests to CAAM hw.
> I'm debugging this and I'll let you know my findings.
I can't even use this without the "crypto: caam - bypass crypto-engine
sw queue, if empty". The mkfs.ext4 command does not even finish and I
see hung task warnings. Am I holding it wrong?
Regards,
Bastian
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2019-12-11 13:33 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-17 22:30 [PATCH 00/12] crypto: caam - backlogging support Iuliana Prodan
2019-11-17 22:30 ` [PATCH 01/12] crypto: add helper function for akcipher_request Iuliana Prodan
2019-11-18 13:29 ` Corentin Labbe
2019-11-19 14:27 ` Horia Geanta
2019-11-19 15:10 ` Gary R Hook
2019-11-22 9:08 ` Herbert Xu
2019-11-22 10:29 ` Iuliana Prodan
2019-11-22 10:34 ` Herbert Xu
2019-11-17 22:30 ` [PATCH 02/12] crypto: caam - refactor skcipher/aead/gcm/chachapoly {en,de}crypt functions Iuliana Prodan
2019-11-19 14:41 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 03/12] crypto: caam - refactor ahash_done callbacks Iuliana Prodan
2019-11-19 14:56 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 04/12] crypto: caam - refactor ahash_edesc_alloc Iuliana Prodan
2019-11-19 15:05 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 05/12] crypto: caam - refactor RSA private key _done callbacks Iuliana Prodan
2019-11-19 15:06 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 06/12] crypto: caam - change return code in caam_jr_enqueue function Iuliana Prodan
2019-11-19 15:21 ` Horia Geanta
2019-12-10 11:56 ` Bastian Krause
2019-12-10 12:28 ` Iuliana Prodan
2019-11-17 22:30 ` [PATCH 07/12] crypto: caam - refactor caam_jr_enqueue Iuliana Prodan
2019-11-19 17:55 ` Horia Geanta
2019-11-19 22:49 ` Iuliana Prodan
2019-11-20 6:48 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 08/12] crypto: caam - support crypto_engine framework for SKCIPHER algorithms Iuliana Prodan
2019-11-21 11:46 ` Horia Geanta
2019-11-22 10:33 ` Herbert Xu
2019-11-22 11:05 ` Iuliana Prodan
2019-11-22 11:09 ` Herbert Xu
2019-11-22 14:11 ` Iuliana Prodan
2019-11-22 14:31 ` Herbert Xu
2019-12-10 15:27 ` Bastian Krause
2019-12-11 12:20 ` Iuliana Prodan
2019-12-11 13:33 ` Bastian Krause [this message]
2019-11-17 22:30 ` [PATCH 09/12] crypto: caam - bypass crypto-engine sw queue, if empty Iuliana Prodan
2019-11-21 11:53 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 10/12] crypto: caam - add crypto_engine support for AEAD algorithms Iuliana Prodan
2019-11-21 16:46 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 11/12] crypto: caam - add crypto_engine support for RSA algorithms Iuliana Prodan
2019-11-21 16:53 ` Horia Geanta
2019-11-17 22:30 ` [PATCH 12/12] crypto: caam - add crypto_engine support for HASH algorithms Iuliana Prodan
2019-11-21 17:06 ` Horia Geanta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56aa6894-6df9-1ade-6c22-cccb99172d2a@pengutronix.de \
--to=bst@pengutronix.de \
--cc=aymen.sghaier@nxp.com \
--cc=davem@davemloft.net \
--cc=gary.hook@amd.com \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=iuliana.prodan@nxp.com \
--cc=kernel@pengutronix.de \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas.lendacky@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).