All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Kyle Sanderson <kyle.leet@gmail.com>,
	Dave Chinner <david@fromorbit.com>,
	qat-linux@intel.com, Linux-Kernal <linux-kernel@vger.kernel.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	device-mapper development <dm-devel@redhat.com>
Subject: Re: Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with dm-crypt + xfs
Date: Thu, 3 Mar 2022 21:44:53 +0000	[thread overview]
Message-ID: <YiE21aPGG5DHwJvb@gmail.com> (raw)
In-Reply-To: <YiEyGoHacN80FcOL@silpixa00400314>

On Thu, Mar 03, 2022 at 09:24:42PM +0000, Giovanni Cabiddu wrote:
> On Thu, Mar 03, 2022 at 07:21:33PM +0000, Eric Biggers wrote:
> > If these algorithms have critical bugs, which it appears they do, then IMO it
> > would be better to disable them (either stop registering them, or disable the
> > whole driver) than to leave them available with low cra_priority.  Low
> > cra_priority doesn't guarantee that they aren't used.
> Thanks for your feedback Eric.
> 
> Here is a patch that disables the registration of the algorithms in the
> QAT driver by setting, a config time, the number of HW queues (aka
> instances) to zero.
> 
> ---8<---
> From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Subject: [PATCH] crypto: qat - disable registration of algorithms
> Organization: Intel Research and Development Ireland Ltd - Co. Reg. #308263 - Collinstown Industrial Park, Leixlip, County Kildare - Ireland
> 
> The implementations of aead and skcipher in the QAT driver do not
> support properly requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set.
> If the HW queue is full, the driver returns -EBUSY but does not enqueue
> the request.
> This can result in applications like dm-crypt waiting indefinitely for a
> completion of a request that was never submitted to the hardware.
> 
> To avoid this problem, disable the registration of all skcipher and aead
> implementations in the QAT driver by setting the number of crypto
> instances to 0 at configuration time.
> 
> This patch deviates from the original upstream solution, that prevents
> dm-crypt to use drivers registered with the flag
> CRYPTO_ALG_ALLOCATES_MEMORY, since a backport of that set to stable
> kernels may have a too wide effect.
> 
> commit 7bcb2c99f8ed032cfb3f5596b4dccac6b1f501df upstream
> commit 2eb27c11937ee9984c04b75d213a737291c5f58c upstream
> commit fbb6cda44190d72aa5199d728797aabc6d2ed816 upstream
> commit b8aa7dc5c7535f9abfca4bceb0ade9ee10cf5f54 upstream
> commit cd74693870fb748d812867ba49af733d689a3604 upstream
> 
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> ---
>  drivers/crypto/qat/qat_common/qat_crypto.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Sounds good; is there any reason not to apply this upstream too, though?
You could revert it later as part of the patch series that fixes the driver.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Greg KH <gregkh@linuxfoundation.org>,
	Dave Chinner <david@fromorbit.com>,
	qat-linux@intel.com, Linux-Kernal <linux-kernel@vger.kernel.org>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	device-mapper development <dm-devel@redhat.com>,
	Kyle Sanderson <kyle.leet@gmail.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [dm-devel] Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with dm-crypt + xfs
Date: Thu, 3 Mar 2022 21:44:53 +0000	[thread overview]
Message-ID: <YiE21aPGG5DHwJvb@gmail.com> (raw)
In-Reply-To: <YiEyGoHacN80FcOL@silpixa00400314>

On Thu, Mar 03, 2022 at 09:24:42PM +0000, Giovanni Cabiddu wrote:
> On Thu, Mar 03, 2022 at 07:21:33PM +0000, Eric Biggers wrote:
> > If these algorithms have critical bugs, which it appears they do, then IMO it
> > would be better to disable them (either stop registering them, or disable the
> > whole driver) than to leave them available with low cra_priority.  Low
> > cra_priority doesn't guarantee that they aren't used.
> Thanks for your feedback Eric.
> 
> Here is a patch that disables the registration of the algorithms in the
> QAT driver by setting, a config time, the number of HW queues (aka
> instances) to zero.
> 
> ---8<---
> From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Subject: [PATCH] crypto: qat - disable registration of algorithms
> Organization: Intel Research and Development Ireland Ltd - Co. Reg. #308263 - Collinstown Industrial Park, Leixlip, County Kildare - Ireland
> 
> The implementations of aead and skcipher in the QAT driver do not
> support properly requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set.
> If the HW queue is full, the driver returns -EBUSY but does not enqueue
> the request.
> This can result in applications like dm-crypt waiting indefinitely for a
> completion of a request that was never submitted to the hardware.
> 
> To avoid this problem, disable the registration of all skcipher and aead
> implementations in the QAT driver by setting the number of crypto
> instances to 0 at configuration time.
> 
> This patch deviates from the original upstream solution, that prevents
> dm-crypt to use drivers registered with the flag
> CRYPTO_ALG_ALLOCATES_MEMORY, since a backport of that set to stable
> kernels may have a too wide effect.
> 
> commit 7bcb2c99f8ed032cfb3f5596b4dccac6b1f501df upstream
> commit 2eb27c11937ee9984c04b75d213a737291c5f58c upstream
> commit fbb6cda44190d72aa5199d728797aabc6d2ed816 upstream
> commit b8aa7dc5c7535f9abfca4bceb0ade9ee10cf5f54 upstream
> commit cd74693870fb748d812867ba49af733d689a3604 upstream
> 
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> ---
>  drivers/crypto/qat/qat_common/qat_crypto.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Sounds good; is there any reason not to apply this upstream too, though?
You could revert it later as part of the patch series that fixes the driver.

- Eric

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2022-03-03 21:44 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-19  5:02 Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with dm-crypt + xfs Kyle Sanderson
2022-02-19  5:02 ` [dm-devel] " Kyle Sanderson
2022-02-19 21:03 ` Dave Chinner
2022-02-19 21:03   ` [dm-devel] " Dave Chinner
2022-02-19 23:00   ` Kyle Sanderson
2022-02-19 23:00     ` [dm-devel] " Kyle Sanderson
2022-02-21 11:47     ` Giovanni Cabiddu
2022-02-21 11:47       ` [dm-devel] " Giovanni Cabiddu
2022-02-28  8:18       ` Kyle Sanderson
2022-02-28  8:18         ` [dm-devel] " Kyle Sanderson
2022-02-28 19:25         ` Linus Torvalds
2022-02-28 19:25           ` [dm-devel] " Linus Torvalds
2022-02-28 20:39           ` Giovanni Cabiddu
2022-02-28 20:39             ` [dm-devel] " Giovanni Cabiddu
2022-02-28 20:59             ` Greg KH
2022-02-28 20:59               ` [dm-devel] " Greg KH
2022-02-28 23:26             ` Herbert Xu
2022-02-28 23:26               ` [dm-devel] " Herbert Xu
2022-03-01  1:12               ` Linus Torvalds
2022-03-01  1:12                 ` [dm-devel] " Linus Torvalds
2022-03-01  4:11                 ` Herbert Xu
2022-03-01  4:11                   ` [dm-devel] " Herbert Xu
2022-03-02 10:29                   ` Greg KH
2022-03-02 10:29                     ` [dm-devel] " Greg KH
2022-03-02 11:49                     ` Giovanni Cabiddu
2022-03-02 11:49                       ` [dm-devel] " Giovanni Cabiddu
2022-03-02 14:56                       ` Greg KH
2022-03-02 14:56                         ` [dm-devel] " Greg KH
2022-03-02 22:27                         ` Herbert Xu
2022-03-02 22:27                           ` [dm-devel] " Herbert Xu
2022-03-02 22:42                           ` Giovanni Cabiddu
2022-03-02 22:42                             ` [dm-devel] " Giovanni Cabiddu
2022-03-02 22:45                             ` Herbert Xu
2022-03-02 22:45                               ` [dm-devel] " Herbert Xu
2022-03-03 13:49                               ` Giovanni Cabiddu
2022-03-03 13:49                                 ` [dm-devel] " Giovanni Cabiddu
2022-03-03 19:21                                 ` Eric Biggers
2022-03-03 19:21                                   ` [dm-devel] " Eric Biggers
2022-03-03 21:24                                   ` Giovanni Cabiddu
2022-03-03 21:24                                     ` [dm-devel] " Giovanni Cabiddu
2022-03-03 21:44                                     ` Eric Biggers [this message]
2022-03-03 21:44                                       ` Eric Biggers
2022-03-04 17:50                                       ` Giovanni Cabiddu
2022-03-16 21:38                                         ` Kyle Sanderson
2022-03-16 21:38                                           ` [dm-devel] " Kyle Sanderson
2022-03-16 22:13                                           ` Herbert Xu
2022-03-16 22:13                                             ` [dm-devel] " Herbert Xu
2022-02-28 21:13           ` Milan Broz
2022-02-28 21:13             ` Milan Broz

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=YiE21aPGG5DHwJvb@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=david@fromorbit.com \
    --cc=dm-devel@redhat.com \
    --cc=giovanni.cabiddu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=kyle.leet@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=qat-linux@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.