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@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
