On Mon, Nov 25, 2024 at 02:00:52PM +0100, Harald Freudenberger wrote: > > Well, I fear the paes implementation is similar broken. The EBUSY > is a reaction of the zcrpyt/AP bus when no eligible crypto card has > been found and a ansynchronous bus scan is running. In that case the > caller should retry in the hope that the bus scan detects a eligible card. So this is a rare event, right? Can we expect this to eventually succeed? Or are there situations where this can legitimately fail? > Please note that the sleep only happens in in_task() context for the > paes implementation. That's still broken. There are situations where in_task() is true but you can't sleep, e.g., spin locks held without preemption. In general, you cannot determine whether you can sleep safely. That's why we rely on the user to tell us whether we can sleep or not. > For the phmac implementation - didn't you suggest to wrap this with > an asynchronous hmac to be able to sleep in the wrapped synchronous hmac? I don't think this is a viable strategy since these are not short sleeps. I think you're better off making both paes and phmac async. However, they can remain synchronous in practice until you actually need to sleep. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
