From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcBbY-0007f8-T5 for qemu-devel@nongnu.org; Wed, 16 Sep 2015 08:14:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcBbV-0005iY-Mr for qemu-devel@nongnu.org; Wed, 16 Sep 2015 08:14:28 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:10189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcBbV-0005iM-Eh for qemu-devel@nongnu.org; Wed, 16 Sep 2015 08:14:25 -0400 References: <1442333283-13119-1-git-send-email-marcandre.lureau@redhat.com> <1442333283-13119-30-git-send-email-marcandre.lureau@redhat.com> From: Claudio Fontana Message-ID: <55F95D1A.2020909@huawei.com> Date: Wed, 16 Sep 2015 14:14:18 +0200 MIME-Version: 1.0 In-Reply-To: <1442333283-13119-30-git-send-email-marcandre.lureau@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 29/46] ivshmem: error on too many eventfd received List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: marcandre.lureau@redhat.com, qemu-devel@nongnu.org Cc: drjones@redhat.com, cam@cs.ualberta.ca, stefanha@redhat.com On 15.09.2015 18:07, marcandre.lureau@redhat.com wrote: > From: Marc-André Lureau > > The number of eventfd that can be handled per peer is limited by the > number of vectors. Return an error when receiving too many of them. > > Signed-off-by: Marc-André Lureau > --- > hw/misc/ivshmem.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c > index b9c78cd..63e4c4f 100644 > --- a/hw/misc/ivshmem.c > +++ b/hw/misc/ivshmem.c > @@ -569,6 +569,13 @@ static void ivshmem_read(void *opaque, const uint8_t *buf, int size) > } > > /* get a new eventfd */ > + if (peer->nb_eventfds >= s->vectors) { > + error_report("Too many eventfd received, device has %d vectors", > + s->vectors); > + close(incoming_fd); > + return; > + } > + > nth_eventfd = peer->nb_eventfds++; > > /* this is an eventfd for a particular peer VM */ > can the device still operate if we detect these errors at ivshmem_read time? I am referring also to the other checks happening in ivshmem_read doing if ([something fails]) { error_report("abcabc"); /* close(), ... */ return; } Can the device stop operating if these conditions happen? If so, do we have to put the device into a non-operating state, where all read/writes are ignored? Should there be a ivshmem status flag for ERROR? Should we exit(1)? note: I don't know what the "proper" behavior should be, but I am concerned about the runtime stability of the software which uses the device. Ciao, Claudio