On 22.06.2010, at 00:13, Jan Kiszka wrote:
> Jan Kiszka wrote:
>> And there is some race that cause a lock up in qemu_mutex_lock_iothread
>> after a while (the cpu_unlink_tb seems to race with the linking - just a
>> guess so far).
>
> This seems to fix a long-standing race between cpu_exec and
> signal-driven cpu_unlink_tb:
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 026980a..bfc34e4 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -599,8 +598,9 @@ int cpu_exec(CPUState *env1)
> TB, but before it is linked into a potentially
> infinite loop and becomes env->current_tb. Avoid
> starting execution if there is a pending interrupt. */
> - if (!unlikely (env->exit_request)) {
> - env->current_tb = tb;
> + env->current_tb = tb;
> + asm("");
This is just barrier(), no?
Alex
