From patchwork Thu Nov 11 15:33:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roman Kagan X-Patchwork-Id: 12615205 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AA53C433F5 for ; Thu, 11 Nov 2021 15:37:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3472F60F4B for ; Thu, 11 Nov 2021 15:37:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3472F60F4B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex-team.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:37100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlC93-0002x7-B2 for qemu-devel@archiver.kernel.org; Thu, 11 Nov 2021 10:37:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40452) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlC5c-0004Rh-RM; Thu, 11 Nov 2021 10:34:13 -0500 Received: from forwardcorp1j.mail.yandex.net ([5.45.199.163]:40848) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlC5T-00040m-UG; Thu, 11 Nov 2021 10:34:07 -0500 Received: from iva8-d2cd82b7433e.qloud-c.yandex.net (iva8-d2cd82b7433e.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:a88e:0:640:d2cd:82b7]) by forwardcorp1j.mail.yandex.net (Yandex) with ESMTP id C8D812E1E9C; Thu, 11 Nov 2021 18:33:56 +0300 (MSK) Received: from iva8-3a65cceff156.qloud-c.yandex.net (iva8-3a65cceff156.qloud-c.yandex.net [2a02:6b8:c0c:2d80:0:640:3a65:ccef]) by iva8-d2cd82b7433e.qloud-c.yandex.net (mxbackcorp/Yandex) with ESMTP id OmDzIFb9ez-XtsS8QN1; Thu, 11 Nov 2021 18:33:56 +0300 Precedence: bulk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1636644836; bh=P415Pnp2Q53kRr3ekH8mFM4DFA8+5p2tUcDgCjtFogE=; h=Message-Id:Date:Subject:To:From:Cc; b=kOfAUcdL+dpyjYA29DeIn7C06gOAEc521VGnpLTFwCi1zLE0gOvICPli+XVfb0CB7 0XKkGklZS0XIdfiXmt2845FzfeNgTUDANdhlr9fWAwq77HWNuZLtOhWECXD59qpYAd Dy4KSoB+w7xHjsdJJ0rkfkOPIQ47hLoIB/3fJHrg= Authentication-Results: iva8-d2cd82b7433e.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from rvkaganb.lan (dynamic-vpn.dhcp.yndx.net [2a02:6b8:b081:8830::1:2d]) by iva8-3a65cceff156.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPS id WgGv8YbvMJ-XtwCqDe7; Thu, 11 Nov 2021 18:33:55 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) X-Yandex-Fwd: 2 From: Roman Kagan To: qemu-devel@nongnu.org Subject: [PATCH 00/10] vhost: stick to -errno error return convention Date: Thu, 11 Nov 2021 18:33:44 +0300 Message-Id: <20211111153354.18807-1-rvkagan@yandex-team.ru> X-Mailer: git-send-email 2.33.1 MIME-Version: 1.0 Received-SPF: pass client-ip=5.45.199.163; envelope-from=rvkagan@yandex-team.ru; helo=forwardcorp1j.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , qemu-block@nongnu.org, "Michael S. Tsirkin" , Raphael Norwitz , Hanna Reitz , yc-core@yandex-team.ru, =?utf-8?q?Marc-And?= =?utf-8?q?r=C3=A9_Lureau?= , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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. Roman Kagan (10): vhost-user-blk: reconnect on any error during realize chardev/char-socket: tcp_chr_recv: don't clobber errno chardev/char-socket: tcp_chr_sync_read: don't clobber errno chardev/char-fe: don't allow EAGAIN from blocking read vhost-backend: avoid overflow on memslots_limit vhost-backend: stick to -errno error return convention vhost-vdpa: stick to -errno error return convention vhost-user: stick to -errno error return convention vhost: stick to -errno error return convention vhost-user-blk: propagate error return from generic vhost chardev/char-fe.c | 7 +- chardev/char-socket.c | 17 +- hw/block/vhost-user-blk.c | 4 +- hw/virtio/vhost-backend.c | 4 +- hw/virtio/vhost-user.c | 401 +++++++++++++++++++++----------------- hw/virtio/vhost-vdpa.c | 37 ++-- hw/virtio/vhost.c | 98 +++++----- 7 files changed, 307 insertions(+), 261 deletions(-)