* [PATCH v9 07/20] crypto: move algif to generic async completion
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
algif starts several async crypto ops and waits for their completion.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
crypto/af_alg.c | 27 ---------------------------
crypto/algif_aead.c | 8 ++++----
crypto/algif_hash.c | 30 ++++++++++++++----------------
crypto/algif_skcipher.c | 9 ++++-----
include/crypto/if_alg.h | 15 +--------------
5 files changed, 23 insertions(+), 66 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 337cf38..85cea9d 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -481,33 +481,6 @@ int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con)
}
EXPORT_SYMBOL_GPL(af_alg_cmsg_send);
-int af_alg_wait_for_completion(int err, struct af_alg_completion *completion)
-{
- switch (err) {
- case -EINPROGRESS:
- case -EBUSY:
- wait_for_completion(&completion->completion);
- reinit_completion(&completion->completion);
- err = completion->err;
- break;
- };
-
- return err;
-}
-EXPORT_SYMBOL_GPL(af_alg_wait_for_completion);
-
-void af_alg_complete(struct crypto_async_request *req, int err)
-{
- struct af_alg_completion *completion = req->data;
-
- if (err == -EINPROGRESS)
- return;
-
- completion->err = err;
- complete(&completion->completion);
-}
-EXPORT_SYMBOL_GPL(af_alg_complete);
-
/**
* af_alg_alloc_tsgl - allocate the TX SGL
*
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 516b38c..aacae08 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -278,11 +278,11 @@ static int _aead_recvmsg(struct socket *sock, struct msghdr *msg,
/* Synchronous operation */
aead_request_set_callback(&areq->cra_u.aead_req,
CRYPTO_TFM_REQ_MAY_BACKLOG,
- af_alg_complete, &ctx->completion);
- err = af_alg_wait_for_completion(ctx->enc ?
+ crypto_req_done, &ctx->wait);
+ err = crypto_wait_req(ctx->enc ?
crypto_aead_encrypt(&areq->cra_u.aead_req) :
crypto_aead_decrypt(&areq->cra_u.aead_req),
- &ctx->completion);
+ &ctx->wait);
}
/* AIO operation in progress */
@@ -554,7 +554,7 @@ static int aead_accept_parent_nokey(void *private, struct sock *sk)
ctx->merge = 0;
ctx->enc = 0;
ctx->aead_assoclen = 0;
- af_alg_init_completion(&ctx->completion);
+ crypto_init_wait(&ctx->wait);
ask->private = ctx;
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 5e92bd2..76d2e71 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -26,7 +26,7 @@ struct hash_ctx {
u8 *result;
- struct af_alg_completion completion;
+ struct crypto_wait wait;
unsigned int len;
bool more;
@@ -88,8 +88,7 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
if ((msg->msg_flags & MSG_MORE))
hash_free_result(sk, ctx);
- err = af_alg_wait_for_completion(crypto_ahash_init(&ctx->req),
- &ctx->completion);
+ err = crypto_wait_req(crypto_ahash_init(&ctx->req), &ctx->wait);
if (err)
goto unlock;
}
@@ -110,8 +109,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
ahash_request_set_crypt(&ctx->req, ctx->sgl.sg, NULL, len);
- err = af_alg_wait_for_completion(crypto_ahash_update(&ctx->req),
- &ctx->completion);
+ err = crypto_wait_req(crypto_ahash_update(&ctx->req),
+ &ctx->wait);
af_alg_free_sg(&ctx->sgl);
if (err)
goto unlock;
@@ -129,8 +128,8 @@ static int hash_sendmsg(struct socket *sock, struct msghdr *msg,
goto unlock;
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
- err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
- &ctx->completion);
+ err = crypto_wait_req(crypto_ahash_final(&ctx->req),
+ &ctx->wait);
}
unlock:
@@ -171,7 +170,7 @@ static ssize_t hash_sendpage(struct socket *sock, struct page *page,
} else {
if (!ctx->more) {
err = crypto_ahash_init(&ctx->req);
- err = af_alg_wait_for_completion(err, &ctx->completion);
+ err = crypto_wait_req(err, &ctx->wait);
if (err)
goto unlock;
}
@@ -179,7 +178,7 @@ static ssize_t hash_sendpage(struct socket *sock, struct page *page,
err = crypto_ahash_update(&ctx->req);
}
- err = af_alg_wait_for_completion(err, &ctx->completion);
+ err = crypto_wait_req(err, &ctx->wait);
if (err)
goto unlock;
@@ -215,17 +214,16 @@ static int hash_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
if (!result && !ctx->more) {
- err = af_alg_wait_for_completion(
- crypto_ahash_init(&ctx->req),
- &ctx->completion);
+ err = crypto_wait_req(crypto_ahash_init(&ctx->req),
+ &ctx->wait);
if (err)
goto unlock;
}
if (!result || ctx->more) {
ctx->more = 0;
- err = af_alg_wait_for_completion(crypto_ahash_final(&ctx->req),
- &ctx->completion);
+ err = crypto_wait_req(crypto_ahash_final(&ctx->req),
+ &ctx->wait);
if (err)
goto unlock;
}
@@ -476,13 +474,13 @@ static int hash_accept_parent_nokey(void *private, struct sock *sk)
ctx->result = NULL;
ctx->len = len;
ctx->more = 0;
- af_alg_init_completion(&ctx->completion);
+ crypto_init_wait(&ctx->wait);
ask->private = ctx;
ahash_request_set_tfm(&ctx->req, hash);
ahash_request_set_callback(&ctx->req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- af_alg_complete, &ctx->completion);
+ crypto_req_done, &ctx->wait);
sk->sk_destruct = hash_sock_destruct;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 8ae4170..9954b07 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -129,12 +129,11 @@ static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
skcipher_request_set_callback(&areq->cra_u.skcipher_req,
CRYPTO_TFM_REQ_MAY_SLEEP |
CRYPTO_TFM_REQ_MAY_BACKLOG,
- af_alg_complete,
- &ctx->completion);
- err = af_alg_wait_for_completion(ctx->enc ?
+ crypto_req_done, &ctx->wait);
+ err = crypto_wait_req(ctx->enc ?
crypto_skcipher_encrypt(&areq->cra_u.skcipher_req) :
crypto_skcipher_decrypt(&areq->cra_u.skcipher_req),
- &ctx->completion);
+ &ctx->wait);
}
/* AIO operation in progress */
@@ -388,7 +387,7 @@ static int skcipher_accept_parent_nokey(void *private, struct sock *sk)
ctx->more = 0;
ctx->merge = 0;
ctx->enc = 0;
- af_alg_init_completion(&ctx->completion);
+ crypto_init_wait(&ctx->wait);
ask->private = ctx;
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 75ec9c6..6abf0a3 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -40,11 +40,6 @@ struct alg_sock {
void *private;
};
-struct af_alg_completion {
- struct completion completion;
- int err;
-};
-
struct af_alg_control {
struct af_alg_iv *iv;
int op;
@@ -152,7 +147,7 @@ struct af_alg_ctx {
void *iv;
size_t aead_assoclen;
- struct af_alg_completion completion;
+ struct crypto_wait wait;
size_t used;
size_t rcvused;
@@ -177,19 +172,11 @@ void af_alg_link_sg(struct af_alg_sgl *sgl_prev, struct af_alg_sgl *sgl_new);
int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con);
-int af_alg_wait_for_completion(int err, struct af_alg_completion *completion);
-void af_alg_complete(struct crypto_async_request *req, int err);
-
static inline struct alg_sock *alg_sk(struct sock *sk)
{
return (struct alg_sock *)sk;
}
-static inline void af_alg_init_completion(struct af_alg_completion *completion)
-{
- init_completion(&completion->completion);
-}
-
/**
* Size of available buffer for sending data from user space to kernel.
*
--
2.7.4
^ permalink raw reply related
* [PATCH v9 05/20] crypto: marvell/cesa: remove redundant backlog checks on EBUSY
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
Now that -EBUSY return code only indicates backlog queueing
we can safely remove the now redundant check for the
CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/crypto/marvell/cesa.c | 3 +--
drivers/crypto/marvell/cesa.h | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index b657e7c..ff73aa5 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -181,8 +181,7 @@ int mv_cesa_queue_req(struct crypto_async_request *req,
spin_lock_bh(&engine->lock);
ret = crypto_enqueue_request(&engine->queue, req);
if ((mv_cesa_req_get_type(creq) == CESA_DMA_REQ) &&
- (ret == -EINPROGRESS ||
- (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ (ret == -EINPROGRESS || ret == -EBUSY))
mv_cesa_tdma_chain(engine, creq);
spin_unlock_bh(&engine->lock);
diff --git a/drivers/crypto/marvell/cesa.h b/drivers/crypto/marvell/cesa.h
index b7872f6..63c8457 100644
--- a/drivers/crypto/marvell/cesa.h
+++ b/drivers/crypto/marvell/cesa.h
@@ -763,7 +763,7 @@ static inline int mv_cesa_req_needs_cleanup(struct crypto_async_request *req,
* the backlog and will be processed later. There's no need to
* clean it up.
*/
- if (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)
+ if (ret == -EBUSY)
return false;
/* Request wasn't queued, we need to clean it up */
--
2.7.4
^ permalink raw reply related
* [PATCH v9 04/20] crypto: remove redundant backlog checks on EBUSY
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
Now that -EBUSY return code only indicates backlog queueing
we can safely remove the now redundant check for the
CRYPTO_TFM_REQ_MAY_BACKLOG flag when -EBUSY is returned.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
---
crypto/ahash.c | 12 +++---------
crypto/cts.c | 6 ++----
crypto/lrw.c | 8 ++------
crypto/rsa-pkcs1pad.c | 16 ++++------------
crypto/xts.c | 8 ++------
5 files changed, 13 insertions(+), 37 deletions(-)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 5e8666e..3a35d67 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -334,9 +334,7 @@ static int ahash_op_unaligned(struct ahash_request *req,
return err;
err = op(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY && (ahash_request_flags(req) &
- CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
ahash_restore_req(req, err);
@@ -394,9 +392,7 @@ static int ahash_def_finup_finish1(struct ahash_request *req, int err)
req->base.complete = ahash_def_finup_done2;
err = crypto_ahash_reqtfm(req)->final(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY && (ahash_request_flags(req) &
- CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
out:
@@ -432,9 +428,7 @@ static int ahash_def_finup(struct ahash_request *req)
return err;
err = tfm->update(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY && (ahash_request_flags(req) &
- CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
return ahash_def_finup_finish1(req, err);
diff --git a/crypto/cts.c b/crypto/cts.c
index 243f591..4773c18 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -136,8 +136,7 @@ static void crypto_cts_encrypt_done(struct crypto_async_request *areq, int err)
goto out;
err = cts_cbc_encrypt(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY && req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (err == -EINPROGRESS || err == -EBUSY)
return;
out:
@@ -229,8 +228,7 @@ static void crypto_cts_decrypt_done(struct crypto_async_request *areq, int err)
goto out;
err = cts_cbc_decrypt(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY && req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (err == -EINPROGRESS || err == -EBUSY)
return;
out:
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 92df312..cbbd7c5 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -328,9 +328,7 @@ static int do_encrypt(struct skcipher_request *req, int err)
crypto_skcipher_encrypt(subreq) ?:
post_crypt(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY &&
- req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
}
@@ -380,9 +378,7 @@ static int do_decrypt(struct skcipher_request *req, int err)
crypto_skcipher_decrypt(subreq) ?:
post_crypt(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY &&
- req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
}
diff --git a/crypto/rsa-pkcs1pad.c b/crypto/rsa-pkcs1pad.c
index 407c64b..2908f93 100644
--- a/crypto/rsa-pkcs1pad.c
+++ b/crypto/rsa-pkcs1pad.c
@@ -279,9 +279,7 @@ static int pkcs1pad_encrypt(struct akcipher_request *req)
req->dst, ctx->key_size - 1, req->dst_len);
err = crypto_akcipher_encrypt(&req_ctx->child_req);
- if (err != -EINPROGRESS &&
- (err != -EBUSY ||
- !(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err != -EINPROGRESS && err != -EBUSY)
return pkcs1pad_encrypt_sign_complete(req, err);
return err;
@@ -383,9 +381,7 @@ static int pkcs1pad_decrypt(struct akcipher_request *req)
ctx->key_size);
err = crypto_akcipher_decrypt(&req_ctx->child_req);
- if (err != -EINPROGRESS &&
- (err != -EBUSY ||
- !(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err != -EINPROGRESS && err != -EBUSY)
return pkcs1pad_decrypt_complete(req, err);
return err;
@@ -440,9 +436,7 @@ static int pkcs1pad_sign(struct akcipher_request *req)
req->dst, ctx->key_size - 1, req->dst_len);
err = crypto_akcipher_sign(&req_ctx->child_req);
- if (err != -EINPROGRESS &&
- (err != -EBUSY ||
- !(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err != -EINPROGRESS && err != -EBUSY)
return pkcs1pad_encrypt_sign_complete(req, err);
return err;
@@ -561,9 +555,7 @@ static int pkcs1pad_verify(struct akcipher_request *req)
ctx->key_size);
err = crypto_akcipher_verify(&req_ctx->child_req);
- if (err != -EINPROGRESS &&
- (err != -EBUSY ||
- !(req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ if (err != -EINPROGRESS && err != -EBUSY)
return pkcs1pad_verify_complete(req, err);
return err;
diff --git a/crypto/xts.c b/crypto/xts.c
index e31828e..f317c48 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -269,9 +269,7 @@ static int do_encrypt(struct skcipher_request *req, int err)
crypto_skcipher_encrypt(subreq) ?:
post_crypt(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY &&
- req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
}
@@ -321,9 +319,7 @@ static int do_decrypt(struct skcipher_request *req, int err)
crypto_skcipher_decrypt(subreq) ?:
post_crypt(req);
- if (err == -EINPROGRESS ||
- (err == -EBUSY &&
- req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (err == -EINPROGRESS || err == -EBUSY)
return err;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v9 03/20] net: use -EAGAIN for transient busy indication
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, Steve French,
Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyrings-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-fscrypt-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-ima-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-ima-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-security-module-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1508059209-25529-1-git-send-email-gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
Replace -EBUSY with -EAGAIN when handling transient busy
indication in the absence of backlog.
Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
---
Please squash this patch with the previous one when merging upstream.
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv6/ah6.c | 2 +-
net/ipv6/esp6.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 37db44f..049cb0a 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -240,7 +240,7 @@ static int ah_output(struct xfrm_state *x, struct sk_buff *skb)
if (err == -EINPROGRESS)
goto out;
- if (err == -EBUSY)
+ if (err == -EAGAIN)
err = NET_XMIT_DROP;
goto out_free;
}
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index b00e4a4..ff8e088 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -432,7 +432,7 @@ int esp_output_tail(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *
case -EINPROGRESS:
goto error;
- case -EBUSY:
+ case -EAGAIN:
err = NET_XMIT_DROP;
break;
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 7802b72..ba0c145 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -443,7 +443,7 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff *skb)
if (err == -EINPROGRESS)
goto out;
- if (err == -EBUSY)
+ if (err == -EAGAIN)
err = NET_XMIT_DROP;
goto out_free;
}
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 89910e2..1a71ee5 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -396,7 +396,7 @@ int esp6_output_tail(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
case -EINPROGRESS:
goto error;
- case -EBUSY:
+ case -EAGAIN:
err = NET_XMIT_DROP;
break;
--
2.7.4
^ permalink raw reply related
* [PATCH v9 02/20] crypto: ccp: use -EAGAIN for transient busy indication
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
In-Reply-To: <1508059209-25529-1-git-send-email-gilad@benyossef.com>
Replace -EBUSY with -EAGAIN when reporting transient busy
indication in the absence of backlog.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Reviewed-by: Gary R Hook <gary.hook@amd.com>
---
Please squash this patch with the previous one when merging upstream.
drivers/crypto/ccp/ccp-crypto-main.c | 8 +++-----
drivers/crypto/ccp/ccp-dev.c | 7 +++++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c b/drivers/crypto/ccp/ccp-crypto-main.c
index 35a9de7..403ff0a 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -222,9 +222,10 @@ static int ccp_crypto_enqueue_cmd(struct ccp_crypto_cmd *crypto_cmd)
/* Check if the cmd can/should be queued */
if (req_queue.cmd_count >= CCP_CRYPTO_MAX_QLEN) {
- ret = -EBUSY;
- if (!(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG))
+ if (!(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG)) {
+ ret = -EAGAIN;
goto e_lock;
+ }
}
/* Look for an entry with the same tfm. If there is a cmd
@@ -243,9 +244,6 @@ static int ccp_crypto_enqueue_cmd(struct ccp_crypto_cmd *crypto_cmd)
ret = ccp_enqueue_cmd(crypto_cmd->cmd);
if (!ccp_crypto_success(ret))
goto e_lock; /* Error, don't queue it */
- if ((ret == -EBUSY) &&
- !(crypto_cmd->cmd->flags & CCP_CMD_MAY_BACKLOG))
- goto e_lock; /* Not backlogging, don't queue it */
}
if (req_queue.cmd_count >= CCP_CRYPTO_MAX_QLEN) {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 4e029b1..3d637e3 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -292,9 +292,12 @@ int ccp_enqueue_cmd(struct ccp_cmd *cmd)
i = ccp->cmd_q_count;
if (ccp->cmd_count >= MAX_CMD_QLEN) {
- ret = -EBUSY;
- if (cmd->flags & CCP_CMD_MAY_BACKLOG)
+ if (cmd->flags & CCP_CMD_MAY_BACKLOG) {
+ ret = -EBUSY;
list_add_tail(&cmd->entry, &ccp->backlog);
+ } else {
+ ret = -EAGAIN;
+ }
} else {
ret = -EINPROGRESS;
ccp->cmd_count++;
--
2.7.4
^ permalink raw reply related
* [PATCH v9 01/20] crypto: change transient busy return code to -EAGAIN
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, Steve French,
Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyrings-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-fscrypt-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-ima-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-ima-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-security-module-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1508059209-25529-1-git-send-email-gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
The crypto API was using the -EBUSY return value to indicate
both a hard failure to submit a crypto operation into a
transformation provider when the latter was busy and the backlog
mechanism was not enabled as well as a notification that the
operation was queued into the backlog when the backlog mechanism
was enabled.
Having the same return code indicate two very different conditions
depending on a flag is both error prone and requires extra runtime
check like the following to discern between the cases:
if (err == -EINPROGRESS ||
(err == -EBUSY && (ahash_request_flags(req) &
CRYPTO_TFM_REQ_MAY_BACKLOG)))
This patch changes the return code used to indicate a crypto op
failed due to the transformation provider being transiently busy
to -EAGAIN.
Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
---
crypto/algapi.c | 6 ++++--
crypto/cryptd.c | 4 +---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index aa699ff..916bee3 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -897,9 +897,11 @@ int crypto_enqueue_request(struct crypto_queue *queue,
int err = -EINPROGRESS;
if (unlikely(queue->qlen >= queue->max_qlen)) {
- err = -EBUSY;
- if (!(request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG))
+ if (!(request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)) {
+ err = -EAGAIN;
goto out;
+ }
+ err = -EBUSY;
if (queue->backlog == &queue->list)
queue->backlog = &request->list;
}
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 0508c48..d1dbdce 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -137,16 +137,14 @@ static int cryptd_enqueue_request(struct cryptd_queue *queue,
int cpu, err;
struct cryptd_cpu_queue *cpu_queue;
atomic_t *refcnt;
- bool may_backlog;
cpu = get_cpu();
cpu_queue = this_cpu_ptr(queue->cpu_queue);
err = crypto_enqueue_request(&cpu_queue->queue, request);
refcnt = crypto_tfm_ctx(request->tfm);
- may_backlog = request->flags & CRYPTO_TFM_REQ_MAY_BACKLOG;
- if (err == -EBUSY && !may_backlog)
+ if (err == -EAGAIN)
goto out_put_cpu;
queue_work_on(cpu, kcrypto_wq, &cpu_queue->work);
--
2.7.4
^ permalink raw reply related
* [PATCH v9 00/20] simplify crypto wait for async op
From: Gilad Ben-Yossef @ 2017-10-15 9:19 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet, David Howells,
Tom Lendacky, Gary Hook, Boris Brezillon, Arnaud Ebalard,
Matthias Brugger, Alasdair Kergon, Mike Snitzer, dm-devel,
Steve French, Theodore Y. Ts'o, Jaegeuk Kim, Steffen Klassert,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Mimi Zohar,
Dmitry Kasatkin <dmitry.ka
Cc: Ofir Drang, linux-crypto, linux-doc, linux-kernel, keyrings,
linux-arm-kernel, linux-mediatek, linux-cifs, samba-technical,
linux-fscrypt, netdev, linux-ima-devel, linux-ima-user,
linux-security-module
Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end.
This patch set simplifies this common use case in two ways:
First, by separating the return codes of the case where a
request is queued to a backlog due to the provider being
busy (-EBUSY) from the case the request has failed due
to the provider being busy and backlogging is not enabled
(-EAGAIN).
Next, this change is than built on to create a generic API
to wait for a async. crypto operation to complete.
The end result is a smaller code base and an API that is
easier to use and more difficult to get wrong.
The patch set was boot tested on x86_64 and arm64 which
at the very least tests the crypto users via testmgr and
tcrypt but I do note that I do not have access to some
of the HW whose drivers are modified nor do I claim I was
able to test all of the corner cases.
The patch set is based upon linux-next release tagged
next-20171013.
Changes from v8:
- Remove the translation of EAGAIN return code to the
previous return code of EBUSY for the user space
interface of algif as no one seems to rely on it as
requested by Herbert Xu.
Changes from v7:
- Turn -EBUSY to -EAGAIN also in crypto using net
code which I missed before, as has been pointed
out by Harsh Jain.
Changes from v6:
- Fix brown paper bag compile error on marvell/cesa
code.
Changes from v5:
- Remove redundant new line as spotted by Jonathan
Cameron.
- Reworded dm-verity change commit message to better
clarify potential issue averted by change as
pointed out by Mikulas Patocka.
Changes from v4:
- Rebase on top of latest algif changes from Stephan
Mueller.
- Fix typo in ccp patch title.
Changes from v3:
- Instead of changing the return code to indicate
backlog queueing, change the return code to indicate
transient busy state, as suggested by Herbert Xu.
Changes from v2:
- Patch title changed from "introduce crypto wait for
async op" to better reflect the current state.
- Rebase on top of latest linux-next.
- Add a new return code of -EIOCBQUEUED for backlog
queueing, as suggested by Herbert Xu.
- Transform more users to the new API.
- Update the drbg change to account for new init as
indicated by Stephan Muller.
Changes from v1:
- Address review comments from Eric Biggers.
- Separated out bug fixes of existing code and rebase
on top of that patch set.
- Rename 'ecr' to 'wait' in fscrypto code.
- Split patch introducing the new API from the change
moving over the algif code which it originated from
to the new API.
- Inline crypto_wait_req().
- Some code indentation fixes.
Gilad Ben-Yossef (20):
crypto: change transient busy return code to -EAGAIN
crypto: ccp: use -EAGAIN for transient busy indication
net: use -EAGAIN for transient busy indication
crypto: remove redundant backlog checks on EBUSY
crypto: marvell/cesa: remove redundant backlog checks on EBUSY
crypto: introduce crypto wait for async op
crypto: move algif to generic async completion
crypto: move pub key to generic async completion
crypto: move drbg to generic async completion
crypto: move gcm to generic async completion
crypto: move testmgr to generic async completion
fscrypt: move to generic async completion
dm: move dm-verity to generic async completion
cifs: move to generic async completion
ima: move to generic async completion
crypto: tcrypt: move to generic async completion
crypto: talitos: move to generic async completion
crypto: qce: move to generic async completion
crypto: mediatek: move to generic async completion
crypto: adapt api sample to use async. op wait
Documentation/crypto/api-samples.rst | 52 ++-------
crypto/af_alg.c | 27 -----
crypto/ahash.c | 12 +--
crypto/algapi.c | 6 +-
crypto/algif_aead.c | 8 +-
crypto/algif_hash.c | 30 +++---
crypto/algif_skcipher.c | 9 +-
crypto/api.c | 13 +++
crypto/asymmetric_keys/public_key.c | 28 +----
crypto/cryptd.c | 4 +-
crypto/cts.c | 6 +-
crypto/drbg.c | 36 ++-----
crypto/gcm.c | 32 ++----
crypto/lrw.c | 8 +-
crypto/rsa-pkcs1pad.c | 16 +--
crypto/tcrypt.c | 84 +++++----------
crypto/testmgr.c | 204 ++++++++++++-----------------------
crypto/xts.c | 8 +-
drivers/crypto/ccp/ccp-crypto-main.c | 8 +-
drivers/crypto/ccp/ccp-dev.c | 7 +-
drivers/crypto/marvell/cesa.c | 3 +-
drivers/crypto/marvell/cesa.h | 2 +-
drivers/crypto/mediatek/mtk-aes.c | 31 +-----
drivers/crypto/qce/sha.c | 30 +-----
drivers/crypto/talitos.c | 38 +------
drivers/md/dm-verity-target.c | 81 ++++----------
drivers/md/dm-verity.h | 5 -
fs/cifs/smb2ops.c | 30 +-----
fs/crypto/crypto.c | 28 +----
fs/crypto/fname.c | 36 ++-----
fs/crypto/fscrypt_private.h | 10 --
fs/crypto/keyinfo.c | 21 +---
include/crypto/drbg.h | 3 +-
include/crypto/if_alg.h | 15 +--
include/linux/crypto.h | 40 +++++++
net/ipv4/ah4.c | 2 +-
net/ipv4/esp4.c | 2 +-
net/ipv6/ah6.c | 2 +-
net/ipv6/esp6.c | 2 +-
security/integrity/ima/ima_crypto.c | 56 +++-------
40 files changed, 297 insertions(+), 738 deletions(-)
--
2.7.4
^ permalink raw reply
* RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
From: Yuval Mintz @ 2017-10-15 8:51 UTC (permalink / raw)
To: Yunsheng Lin, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
amritha.nambiar@intel.com
In-Reply-To: <AM0PR0502MB368336C6A93618A13ADBB68ABF4E0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
> > >> This patchset adds a new hardware offload type in mqprio before
> adding
> > >> mqprio hardware offload support in hns3 driver.
Apparently Dave has already accepted Amirtha's changes to mqprio:
https://marc.info/?l=linux-netdev&m=150803219824053&w=2
so I guess you need to revise your patchs to align to the new conventions.
> > >
> > > I think one of the biggest issues in tying this to DCB configuration is the
> > > non-immediate [and possibly non persistent] configuration.
> > >
> > > Scenario #1:
> > > User is configuring mqprio offloaded with 3 TCs while device is in willing
> > mode.
> > > Would you expect the driver to immediately respond with a success or
> > instead
> > > delay the return until the DCBx negotiation is complete and the
> operational
> > > num of TCs is actually 3?
> >
> > Well, when user requsts the mqprio offloaded by a hardware shared by
> DCB,
> > I expect
> > the user is not using the dcb tool.
> > If user is still using dcb tool, then result is undefined.
> >
> > The scenario you mention maybe can be enforced by setting willing to zero
> > when user
> > is requesting the mqprio offload, and restore the willing bit when unloaded
> > the mqprio
> > offload.
>
> Sounds a bit harsh but would probably work.
>
> > But I think the real issue is that dcb and mqprio shares the tc system in the
> > stack,
> > the problem may be better to be fixed in the stack rather than in the
> driver,
> > as you
> > suggested in the DCB patchset. What do you think?
>
> What did you have in mind?
>
> >
> > >
> > > Scenario #2:
> > > Assume user explicitly offloaded mqprio with 3 TCs, but now DCB
> > configuration
> > > has changed on the peer side and 4 TCs is the new negotiated operational
> > value.
> > > Your current driver logic would change the number of TCs underneath
> the
> > user
> > > configuration [and it would actually probably work due to mqprio being a
> > crappy
> > > qdisc]. But was that the user actual intention?
> > > [I think the likely answer in this scenario is 'yes' since the alternative is no
> > better.
> > > But I still thought it was worth mentioning]
> >
> > You are right, the problem also have something to do with mqprio and dcb
> > sharing
> > the tc in the stack.
> >
> > Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
> > queue has a default pfifo mqprio attached, after DCB changes the tc num
> to
> > 4,
> > using tc qdisc shows some queue does not have a default pfifo mqprio
> > attached.
>
> Really? Then what did it show?
> [I assume it has some pfifo attached, and it's an mqprio dump kind of an
> issue]
>
> >
> > Maybe we can add a callback to notify mqprio the configuration has
> changed.
> >
>
> Which would do what?
> You already have the notifications available for monitoring using dcbnl logic if
> the
> configuration change [for user]; So user can re-configure whatever it wants.
> But other than dropping all the qdisc configurations and going back to the
> default
> qdiscs, what default action would mqprio be able to do when configuration
> changes
> that actually makes sense?
>
> > Thanks
> > Yunsheng Lin
> >
> > >
> > > Cheers,
> > > Yuval
> > >
> > >>
> > >> Yunsheng Lin (2):
> > >> mqprio: Add a new hardware offload type in mqprio
> > >> net: hns3: Add mqprio hardware offload support in hns3 driver
> > >>
> > >> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> > >> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
> > >> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> > ++++++++++++++-
> > >> -------
> > >> include/uapi/linux/pkt_sched.h | 1 +
> > >> 4 files changed, 55 insertions(+), 16 deletions(-)
> > >>
> > >> --
> > >> 1.9.1
> > >
> > >
> > >
^ permalink raw reply
* Re: [PATCH net-next 4/5] mlxsw: spectrum: router: Add support for address validator notifier
From: Ido Schimmel @ 2017-10-15 8:36 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <1507935733-18950-5-git-send-email-dsahern@gmail.com>
On Fri, Oct 13, 2017 at 04:02:12PM -0700, David Ahern wrote:
> Add support for inetaddr_validator and inet6addr_validator. The
> notifiers provide a means for validating ipv4 and ipv6 addresses
> before the addresses are installed and on failure the error
> is propagated back to the user.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: ipv6: Make inet6addr_validator a blocking notifier
From: Ido Schimmel @ 2017-10-15 7:53 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <1507935733-18950-3-git-send-email-dsahern@gmail.com>
On Fri, Oct 13, 2017 at 04:02:10PM -0700, David Ahern wrote:
> inet6addr_validator chain was added by commit 3ad7d2468f79f ("Ipvlan
> should return an error when an address is already in use") to allow
> address validation before changes are committed and to be able to
> fail the address change with an error back to the user. The address
> validation is not done for addresses received from router
> advertisements.
>
> Handling RAs in softirq context is the only reason for the notifier
> chain to be atomic versus blocking. Since the only current user, ipvlan,
> of the validator chain ignores softirq context, the notifier can be made
> blocking and simply not invoked for softirq path.
>
> The blocking option is needed by spectrum for example to validate
> resources for an adding an address to an interface.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Thanks for taking care of the in_softirq() check.
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/5] ipv6: addrconf: cleanup locking in ipv6_add_addr
From: Ido Schimmel @ 2017-10-15 7:50 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, jiri, idosch, kjlx, davem, yoshfuji
In-Reply-To: <1507935733-18950-2-git-send-email-dsahern@gmail.com>
On Fri, Oct 13, 2017 at 04:02:09PM -0700, David Ahern wrote:
> ipv6_add_addr is called in process context with rtnl lock held
> (e.g., manual config of an address) or during softirq processing
> (e.g., autoconf and address from a router advertisement).
>
> Currently, ipv6_add_addr calls rcu_read_lock_bh shortly after entry
> and does not call unlock until exit, minus the call around the address
> validator notifier. Similarly, addrconf_hash_lock is taken after the
> validator notifier and held until exit. This forces the allocation of
> inet6_ifaddr to always be atomic.
>
> Refactor ipv6_add_addr as follows:
> 1. add an input boolean to discriminate the call path (process context
> or softirq). This new flag controls whether the alloc can be done
> with GFP_KERNEL or GFP_ATOMIC.
>
> 2. Move the rcu_read_lock_bh and unlock calls only around functions that
> do rcu updates.
>
> 3. Remove the in6_dev_hold and put added by 3ad7d2468f79f ("Ipvlan should
> return an error when an address is already in use."). This was done
> presumably because rcu_read_unlock_bh needs to be called before calling
> the validator. Since rcu_read_lock is not needed before the validator
> runs revert the hold and put added by 3ad7d2468f79f and only do the
> hold when setting ifp->idev.
>
> 4. move duplicate address check and insertion of new address in the global
> address hash into a helper. The helper is called after an ifa is
> allocated and filled in.
>
> This allows the ifa for manually configured addresses to be done with
> GFP_KERNEL and reduces the overall amount of time with rcu_read_lock held
> and hash table spinlock held.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
[...]
> @@ -1073,21 +1085,19 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
>
> in6_ifa_hold(ifa);
> write_unlock(&idev->lock);
> -out2:
> +
> rcu_read_unlock_bh();
>
> - if (likely(err == 0))
> - inet6addr_notifier_call_chain(NETDEV_UP, ifa);
> - else {
> + inet6addr_notifier_call_chain(NETDEV_UP, ifa);
> +out:
> + if (unlikely(err < 0)) {
> + if (rt)
> + ip6_rt_put(rt);
I believe 'rt' needs to be set to NULL after addrconf_dst_alloc()
fails.
> kfree(ifa);
> - in6_dev_put(idev);
> ifa = ERR_PTR(err);
> }
>
> return ifa;
> -out:
> - spin_unlock(&addrconf_hash_lock);
> - goto out2;
> }
^ permalink raw reply
* Re: [patch net-next 06/34] net: core: use dev->ingress_queue instead of tp->q
From: Jiri Pirko @ 2017-10-15 6:45 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, jeffrey.t.kirsher, saeedm,
matanb, leonro, idosch, jakub.kicinski, ast, simon.horman,
pieter.jansenvanvuuren, john.hurley, edumazet, dsahern,
alexander.h.duyck, john.fastabend, willemb
In-Reply-To: <59E29B5E.9000304@iogearbox.net>
Sun, Oct 15, 2017 at 01:18:54AM CEST, daniel@iogearbox.net wrote:
>On 10/13/2017 08:30 AM, Jiri Pirko wrote:
>> Thu, Oct 12, 2017 at 11:45:43PM CEST, daniel@iogearbox.net wrote:
>> > On 10/12/2017 07:17 PM, Jiri Pirko wrote:
>> > > From: Jiri Pirko <jiri@mellanox.com>
>> > >
>> > > In sch_handle_egress and sch_handle_ingress, don't use tp->q and use
>> > > dev->ingress_queue which stores the same pointer instead.
>> > >
>> > > Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> > > ---
>> > > net/core/dev.c | 21 +++++++++++++++------
>> > > 1 file changed, 15 insertions(+), 6 deletions(-)
>> > >
>> > > diff --git a/net/core/dev.c b/net/core/dev.c
>> > > index fcddccb..cb9e5e5 100644
>> > > --- a/net/core/dev.c
>> > > +++ b/net/core/dev.c
>> > > @@ -3273,14 +3273,18 @@ EXPORT_SYMBOL(dev_loopback_xmit);
>> > > static struct sk_buff *
>> > > sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
>> > > {
>> > > + struct netdev_queue *netdev_queue =
>> > > + rcu_dereference_bh(dev->ingress_queue);
>> > > struct tcf_proto *cl = rcu_dereference_bh(dev->egress_cl_list);
>> > > struct tcf_result cl_res;
>> > > + struct Qdisc *q;
>> > >
>> > > - if (!cl)
>> > > + if (!cl || !netdev_queue)
>> > > return skb;
>> > > + q = netdev_queue->qdisc;
>> >
>> > NAK, no additional overhead in the software fast-path of
>> > sch_handle_{ingress,egress}() like this. There are users out there
>> > that use tc in software only, so performance is critical here.
>>
>> Okay, how else do you suggest I can avoid the need to use tp->q?
>> I was thinking about storing q directly to net_device, which would safe
>> one dereference, resulting in the same amount as current cl->q.
>
>Sorry for late reply, mostly off for few days. netdev struct has different
>cachelines which are hot on rx and tx (see also the location of the two
>lists, ingress_cl_list and egress_cl_list), if you add only one qdisc
>pointer there, then you'd at least penalize one of the two w/ potential
>cache miss. Can we leave it in cl?
Well that is the whole point of this excercise, to remove it from cl.
The thing is, for the shared blocks, cls are shared between multiple
qdisc instances, so cl->q makes no longer any sense.
^ permalink raw reply
* Re: [pull request][for-next 00/12] Mellanox, mlx5 IPoIB Muli Pkey support 2017-10-11
From: Leon Romanovsky @ 2017-10-15 6:30 UTC (permalink / raw)
To: Doug Ledford; +Cc: Saeed Mahameed, David S. Miller, netdev, linux-rdma
In-Reply-To: <af28440c-bb1c-c47b-92dd-60bfbeaa839d@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Sat, Oct 14, 2017 at 05:19:34PM -0400, Doug Ledford wrote:
> On 10/14/2017 2:48 PM, Saeed Mahameed wrote:
> > Hi Dave and Doug,
> >
> > This series includes updates for mlx5 IPoIB offloading driver from Alex
> > and Feras to add the support for Muli Pkey in the mlx5i ipoib offloading netdev,
> > to be merged into net-next and rdma-next trees.
>
> As far as the two IPoIB patches are concerned, they're fine.
>
> > Doug, I am sorry I couldn't base this on rc2 since the series needs and conflicts
> > with a fix that was submitted to rc3, so to keep things simple I based it on rc4,
> > I hope this is ok with you..
>
> No worries, it just means I have to submit it under another branch. But
> I'm already holding one patch series in a stand alone branch, so no big
> deal. And, actually, the IPoIB changes are so small they can simply go
> through Dave's tree if you don't have any dependent code in the IPoIB
> driver to submit after this but still in this devel cycle.
I have IPoIB NAPI implementation waiting for this shared code.
Thanks
>
> > Please pull and let me know if there's any problem.
>
> Once I hear that Dave is OK with the net changes, I'm ready to pull (if
> I need to).
>
> --
> Doug Ledford <dledford@redhat.com>
> GPG Key ID: B826A3330E572FDD
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
From: Yuval Mintz @ 2017-10-15 5:14 UTC (permalink / raw)
To: Yunsheng Lin, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5c268e80-3b04-28bd-26fb-d77f2edd69a8@huawei.com>
> Hi, Yuval
>
> On 2017/10/13 4:21, Yuval Mintz wrote:
> >> This patchset adds a new hardware offload type in mqprio before adding
> >> mqprio hardware offload support in hns3 driver.
> >
> > I think one of the biggest issues in tying this to DCB configuration is the
> > non-immediate [and possibly non persistent] configuration.
> >
> > Scenario #1:
> > User is configuring mqprio offloaded with 3 TCs while device is in willing
> mode.
> > Would you expect the driver to immediately respond with a success or
> instead
> > delay the return until the DCBx negotiation is complete and the operational
> > num of TCs is actually 3?
>
> Well, when user requsts the mqprio offloaded by a hardware shared by DCB,
> I expect
> the user is not using the dcb tool.
> If user is still using dcb tool, then result is undefined.
>
> The scenario you mention maybe can be enforced by setting willing to zero
> when user
> is requesting the mqprio offload, and restore the willing bit when unloaded
> the mqprio
> offload.
Sounds a bit harsh but would probably work.
> But I think the real issue is that dcb and mqprio shares the tc system in the
> stack,
> the problem may be better to be fixed in the stack rather than in the driver,
> as you
> suggested in the DCB patchset. What do you think?
What did you have in mind?
>
> >
> > Scenario #2:
> > Assume user explicitly offloaded mqprio with 3 TCs, but now DCB
> configuration
> > has changed on the peer side and 4 TCs is the new negotiated operational
> value.
> > Your current driver logic would change the number of TCs underneath the
> user
> > configuration [and it would actually probably work due to mqprio being a
> crappy
> > qdisc]. But was that the user actual intention?
> > [I think the likely answer in this scenario is 'yes' since the alternative is no
> better.
> > But I still thought it was worth mentioning]
>
> You are right, the problem also have something to do with mqprio and dcb
> sharing
> the tc in the stack.
>
> Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
> queue has a default pfifo mqprio attached, after DCB changes the tc num to
> 4,
> using tc qdisc shows some queue does not have a default pfifo mqprio
> attached.
Really? Then what did it show?
[I assume it has some pfifo attached, and it's an mqprio dump kind of an issue]
>
> Maybe we can add a callback to notify mqprio the configuration has changed.
>
Which would do what?
You already have the notifications available for monitoring using dcbnl logic if the
configuration change [for user]; So user can re-configure whatever it wants.
But other than dropping all the qdisc configurations and going back to the default
qdiscs, what default action would mqprio be able to do when configuration changes
that actually makes sense?
> Thanks
> Yunsheng Lin
>
> >
> > Cheers,
> > Yuval
> >
> >>
> >> Yunsheng Lin (2):
> >> mqprio: Add a new hardware offload type in mqprio
> >> net: hns3: Add mqprio hardware offload support in hns3 driver
> >>
> >> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
> >> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
> >> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46
> ++++++++++++++-
> >> -------
> >> include/uapi/linux/pkt_sched.h | 1 +
> >> 4 files changed, 55 insertions(+), 16 deletions(-)
> >>
> >> --
> >> 1.9.1
> >
> >
> >
^ permalink raw reply
* Re: [net-next 3/3] tcp: keep tcp_collapse controllable even after processing starts
From: Koichiro Den @ 2017-10-15 2:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995970.31614.59.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:46 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Combining actual collapsing with reasoning for deciding the starting
> > point, we can apply its logic in a consistent manner such that we can
> > avoid costly yet not much useful collapsing. When collapsing to be
> > triggered, it's not rare that most of the skbs in the receive or ooo
> > queue are large ones without much metadata overhead. This also
> > simplifies code and makes it easier to apply logic in a fair manner.
> >
> > Subtle subsidiary changes included:
> > - When the end_seq of the skb we are trying to collapse was larger than
> > the 'end' argument provided, we would end up copying to the 'end'
> > even though we couldn't collapse the original one. Current users of
> > tcp_collapse does not require such reserves so redefines it as the
> > point over which skbs whose seq passes guranteed not to be collapsed.
> > - Naturally tcp_collapse_ofo_queue shapes up and we no longer need
> > 'tail' argument.
>
>
> I am not inclined to review such a large change, without you providing
> actual numbers.
>
> We have a problem in TCP right now, that receiver announces a too big
> window, and that is the main reason we trigger collapsing.
>
> I would rather fix the root cause.
>
>
Ok I got it, thank you.
^ permalink raw reply
* Re: [net-next 2/3] tcp: do not tcp_collapse once SYN or FIN found
From: Koichiro Den @ 2017-10-15 2:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995823.31614.57.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:43 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > Since 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
> > applied, we no longer need to continue to search for the starting
> > point once we encounter FIN packet. Same reasoning for SYN packet
> > since commit 9d691539eea2d ("tcp: do not enqueue skb with SYN flag"),
> > that would help us with error message when actual receiving.
>
> Very confusing changelog or patch.
>
> What exact problem do you want to solve ?
>
>
That I thought as unnecessary search for the starting point. I am going to re-
read all to correct my misunderstanding.
Thank you.
^ permalink raw reply
* Re: [net-next 1/3] tcp: avoid useless copying and collapsing of just one skb
From: Koichiro Den @ 2017-10-15 2:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, kuznet, yoshfuji
In-Reply-To: <1507995761.31614.56.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, 2017-10-14 at 08:42 -0700, Eric Dumazet wrote:
> On Sat, 2017-10-14 at 16:27 +0900, Koichiro Den wrote:
> > On the starting point chosen, it could be possible that just one skb
> > remains in between the range provided, leading to copying and re-insertion
> > of rb node, which is useless with respect to the rcv buf measurement.
> > This is rather probable in ooo queue case, in which non-contiguous bloated
> > packets have been queued up.
> >
> > Signed-off-by: Koichiro Den <den@klaipeden.com>
> > ---
> > net/ipv4/tcp_input.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> > index d0682ce2a5d6..1d785b5bf62d 100644
> > --- a/net/ipv4/tcp_input.c
> > +++ b/net/ipv4/tcp_input.c
> > @@ -4807,7 +4807,8 @@ tcp_collapse(struct sock *sk, struct sk_buff_head
> > *list, struct rb_root *root,
> > start = TCP_SKB_CB(skb)->end_seq;
> > }
> > if (end_of_skbs ||
> > - (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)))
> > + (TCP_SKB_CB(skb)->tcp_flags & (TCPHDR_SYN | TCPHDR_FIN)) ||
> > + (TCP_SKB_CB(skb)->seq == start && TCP_SKB_CB(skb)->end_seq ==
> > end))
> > return;
> >
> > __skb_queue_head_init(&tmp);
>
>
> What do you mean by useless ?
>
> Surely if this skb contains 17 segments (some USB drivers allocate 8KB
> per frame), we want to collapse them to save memory.
>
> So I do not agree with this patch.
>
>
I missed that, and sorry about bothering with all, I totally misunderstood it.
Thank you for all of them.
^ permalink raw reply
* [PATCH] rtlwifi: Fix typo in if ... else if ... else construct
From: Larry Finger @ 2017-10-15 1:58 UTC (permalink / raw)
To: gregkh
Cc: netdev, devel, Larry Finger, Ping-Ke Shih, Yan-Hsuan Chuang,
Birming Chiu, Shaofu, Steven Ting, kbuild-all, Julia Lawall
The kbuild test robot reports two conditions with no effect (if == else).
These are the result of copy and paste typographical errors.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: kbuild-all@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
drivers/staging/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index b88b0e8edd3d..1a0331cf63ee 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c
@@ -920,7 +920,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x000c) >> 2 ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_2SS_MCS9];
@@ -932,7 +932,7 @@ static u8 _rtl_get_vht_highest_n_rate(struct ieee80211_hw *hw,
else if ((tx_mcs_map & 0x0003) ==
IEEE80211_VHT_MCS_SUPPORT_0_8)
hw_rate =
- rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
+ rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS8];
else
hw_rate =
rtlpriv->cfg->maps[RTL_RC_VHT_RATE_1SS_MCS9];
--
2.12.3
^ permalink raw reply related
* Re: [PATCH net 0/6] bnxt_en: bug fixes.
From: David Miller @ 2017-10-15 1:52 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1507943374-13308-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 13 Oct 2017 21:09:28 -0400
> Various bug fixes for the VF/PF link change logic, VF resource checking,
> potential firmware response corruption on NVRAM and DCB parameters,
> and reading the wrong register for PCIe link speed on the VF.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next 0/9][pull request] 40GbE Intel Wired LAN Driver Updates 2017-10-13
From: David Miller @ 2017-10-15 1:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20171013215249.61286-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Oct 2017 14:52:40 -0700
> This series contains updates to mqprio and i40e.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] tc-testing: Test suite updates
From: David Miller @ 2017-10-15 1:48 UTC (permalink / raw)
To: lucasb; +Cc: netdev, xiyou.wangcong, jiri, jhs, aring, mrv
In-Reply-To: <1507931485-1814-1-git-send-email-lucasb@mojatatu.com>
From: Lucas Bates <lucasb@mojatatu.com>
Date: Fri, 13 Oct 2017 17:51:21 -0400
> This patch series is a roundup of changes to the tc-testing
> suite:
>
> - Add test cases for police and mirred modules and some coverage
> in already-submitted test categories
> - Break the test case files down into more user-friendly sizes
> - Bug fix to the tdc.py script's handling of the -l argument
>
> v2: fix the lack of final newlines in two new files (thanks David)
Series applied, thanks for fixing that up.
^ permalink raw reply
* Re: [net-next PATCH 0/2] Minor macvlan source mode cleanups
From: David Miller @ 2017-10-15 1:46 UTC (permalink / raw)
To: alexander.duyck; +Cc: netdev
In-Reply-To: <20171013203726.16950.32584.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 13 Oct 2017 13:40:18 -0700
> So this patch series is just a few minor cleanups for macvlan source mode.
> The first patch addresses double receives when a packet is being routed to
> the macvlan destination address, and the other addresses the pkt_type being
> updated in cases where it most likely should not be.
Series applied, thanks.
^ permalink raw reply
* Re: [Patch net-next v3] tcp: add a tracepoint for tcp retransmission
From: David Miller @ 2017-10-15 1:45 UTC (permalink / raw)
To: xiyou.wangcong
Cc: netdev, edumazet, alexei.starovoitov, hannes, brendan.d.gregg,
ncardwell
In-Reply-To: <20171013200316.28561-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Oct 2017 13:03:16 -0700
> We need a real-time notification for tcp retransmission
> for monitoring.
>
> Of course we could use ftrace to dynamically instrument this
> kernel function too, however we can't retrieve the connection
> information at the same time, for example perf-tools [1] reads
> /proc/net/tcp for socket details, which is slow when we have
> a lots of connections.
>
> Therefore, this patch adds a tracepoint for __tcp_retransmit_skb()
> and exposes src/dst IP addresses and ports of the connection.
> This also makes it easier to integrate into perf.
>
> Note, I expose both IPv4 and IPv6 addresses at the same time:
> for a IPv4 socket, v4 mapped address is used as IPv6 addresses,
> for a IPv6 socket, LOOPBACK4_IPV6 is already filled by kernel.
> Also, add sk and skb pointers as they are useful for BPF.
>
> 1. https://github.com/brendangregg/perf-tools/blob/master/net/tcpretrans
>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix a compile warning in act_ife
From: David Miller @ 2017-10-15 1:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, mrv
In-Reply-To: <20171013195813.25321-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 13 Oct 2017 12:58:13 -0700
> Apparently ife_meta_id2name() is only called when
> CONFIG_MODULES is defined.
>
> This fixes:
>
> net/sched/act_ife.c:251:20: warning: ‘ife_meta_id2name’ defined but not used [-Wunused-function]
> static const char *ife_meta_id2name(u32 metaid)
> ^~~~~~~~~~~~~~~~
>
> Fixes: d3f24ba895f0 ("net sched actions: fix module auto-loading")
> Cc: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next,0/3] Add init of send table and var renames
From: David Miller @ 2017-10-15 1:43 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, sthemmin, olaf, vkuznets, linux-kernel
In-Reply-To: <20171013192805.18183-1-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 13 Oct 2017 12:28:02 -0700
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> Add initialization of send indirection table. Otherwise it may contain
> old info of previous device with different number of channels.
>
> Also, did some variable renaming for easier reading.
Series applied, thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox