qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size ex


From: Fernando Casas Schössow
Subject: Re: [Qemu-devel] [Qemu-block] Guest unresponsive after Virtqueue size exceeded error
Date: Thu, 28 Feb 2019 07:35:23 +0000

Just wanted to share a small update on the situation after updating QEMU to the 
new Alpine package patched with Natanael's patch.
So far so good, moreover I switched a few other guests from SATA to VirtIO SCSI 
and after two days no issues.
Unless I find any problem I will report back with an update in a week from now.

Thanks everyone for all you did to help find a solution to this issue.

On mar, feb 26, 2019 at 2:30 PM, Paolo Bonzini <address@hidden> wrote:
On 23/02/19 12:49, Natanael Copa wrote:
I suspect this happens due to the Alpine toolchain will enable 
_FORTIFY_SOURCE=2 by default and the way this is implemented via 
fortify-headers: 
http://git.2f30.org/fortify-headers/file/include/string.h.html#l39
The call to __orig_memcpy is the culprit there, is there any reason not to do 
something like _FORTIFY_FN(memcpy) void *__memcpy_chk(void *__od, const void 
*__os, size_t __n) { size_t __bd = __builtin_object_size(__od, 0); size_t __bs 
= __builtin_object_size(__os, 0); char *__d = (char *)__od; const char *__s = 
(const char *)__os; /* trap if pointers are overlapping but not if dst == src. 
* gcc seems to like to generate code that relies on dst == src */ if ((__d < 
__s && __d + __n > __s) || (__s < __d && __s + __n > __d)) __builtin_trap(); if 
(__n > __bd || __n > __bs) __builtin_trap(); return memcpy(__od, __os, __n); } 
#define memcpy __memcpy_chk ? That is, getting rid of _FORTIFY_ORIG altogether. 
Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]