lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZtLaYFUKM9pPb5rF@visitorckw-System-Product-Name>
Date: Sat, 31 Aug 2024 16:54:56 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: Chenghai Huang <huangchenghai2@...wei.com>
Cc: herbert@...dor.apana.org.au, davem@...emloft.net,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	fanghao11@...wei.com, liulongfang@...wei.com, shenyang39@...wei.com,
	songzhiqi1@...wei.com, qianweili@...wei.com,
	linwenkai6@...ilicon.com, taoqi10@...wei.com,
	wangzhou1@...ilicon.com
Subject: Re: [PATCH 2/3] crypto: hisilicon - add a lock for the qp send
 operation

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@...wei.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
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ