Thread (43 messages) 43 messages, 2 authors, 2017-10-11

Re: [PATCH v8 01/20] crypto: change transient busy return code to -EAGAIN

From: Gilad Ben-Yossef <gilad@benyossef.com>
Date: 2017-10-07 07:51:49
Also in: dm-devel, keyrings, linux-arm-kernel, linux-cifs, linux-crypto, linux-fscrypt, linux-mediatek, linux-raid, linux-security-module, lkml

On Sat, Oct 7, 2017 at 6:05 AM, Herbert Xu [off-list ref] wrote:
On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
quoted
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 5e92bd2..3b3c154 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -39,6 +39,20 @@ struct algif_hash_tfm {
      bool has_key;
 };

+/* Previous versions of crypto_* ops used to return -EBUSY
+ * rather than -EAGAIN to indicate being tied up. The in
+ * kernel API changed but we don't want to break the user
+ * space API. As only the hash user interface exposed this
+ * error ever to the user, do the translation here.
+ */
+static inline int crypto_user_err(int err)
+{
+     if (err == -EAGAIN)
+             return -EBUSY;
+
+     return err;
I don't see the need to carry along this baggage.  Does anyone
in user-space actually rely on EBUSY?

I am not aware of anyone who does. I was just trying to avoid
changing the user ABI.

Shall I roll a new revision without this patch?

Thanks,
Gilad
Cheers,
--
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help