All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Kagan <rvkagan@yandex-team.ru>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	"Raphael Norwitz" <raphael.norwitz@nutanix.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	yc-core@yandex-team.ru,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH 00/10] vhost: stick to -errno error return convention
Date: Tue, 30 Nov 2021 00:44:17 +0300	[thread overview]
Message-ID: <YaVJsSAPeKj2H97D@rvkaganb.lan> (raw)
In-Reply-To: <20211128164607-mutt-send-email-mst@kernel.org>

On Sun, Nov 28, 2021 at 04:47:20PM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 11, 2021 at 06:33:44PM +0300, Roman Kagan wrote:
> > Error propagation between the generic vhost code and the specific backends is
> > not quite consistent: some places follow "return -1 and set errno" convention,
> > while others assume "return negated errno".  Furthermore, not enough care is
> > taken not to clobber errno.
> > 
> > As a result, on certain code paths the errno resulting from a failure may get
> > overridden by another function call, and then that zero errno inidicating
> > success is propagated up the stack, leading to failures being lost.  In
> > particular, we've seen errors in the communication with a vhost-user-blk slave
> > not trigger an immediate connection drop and reconnection, leaving it in a
> > broken state.
> > 
> > Rework error propagation to always return negated errno on errors and
> > correctly pass it up the stack.
> 
> Hi Roman,
> if there are bugfixes here I'll be happy to take them right now.
> The wholesale rework seems inappropriate for 6.2, I'll be
> happy to tag it for after 6.2. Pls ping me aftre release to help
> make sure it's not lost.

All these patches are bugfixes in one way or another.  That said, none
of the problems being addressed are recent regressions.  OTOH the
patches introduce non-zero churn and change behavior on some error
paths, so I'd suggest to postpone the whole series till after 6.2 is
out.

Thanks,
Roman.


  reply	other threads:[~2021-11-29 21:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 15:33 [PATCH 00/10] vhost: stick to -errno error return convention Roman Kagan
2021-11-11 15:33 ` [PATCH 01/10] vhost-user-blk: reconnect on any error during realize Roman Kagan
2021-11-11 17:52   ` Kevin Wolf
2021-11-12  7:39     ` Roman Kagan
2021-11-12 11:37       ` Kevin Wolf
2021-11-12 19:59         ` Roman Kagan
2021-11-29 22:15           ` Raphael Norwitz
2021-11-29 22:17   ` Raphael Norwitz
2021-11-11 15:33 ` [PATCH 02/10] chardev/char-socket: tcp_chr_recv: don't clobber errno Roman Kagan
2021-11-12  8:27   ` Marc-André Lureau
2021-11-11 15:33 ` [PATCH 03/10] chardev/char-socket: tcp_chr_sync_read: " Roman Kagan
2021-11-12  8:28   ` Marc-André Lureau
2021-11-11 15:33 ` [PATCH 04/10] chardev/char-fe: don't allow EAGAIN from blocking read Roman Kagan
2021-11-12  8:24   ` Marc-André Lureau
2021-11-12 19:04     ` Roman Kagan
2021-11-11 15:33 ` [PATCH 05/10] vhost-backend: avoid overflow on memslots_limit Roman Kagan
2021-11-11 17:59   ` Philippe Mathieu-Daudé
2021-11-12  7:46     ` Roman Kagan
2021-11-12  9:56       ` Daniel P. Berrangé
2021-11-12 11:10         ` Roman Kagan
2021-11-11 15:33 ` [PATCH 06/10] vhost-backend: stick to -errno error return convention Roman Kagan
2021-11-11 18:00   ` Philippe Mathieu-Daudé
2021-11-11 15:33 ` [PATCH 07/10] vhost-vdpa: " Roman Kagan
2021-11-11 15:33 ` [PATCH 08/10] vhost-user: " Roman Kagan
2021-11-11 15:33 ` [PATCH 09/10] vhost: " Roman Kagan
2021-11-11 15:33 ` [PATCH 10/10] vhost-user-blk: propagate error return from generic vhost Roman Kagan
2021-11-29 22:37   ` Raphael Norwitz
2021-11-11 20:14 ` [PATCH 00/10] vhost: stick to -errno error return convention Michael S. Tsirkin
2021-11-12  8:04   ` Roman Kagan
2021-11-28 21:47 ` Michael S. Tsirkin
2021-11-29 21:44   ` Roman Kagan [this message]
2022-01-06  9:57 ` Michael S. Tsirkin

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=YaVJsSAPeKj2H97D@rvkaganb.lan \
    --to=rvkagan@yandex-team.ru \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=yc-core@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.