From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yqhxd-0002xv-Rw for qemu-devel@nongnu.org; Fri, 08 May 2015 09:05:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yqhxa-0007cY-IV for qemu-devel@nongnu.org; Fri, 08 May 2015 09:05:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yqhxa-0007cN-AP for qemu-devel@nongnu.org; Fri, 08 May 2015 09:04:58 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t48D4vJu020259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 8 May 2015 09:04:57 -0400 Message-ID: <554CB475.4030806@redhat.com> Date: Fri, 08 May 2015 15:04:53 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1431078628-7856-1-git-send-email-pbonzini@redhat.com> <554CAEC3.5030705@redhat.com> <554CAF13.4030000@redhat.com> <554CB401.2060608@redhat.com> In-Reply-To: <554CB401.2060608@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] qemu-nbd: only send a limited number of errno codes on the wire List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: kwolf@redhat.com, armbru@redhat.com, mreitz@redhat.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/05/2015 15:02, Eric Blake wrote: >>>>> Do we also want to handle "case 0: return 0;" on either >>>>> conversion, or even "case 0: abort();" to ensure that >>>>> callers are using these helpers correctly? >>> >>> Yes, it's much better that way. > Thinking about it a bit more: abort() is fine on the sending side, > to ensure we aren't putting garbage on the wire; but abort() on > the receiving side is a bit risky (we should be handling a > corrupted incoming stream gracefully - a malicious sender should > not be able to crash us). Of course, once we've detected a > corrupted incoming stream, we can't do much for the block device > the stream was supposed to represent (perhaps treat it as EIO and > declare the device dead), but that's still better than aborting. I've included "case 0: return 0;" in the pull request. Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVTLRxAAoJEL/70l94x66DiU0IAIc9c7XNRGkOzvx8Dr/euTZh urx9OVG4Mwpust8KDmquuBJUv18Xu+omh9AxWOkF5ChZUGBwVxyt0N4sKPreVXK2 zJgObt+5cV4o1FXMb3QcFn1CD7s6+8V8T2QukGTviCsIwRaovwpBQAMuT4N5aJWY BTkCE8GiGTVYiWhV+Uz3UML33j5mXJ4WM2LP11ndsKZpFNMvezwo9iyvQe28EqrI Cj6xz+pLbnOtTu3/Kdf1SMA4FK9loH7/y6fth833TIBE/OIyY+PEtNKoq7TJzc3i /S58dVjXNZAez1Bf0Hb9rMCKsGg/MSv7mGPU5IsLQSKgZ0i154ZzJFxifkXnzYU= =fZNP -----END PGP SIGNATURE-----