[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whVT2GcwiJM8m-XzgJj8CjytTHi_pmgmOnSpzvGWzZM1A@mail.gmail.com>
Date: Mon, 28 Feb 2022 11:25:49 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kyle Sanderson <kyle.leet@...il.com>
Cc: Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Dave Chinner <david@...morbit.com>, qat-linux@...el.com,
Linux-Kernal <linux-kernel@...r.kernel.org>,
linux-xfs <linux-xfs@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
device-mapper development <dm-devel@...hat.com>,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: Intel QAT on A2SDi-8C-HLN4F causes massive data corruption with
dm-crypt + xfs
On Mon, Feb 28, 2022 at 12:18 AM Kyle Sanderson <kyle.leet@...il.com> wrote:
>
> Makes sense - this kernel driver has been destroying users for many
> years. I'm disappointed that this critical bricking failure isn't
> searchable for others.
It does sound like we should just disable that driver entirely until
it is fixed.
Or at least the configuration that can cause problems, if there is
some particular sub-case. Although from a cursory glance and the
noises made in this thread, it looks like it's all of the 'qat_aeads'
cases (since that uses qat_alg_aead_enc() which can return -EAGAIN),
which effectively means that all of the QAT stuff.
So presumably CRYPTO_DEV_QAT should just be marked as
depends on BROKEN || COMPILE_TEST
or similar?
Linus
Powered by blists - more mailing lists