On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 02:18:17PM -0400, Mikulas Patocka wrote:
> >
> >
> > On Tue, 16 Jun 2020, Eric Biggers wrote:
> >
> > > On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > > > Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> > > > CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
> > > > that sleeps.
> > > >
> > > > Signed-off-by: Mikulas Patocka <mpato...@redhat.com>
> > >
> > > I think you need to split this up per driver with a proper explanation
> > > and a
> > > "Fixes:" tag for each driver.
> > >
> > > Also, these bugs should have been detected by the crypto self-tests
> > > already,
> > > since they test having preemption disabled and CRYPTO_TFM_REQ_MAY_SLEEP
> > > cleared.
> > > Can you double check whether these are all valid fixes? One thing to
> > > watch out
> > >
> > > for is that CRYPTO_TFM_REQ_MAY_SLEEP only applies to the function call
> > > like
> > > crypto_skcipher_encrypt() itself. If the implementation is asynchronous
> > > and the
> > > request gets processed in the background (i.e. if
> > > crypto_skcipher_encrypt()
> > > returns -EINPROGRESS), the background work doesn't have to honor
> > > CRYPTO_TFM_REQ_MAY_SLEEP.
> > >
> > > - Eric
> >
> > I can only compile-test this patch. I don't have the hardware.
> >
>
> I'm just asking for you to check the code extra carefully. The fact that the
> self-tests should have been detecting this type of bug implies that these
> might
> not actually be valid fixes.
I've checked it more thoroughly and found out that 3 out of 5 drivers do
the GFP_KERNEL allocation from crypto-engine callback. So, it is
supposedly OK.
> However, we do know that not all crypto drivers are being actively tested with
> the latest self-tests and with kernel debugging options enabled. So it's
> expected that some are indeed broken.
>
> - Eric
The broken ones are drivers/crypto/cavium/cpt/ and
drivers/crypto/hisilicon/sec/
I'm sending patches for them.
Mikulas
