在 2024/4/18 下午2:42, Jason Wang 写道:
On Wed, Apr 17, 2024 at 3:31 AM Daniel Jurgens <danielj@xxxxxxxxxx> wrote:
The command VQ will no longer be protected by the RTNL lock. Use a
spinlock to protect the control buffer header and the VQ.
Signed-off-by: Daniel Jurgens <danielj@xxxxxxxxxx>
Reviewed-by: Jiri Pirko <jiri@xxxxxxxxxx>
---
drivers/net/virtio_net.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0ee192b45e1e..d02f83a919a7 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -282,6 +282,7 @@ struct virtnet_info {
/* Has control virtqueue */
bool has_cvq;
+ spinlock_t cvq_lock;
Spinlock is instead of mutex which is problematic as there's no
guarantee on when the driver will get a reply. And it became even more
serious after 0d197a147164 ("virtio-net: add cond_resched() to the
command waiting loop").
Any reason we can't use mutex?
Hi Jason,
I made a patch set to enable ctrlq's irq on top of this patch set, which
removes cond_resched().
But I need a little time to test, this is close to fast. So could the
topic about cond_resched +
spin lock or mutex lock be wait?
Thank you very much!
Thanks
/* Host can handle any s/g split between our header and packet data */
bool any_header_sg;
@@ -2529,6 +2530,7 @@ static bool virtnet_send_command(struct virtnet_info *vi, u8 class, u8 cmd,
/* Caller should know better */
BUG_ON(!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ));
+ guard(spinlock)(&vi->cvq_lock);
vi->ctrl->status = ~0;
vi->ctrl->hdr.class = class;
vi->ctrl->hdr.cmd = cmd;
@@ -4818,8 +4820,10 @@ static int virtnet_probe(struct virtio_device *vdev)
virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
vi->any_header_sg = true;
- if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) {
vi->has_cvq = true;
+ spin_lock_init(&vi->cvq_lock);
+ }
if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
mtu = virtio_cread16(vdev,
--
2.34.1
