[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cd8131c3-9c6d-012a-465f-46f2477974c4@loongson.cn>
Date: Fri, 5 Dec 2025 09:56:26 +0800
From: Bibo Mao <maobibo@...ngson.cn>
To: Jason Wang <jasowang@...hat.com>
Cc: Gonglei <arei.gonglei@...wei.com>, "Michael S. Tsirkin" <mst@...hat.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
<eperezma@...hat.com>, Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
wangyangxin <wangyangxin1@...wei.com>, stable@...r.kernel.org,
virtualization@...ts.linux.dev, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/9] crypto: virtio: Add spinlock protection with
virtqueue notification
On 2025/12/5 上午9:21, Jason Wang wrote:
> On Thu, Dec 4, 2025 at 7:22 PM Bibo Mao <maobibo@...ngson.cn> wrote:
>>
>> When VM boots with one virtio-crypto PCI device and builtin backend,
>> run openssl benchmark command with multiple processes, such as
>> openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32
>>
>> openssl processes will hangup and there is error reported like this:
>> virtio_crypto virtio0: dataq.0:id 3 is not a head!
>>
>> It seems that the data virtqueue need protection when it is handled
>> for virtio done notification. If the spinlock protection is added
>> in virtcrypto_done_task(), openssl benchmark with multiple processes
>> works well.
>>
>> Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Bibo Mao <maobibo@...ngson.cn>
>> ---
>> drivers/crypto/virtio/virtio_crypto_core.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c
>> index 3d241446099c..ccc6b5c1b24b 100644
>> --- a/drivers/crypto/virtio/virtio_crypto_core.c
>> +++ b/drivers/crypto/virtio/virtio_crypto_core.c
>> @@ -75,15 +75,20 @@ static void virtcrypto_done_task(unsigned long data)
>> struct data_queue *data_vq = (struct data_queue *)data;
>> struct virtqueue *vq = data_vq->vq;
>> struct virtio_crypto_request *vc_req;
>> + unsigned long flags;
>> unsigned int len;
>>
>> + spin_lock_irqsave(&data_vq->lock, flags);
>> do {
>> virtqueue_disable_cb(vq);
>> while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) {
>> + spin_unlock_irqrestore(&data_vq->lock, flags);
>> if (vc_req->alg_cb)
>> vc_req->alg_cb(vc_req, len);
>> + spin_lock_irqsave(&data_vq->lock, flags);
>> }
>> } while (!virtqueue_enable_cb(vq));
>> + spin_unlock_irqrestore(&data_vq->lock, flags);
>> }
>
> Another thing that needs to care:
>
> There seems to be a redundant virtqueue_kick() in
> virtio_crypto_skcipher_crypt_req() which is out of the protection of
> the spinlock.
>
> I think we can simply remote that?
yes, there is redundant virtqueue_kick() in function
virtio_crypto_skcipher_crypt_req().
Will remove one in next version.
Regards
Bibo Mao
>
> Thanks
>
>>
>> static void virtcrypto_dataq_callback(struct virtqueue *vq)
>> --
>> 2.39.3
>>
Powered by blists - more mailing lists