All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Guillaume Vincke <guillaume.vincke@ovhcloud.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	 Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
	Kevin Wolf <kwolf@redhat.com>, Hanna Reitz <hreitz@redhat.com>
Subject: Re: [PATCH v3 0/2] nbd/client-connection: Fix client returning a closed channel
Date: Fri, 6 Nov 2026 13:45:00 -0600	[thread overview]
Message-ID: <au4tsMuhKjq62dVB@redhat.com> (raw)
In-Reply-To: <20261105164124.249395-1-guillaume.vincke@ovhcloud.com>

On Thu, Nov 05, 2026 at 05:41:22PM +0100, Guillaume Vincke wrote:
> NBD client relies on lazy reconnection on error. There is a case where
> nbd_co_establish_connection() will hand back a channel disconnected by
> its peer. This leads to the request running on the dead channel. When
> reconnect-delay is set to 0 (the default), this bug prevents the
> nbd-connect thread from running on the first operation. This patch set
> addresses this specific case.
> 

> 
> v3 does not use a more robust method than sleeping to wait for the NBD
> client to reach the desired state. An option would be to add a QMP
> unstable debug query reporting the NBD client state and whether the
> connect thread has a channel ready. The test would poll this instead of
> sleeping. Would that be an acceptable follow-up?

I think an unstable query for current NBD server state (is the server
up, and if so, which exports is it serving and what is the state of
all client(s) attached to each server) would indeed make sense.  That
will probably miss this release, but I still think this series is okay
for now.  Queueing it up as a bug fix, for my upcoming pull request
intended to make it into rc0.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org



  parent reply	other threads:[~2026-11-06 19:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 16:41 [PATCH v3 0/2] nbd/client-connection: Fix client returning a closed channel Guillaume Vincke
2026-11-05 16:41 ` [PATCH v3 1/2] " Guillaume Vincke
2026-11-05 16:41 ` [PATCH v3 2/2] iotests: Add coverage for NBD connect thread start delay Guillaume Vincke
2026-11-10 16:38   ` Eric Blake
2026-11-06 19:45 ` Eric Blake [this message]
2026-11-09 16:25   ` [PATCH v3 0/2] nbd/client-connection: Fix client returning a closed channel guillaume vincke

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=au4tsMuhKjq62dVB@redhat.com \
    --to=eblake@redhat.com \
    --cc=guillaume.vincke@ovhcloud.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.