This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-changelog] Fix call to memmove inside buffer_advance. The call was

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] Fix call to memmove inside buffer_advance. The call was using buffer + size
From: Xen patchbot -3.0-testing <patchbot-3.0-testing@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 13 Dec 2005 22:14:15 +0000
Delivery-date: Tue, 13 Dec 2005 22:15:47 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User emellor@xxxxxxxxxxxxxxxxxxxxxx
# Node ID 42ff4f19d025670f0abc176c8622d9874f130947
# Parent  4ac91bf4b0890a14fb1e926bf50fdaac5daa144a
Fix call to memmove inside buffer_advance.  The call was using buffer + size
as the source for data, rather than buffer->data + size.  When cat'ing large
files inside the guest to the terminal, this caused a xenconsoled segfault.
We get away with this when handling small amounts of data on the current
changeset, presumably because all the data can be shipped to the terminal in
one write, so the size value given to the memmove is 0.  We also used to get
away with this for large data blocks on older changesets, because this problem
was masked by the blocking-write problem fixed in xen-3.0-testing changeset
8247:a082a85143eb; in other words, xenconsoled previously had a tendency to
hang, rather than to crash.

This changeset is not in the xen-unstable tree, because the problem has been
fixed in a different way in that tree.  xen-unstable changeset
8256:2b8efe11096b changes buffer_advance more radically, removing the memmove
altogether.  I believe that the risk associated with that changeset is such
that it should not be moved into xen-3.0-testing immediately, and so this
much smaller change is being committed instead.

Signed-off-by: Ewan Mellor <ewan@xxxxxxxxxxxxx>

diff -r 4ac91bf4b089 -r 42ff4f19d025 tools/console/daemon/io.c
--- a/tools/console/daemon/io.c Mon Dec 12 10:45:53 2005
+++ b/tools/console/daemon/io.c Tue Dec 13 12:13:13 2005
@@ -126,7 +126,7 @@
 static void buffer_advance(struct buffer *buffer, size_t size)
        size = MIN(size, buffer->size);
-       memmove(buffer->data, buffer + size, buffer->size - size);
+       memmove(buffer->data, buffer->data + size, buffer->size - size);
        buffer->size -= size;

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] Fix call to memmove inside buffer_advance. The call was using buffer + size, Xen patchbot -3 . 0-testing <=