Peter Maydell writes:
> On 4 April 2018 at 11:27, Alex Bennée wrote:
>> I'm wondering if it should be doing more. After all start/end_exclusive
>> rely on the cpu list and that isn't updated on thread creation - and
>> without that a bunch of other things fail like ld/st exclusive after
>> your
On 4 April 2018 at 11:27, Alex Bennée wrote:
> I'm wondering if it should be doing more. After all start/end_exclusive
> rely on the cpu list and that isn't updated on thread creation - and
> without that a bunch of other things fail like ld/st exclusive after
> your first new thread is spawned.
Max Filippov writes:
> Hi Alex,
>
> On Tue, Apr 3, 2018 at 9:26 AM, Alex Bennée wrote:
>> Max Filippov writes:
>>
>>> cpu_copy adds newly created CPU object to container/machine/unattached,
>>> but does it w/o proper locking. As a result when multiple threads are
>>> created rapidly QEMU may a
Hi Alex,
On Tue, Apr 3, 2018 at 9:26 AM, Alex Bennée wrote:
> Max Filippov writes:
>
>> cpu_copy adds newly created CPU object to container/machine/unattached,
>> but does it w/o proper locking. As a result when multiple threads are
>> created rapidly QEMU may abort with the following message:
>
Max Filippov writes:
> cpu_copy adds newly created CPU object to container/machine/unattached,
> but does it w/o proper locking. As a result when multiple threads are
> created rapidly QEMU may abort with the following message:
>
> GLib-CRITICAL **: g_hash_table_iter_next: assertion
> 'ri->v
Hi,
This series failed docker-quick@centos6 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20180330133525.10994-1-jcmvb...@gmail.com
Subject: [Qemu-devel] [PATCH] linux-user: call
Le 30/03/2018 à 15:35, Max Filippov a écrit :
> cpu_copy adds newly created CPU object to container/machine/unattached,
> but does it w/o proper locking. As a result when multiple threads are
> created rapidly QEMU may abort with the following message:
>
> GLib-CRITICAL **: g_hash_table_iter_nex
cpu_copy adds newly created CPU object to container/machine/unattached,
but does it w/o proper locking. As a result when multiple threads are
created rapidly QEMU may abort with the following message:
GLib-CRITICAL **: g_hash_table_iter_next: assertion
'ri->version == ri->hash_table->version'
