Re: [PATCH] crypto: xts - Handle EBUSY correctly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 19, 2023 at 10:50:26AM +0100, Ard Biesheuvel wrote:
> On Thu, 19 Jan 2023 at 10:08, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > As it is xts only handles the special return value of EINPROGERSS,
> 
> EINPROGRESS

Thanks, I will fix this.

> > -               rctx->subreq.base.flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
> > +               rctx->subreq.base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
> 
> I don't get this bit. We used to preserve CRYPTO_TFM_REQ_MAY_BACKLOG
> before (along with all other flags except MAY_SLEEP), but now, we
> *only* preserve CRYPTO_TFM_REQ_MAY_BACKLOG.

This change is just in case we introduce any more flags in
future that we may not wish to pass along (as this code knows
nothing about it).

> So how is this related? Why are we clearing
> CRYPTO_TFM_REQ_FORBID_WEAK_KEYS here for instance?

WEAK_KEYS is only defined for setkey.  Only MAY_SLEEP and MAY_BACKLOG
are currently meaningful for encryption and decryption.

> Apologies for the noob questions about this aspect of the crypto API,
> but I suppose this means that, if CRYPTO_TFM_REQ_MAY_BACKLOG was
> specified, it is up to the skcipher implementation to queue up the
> request and return -EBUSY, as opposed to starting the request
> asynchronously and returning -EINPROGRESS?
> 
> So why the distinction? If the skcipher signals that the request is
> accepted and will complete asynchronously, couldn't it use EINPROGRESS
> for both cases? Or is the EBUSY interpreted differently by the caller,
> for providing back pressure to the source?

EBUSY signals to the caller that it must back off and not issue
any more requests.  The caller should wait for a completion call
with EINPROGRESS to indicate that it may issue new requests.

For xts we essentially ignore EBUSY at this point, and assume that
if our own caller issued any more requests it would directly get
an EBUSY which should be sufficient to avoid total collapse.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux