public inbox for virtualization@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: Nikolay Kuratov <kniv@yandex-team.ru>
Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux.dev,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Eugenio Peterz <eperezma@redhat.com>,
	Lei Yang <leiyang@redhat.com>
Subject: Re: [PATCH] vhost/net: Replace wait_queue with completion in ubufs reference
Date: Sat, 19 Jul 2025 06:11:36 +0800	[thread overview]
Message-ID: <20250718221137.2432-1-hdanton@sina.com> (raw)
In-Reply-To: <20250718132414.1572292-1-kniv@yandex-team.ru>

On Fri, 18 Jul 2025 16:24:14 +0300 Nikolay Kuratov wrote:
> > reinit after wait, so the chance for missing wakeup still exists.
> 
> Can you please provide more details on this? Yes, it is reinit after wait,

The missing wakeup exists if complete_all() is used in combination with
reinit after wait, with nothing to do with vhost.

Your patch was checked simply because of reinit, which hints the chance for
mess in mind without exception.

Of course feel free to prove that missing wakeup disappears in vhost
even if reinit is deployed.

> but wait should not be concurrent. I checked multiple code pathes towards
> vhost_net_flush(), they're all protected by device mutex, except
> vhost_net_release(). In case of vhost_net_release() - it would be a
> problem itself if it was called in parallel with some ioctl on a device?
> 
> Also rationale for this is that put_and_wait() is waiting for zero
> refcount condition. Zero refcount means that after put_and_wait() calling
> thread is the only owner of an ubufs structure. If multiple threads got
> ubufs structure with zero refcount - how either thread can be sure that
> another one is not free'ing it?
> 
> 

  reply	other threads:[~2025-07-18 22:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-18 11:03 [PATCH v2] vhost/net: Replace wait_queue with completion in ubufs reference Nikolay Kuratov
2025-07-18 12:46 ` Hillf Danton
2025-07-18 13:24   ` [PATCH] " Nikolay Kuratov
2025-07-18 22:11     ` Hillf Danton [this message]
2025-07-18 23:03 ` [PATCH v2] " Hillf Danton
2025-07-20 16:13   ` Michael S. Tsirkin
2025-07-21 14:52     ` Lei Yang
2025-08-05 10:02 ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2025-07-16 16:22 [PATCH] " Nikolay Kuratov
2025-07-18  8:31 ` Lei Yang
2025-07-18  9:07 ` Hillf Danton
2025-07-18  9:48   ` Nikolay Kuratov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250718221137.2432-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kniv@yandex-team.ru \
    --cc=leiyang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox