From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCwSg-0007DG-MW for qemu-devel@nongnu.org; Tue, 14 Jun 2016 18:05:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCwSe-0006WJ-Oi for qemu-devel@nongnu.org; Tue, 14 Jun 2016 18:05:29 -0400 References: <1463006384-7734-1-git-send-email-eblake@redhat.com> <1463006384-7734-5-git-send-email-eblake@redhat.com> <852e526a-5235-499a-741e-a695f5e74f83@redhat.com> <575EA656.80508@redhat.com> <6DD06745-C91C-4BFB-BFE5-92E5982ACB42@alex.org.uk> <11f620d2-a51d-5235-5abd-4ced314c9090@redhat.com> <38ABE56B-CA23-4372-A413-CDA72BDAE86A@alex.org.uk> <3f9a5b12-67eb-d2f3-f736-22ced5bbf638@redhat.com> From: Paolo Bonzini Message-ID: <2967191c-0204-f99c-0dca-169cdfbcc419@redhat.com> Date: Wed, 15 Jun 2016 00:05:18 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 04/11] nbd: Improve server handling of bogus commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Eric Blake , "qemu-devel@nongnu.org" , qemu block , "nbd-general@lists.sourceforge.net" On 14/06/2016 17:59, Alex Bligh wrote: > >> On 14 Jun 2016, at 16:11, Paolo Bonzini wrote: >> >>> To illustrate the problem, look consider what qemu itself would do as >>> a server if it can't buffer the entire read issued to it. >> >> Return ENOMEM? > > Well OK, qemu then 'works' on the basis it breaks another > part of the spec, which is coping with long reads. ENOMEM is a documented error code, and the limits extension will help with that as well. >> However, it looks like the >> de facto status prior to structured replies is that the error is in the >> spec, and this patch introduces a regression. > > Well, I guess the patch makes it work the same as the > reference server implementation and the spec, which I'd > consider a fix. My view is that the error is in the > kernel client. ... and QEMU and BSD. What good is a server that doesn't interoperate (albeit only in error cases) with any client? Paolo