On Thu, 19 Jan 2023 at 10:58, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > Fair enough. > > 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. > Ah right - the request is only split across two calls into the underlying skcipher if CTS is needed, and otherwise, we just forward whatever non-zero return value we received. Thanks for the explanation. Acked-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
