Re: [PATCH v6 2/2] s390/crypto: New s390 specific protected key hash phmac

[Herbert Xu <herbert@gondor.apana.org.au>]

On Mon, Dec 02, 2024 at 06:25:22PM +0100, Harald Freudenberger wrote:
>
> - The attempt to derive a protected key usable by the cpacf instructions
>   depends of the raw key material used. For 'clear key' material the
>   derivation process is a simple instruction which can't fail.
>   A more preferred way however is to use 'secure key' material which
>   is transferred to a crypto card and then re-wrapped to be usable
>   with cpacf instructions. This requires communication with a crypto
>   card and thus may fail - because there is no card at all or there
>   is temporarily no card available or the card is in bad state. If there
>   is no usable card the AP bus returns -EBUSY at the pkey_key2protkey()
>   function and triggers an asynchronous bus scan. As long as this scan
>   is running (usually about 100ms or so) the -EBUSY is returned to indicate
>   that the caller should retry "later". Other states are covered with
>   other return codes like ENODEV or EIO and the caller is not supposed
>   to loop but should fail. When there is no accessible hardware available
>   to derive a protected key either the user or the admin broke something
>   or something went really the bad way and then there is no help but the
>   storage device must fail.

Thanks for the explanation.  I think it's fair enough to fail an
op if the hardware is absent or broken.

So all I need is for you to turn the BUSY case into a delayed retry
and I think that should be good enough.

> - Do I get you right, that a completion is ok? I always had the impression
>   that waiting on a completion is also a sleeping act and thus not allowed?

No, what I mean is that if you get an EBUSY, you should return
-EINPROGRESS to indicate that the operation is pending, and then
schedule a delayed work to retry the operation.  When the retry
fails or succeeds, it should invoke the callback with the correct
error status.

If the retry gets EBUSY again, then schedule another delayed
work, or fail permanently by invoking the callback if you hit
some sort of threshold like your existing limit of 3.

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