Apply for a lock before the qp send operation to ensure no
resource competition in multi-concurrency situations.

This modification has almost no impact on performance.

Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
---
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 ++
 drivers/crypto/hisilicon/zip/zip_crypto.c   | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 764532a6ca82..c167dbd6c7d6 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -575,7 +575,9 @@ static int hpre_send(struct hpre_ctx *ctx, struct hpre_sqe *msg)
 
 	do {
 		atomic64_inc(&dfx[HPRE_SEND_CNT].value);
+		spin_lock_bh(&ctx->req_lock);
 		ret = hisi_qp_send(ctx->qp, msg);
+		spin_unlock_bh(&ctx->req_lock);
 		if (ret != -EBUSY)
 			break;
 		atomic64_inc(&dfx[HPRE_SEND_BUSY_CNT].value);
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c b/drivers/crypto/hisilicon/zip/zip_crypto.c
index 94e2d66b04b6..e3a31e3416be 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -213,6 +213,7 @@ static int hisi_zip_do_work(struct hisi_zip_qp_ctx *qp_ctx,
 {
 	struct hisi_acc_sgl_pool *pool = qp_ctx->sgl_pool;
 	struct hisi_zip_dfx *dfx = &qp_ctx->zip_dev->dfx;
+	struct hisi_zip_req_q *req_q = &qp_ctx->req_q;
 	struct acomp_req *a_req = req->req;
 	struct hisi_qp *qp = qp_ctx->qp;
 	struct device *dev = &qp->qm->pdev->dev;
@@ -244,7 +245,9 @@ static int hisi_zip_do_work(struct hisi_zip_qp_ctx *qp_ctx,
 
 	/* send command to start a task */
 	atomic64_inc(&dfx->send_cnt);
+	write_lock(&req_q->req_lock);
 	ret = hisi_qp_send(qp, &zip_sqe);
+	write_unlock(&req_q->req_lock);
 	if (unlikely(ret < 0)) {
 		atomic64_inc(&dfx->send_busy_cnt);
 		ret = -EAGAIN;
-- 
2.33.0

On Fri, Aug 30, 2024 at 06:17:17PM +0800, Chenghai Huang wrote:
> Apply for a lock before the qp send operation to ensure no
> resource competition in multi-concurrency situations.
> 
> This modification has almost no impact on performance.
> 
> Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
> ---
>  drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 ++
>  drivers/crypto/hisilicon/zip/zip_crypto.c   | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> index 764532a6ca82..c167dbd6c7d6 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> +++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> @@ -575,7 +575,9 @@ static int hpre_send(struct hpre_ctx *ctx, struct hpre_sqe *msg)
>  
>  	do {
>  		atomic64_inc(&dfx[HPRE_SEND_CNT].value);
> +		spin_lock_bh(&ctx->req_lock);
>  		ret = hisi_qp_send(ctx->qp, msg);
> +		spin_unlock_bh(&ctx->req_lock);
>  		if (ret != -EBUSY)
>  			break;
>  		atomic64_inc(&dfx[HPRE_SEND_BUSY_CNT].value);
> diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c b/drivers/crypto/hisilicon/zip/zip_crypto.c
> index 94e2d66b04b6..e3a31e3416be 100644
> --- a/drivers/crypto/hisilicon/zip/zip_crypto.c
> +++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
> @@ -213,6 +213,7 @@ static int hisi_zip_do_work(struct hisi_zip_qp_ctx *qp_ctx,
>  {
>  	struct hisi_acc_sgl_pool *pool = qp_ctx->sgl_pool;
>  	struct hisi_zip_dfx *dfx = &qp_ctx->zip_dev->dfx;
> +	struct hisi_zip_req_q *req_q = &qp_ctx->req_q;
>  	struct acomp_req *a_req = req->req;
>  	struct hisi_qp *qp = qp_ctx->qp;
>  	struct device *dev = &qp->qm->pdev->dev;
> @@ -244,7 +245,9 @@ static int hisi_zip_do_work(struct hisi_zip_qp_ctx *qp_ctx,
>  
>  	/* send command to start a task */
>  	atomic64_inc(&dfx->send_cnt);
> +	write_lock(&req_q->req_lock);
>  	ret = hisi_qp_send(qp, &zip_sqe);
> +	write_unlock(&req_q->req_lock);

Hi Chenghai,

Thanks for your patch. Since Herbert has already applied a patch [1]
changing rw_lock to spinlock in the hisilicon zip controller driver,
applying your patch might cause a conflict. Could you rebase on
Herbert's crypto tree and update write_lock() and write_unlock() to
spin_lock() and spin_unlock(), respectively?

[1]: https://lore.kernel.org/lkml/20240823183856.561166-1-visitorckw@gmail.com/

Regards,
Kuan-Wei

>  	if (unlikely(ret < 0)) {
>  		atomic64_inc(&dfx->send_busy_cnt);
>  		ret = -EAGAIN;
> -- 
> 2.33.0
> 
>