On Tue, 28 May 2024 12:45:32 -0400, "Michael S. Tsirkin"
wrote:
> On Wed, May 29, 2024 at 12:01:45AM +0800, Heng Qi wrote:
> > On Tue, 28 May 2024 11:46:28 -0400, "Michael S. Tsirkin"
> > wrote:
> > > On Tue, May 28, 2024 at 03:52:26PM +0800, Heng Qi wrote:
> > > > Refactored the handling of co
On Wed, May 29, 2024 at 12:01:45AM +0800, Heng Qi wrote:
> On Tue, 28 May 2024 11:46:28 -0400, "Michael S. Tsirkin"
> wrote:
> > On Tue, May 28, 2024 at 03:52:26PM +0800, Heng Qi wrote:
> > > Refactored the handling of control_buf to be within the cvq_lock
> > > critical section, mitigating race
On Tue, May 28, 2024 at 5:53 PM Stefano Garzarella wrote:
>
> On Tue, May 28, 2024 at 05:49:32PM GMT, Paolo Bonzini wrote:
> >On Tue, May 28, 2024 at 5:41 PM Stefano Garzarella
> >wrote:
> >> >I think it's either that or implementing virtio-vsock in userspace
> >> >(https://lore.kernel.org/qemu-
On Tue, 28 May 2024 11:46:28 -0400, "Michael S. Tsirkin"
wrote:
> On Tue, May 28, 2024 at 03:52:26PM +0800, Heng Qi wrote:
> > Refactored the handling of control_buf to be within the cvq_lock
> > critical section, mitigating race conditions between reading device
> > responses and new command sub
On Tue, May 28, 2024 at 05:49:32PM GMT, Paolo Bonzini wrote:
On Tue, May 28, 2024 at 5:41 PM Stefano Garzarella wrote:
>I think it's either that or implementing virtio-vsock in userspace
>(https://lore.kernel.org/qemu-devel/30baeb56-64d2-4ea3-8e53-6a5c50999...@redhat.com/,
>search for "To conne
On Tue, May 28, 2024 at 5:41 PM Stefano Garzarella wrote:
> >I think it's either that or implementing virtio-vsock in userspace
> >(https://lore.kernel.org/qemu-devel/30baeb56-64d2-4ea3-8e53-6a5c50999...@redhat.com/,
> >search for "To connect host<->guest").
>
> For in this case AF_VSOCK can't be
On Tue, May 28, 2024 at 03:52:26PM +0800, Heng Qi wrote:
> Refactored the handling of control_buf to be within the cvq_lock
> critical section, mitigating race conditions between reading device
> responses and new command submissions.
>
> Fixes: 6f45ab3e0409 ("virtio_net: Add a lock for the comman
On Tue, May 28, 2024 at 05:19:34PM GMT, Paolo Bonzini wrote:
On 5/27/24 09:54, Alexander Graf wrote:
On 27.05.24 09:08, Alexander Graf wrote:
Hey Stefano,
On 23.05.24 10:45, Stefano Garzarella wrote:
On Tue, May 21, 2024 at 08:50:22AM GMT, Alexander Graf wrote:
Howdy,
On 20.05.24 14:44, Do
On 5/27/24 09:54, Alexander Graf wrote:
On 27.05.24 09:08, Alexander Graf wrote:
Hey Stefano,
On 23.05.24 10:45, Stefano Garzarella wrote:
On Tue, May 21, 2024 at 08:50:22AM GMT, Alexander Graf wrote:
Howdy,
On 20.05.24 14:44, Dorjoy Chowdhury wrote:
Hey Stefano,
Thanks for the reply.
O
On Mon, May 27, 2024 at 09:54:17AM GMT, Alexander Graf wrote:
On 27.05.24 09:08, Alexander Graf wrote:
Hey Stefano,
On 23.05.24 10:45, Stefano Garzarella wrote:
On Tue, May 21, 2024 at 08:50:22AM GMT, Alexander Graf wrote:
Howdy,
On 20.05.24 14:44, Dorjoy Chowdhury wrote:
Hey Stefano,
Tha
When the following snippet is run, lockdep will report a deadlock[1].
/* Acquire all queues dim_locks */
for (i = 0; i < vi->max_queue_pairs; i++)
mutex_lock(&vi->rq[i].dim_lock);
There's no deadlock here because the vq locks are always taken
in the same order, but lockdep can not f
When the dim worker is scheduled, if it no longer needs to issue
commands, dim may not be able to return to the working state later.
For example, the following single queue scenario:
1. The dim worker of rxq0 is scheduled, and the dim status is
changed to DIM_APPLY_NEW_PROFILE;
2. dim is
Patch 1 describes and fixes an issue where dim cannot return to
normal state in certain scenarios.
Patch 2 attempts to resolve lockdep's complaints that holding many
nested locks.
Changelog
===
v2->v3:
Patch(2/2): Refactor code instead of revert the patch.
v1->v2:
Patch(2/2): rephase the
在 2024/5/28 下午6:04, Paolo Abeni 写道:
On Tue, 2024-05-28 at 11:06 +0800, Heng Qi wrote:
On Mon, 27 May 2024 12:42:43 +0200, Paolo Abeni wrote:
On Thu, 2024-05-23 at 15:46 +0800, Heng Qi wrote:
This reverts commit 4d4ac2ececd3c42a08dd32a6e3a4aaf25f7efe44.
When the following snippet is run, lo
On Tue, 2024-05-28 at 11:06 +0800, Heng Qi wrote:
> On Mon, 27 May 2024 12:42:43 +0200, Paolo Abeni wrote:
> > On Thu, 2024-05-23 at 15:46 +0800, Heng Qi wrote:
> > > This reverts commit 4d4ac2ececd3c42a08dd32a6e3a4aaf25f7efe44.
> > >
> > > When the following snippet is run, lockdep will report a
> Refactored the handling of control_buf to be within the cvq_lock critical
> section, mitigating race conditions between reading device responses and
> new command submissions.
>
> Fixes: 6f45ab3e0409 ("virtio_net: Add a lock for the command VQ.")
> Signed-off-by: Heng Qi
> ---
> drivers/net
> -Original Message-
> From: Heng Qi
> Sent: Tuesday, May 28, 2024 1:22 PM
> To: netdev@vger.kernel.org; virtualizat...@lists.linux.dev
> Cc: Michael S. Tsirkin ; Jason Wang
> ; Xuan Zhuo ;
> Eugenio Pérez ; David S. Miller
> ; Eric Dumazet ; Jakub
> Kicinski ; Paolo Abeni ; Jiri Pirko
The integer variable 'ret', denoting the return code, is mismatched with
the boolean return type of virtnet_send_command_reply(); hence, it is
renamed to 'err'.
The usage of 'ret' is deferred to the next patch.
Signed-off-by: Heng Qi
---
drivers/net/virtio_net.c | 8
1 file changed, 4
Patch 1 did a simple rename, leaving 'ret' for patch 2.
Patch 2 fixed a race between reading the device response and the
new command submission.
Heng Qi (2):
virtio_net: rename ret to err
virtio_net: fix missing lock protection on control_buf access
drivers/net/virtio_net.c | 12 +++-
Refactored the handling of control_buf to be within the cvq_lock
critical section, mitigating race conditions between reading device
responses and new command submissions.
Fixes: 6f45ab3e0409 ("virtio_net: Add a lock for the command VQ.")
Signed-off-by: Heng Qi
---
drivers/net/virtio_net.c | 4 +
20 matches
Mail list logo
