From: "Alex Bennée" <alex.bennee@linaro.org>
To: Sergey Fedorov <serge.fdrv@gmail.com>
Cc: Sergey Fedorov <sergey.fedorov@linaro.org>,
qemu-devel@nongnu.org, Riku Voipio <riku.voipio@iki.fi>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
patches@linaro.org, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC 6/8] linux-user: Support CPU work queue
Date: Thu, 30 Jun 2016 11:32:12 +0100 [thread overview]
Message-ID: <87furvq85v.fsf@linaro.org> (raw)
In-Reply-To: <5774E8C2.1050506@gmail.com>
Sergey Fedorov <serge.fdrv@gmail.com> writes:
> On 29/06/16 19:17, Alex Bennée wrote:
>> So I think there is a deadlock we can get with the async work:
>>
>> (gdb) thread apply all bt
>>
>> Thread 11 (Thread 0x7ffefeca7700 (LWP 2912)):
>> #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>> #1 0x00005555555cb777 in wait_cpu_work () at /home/alex/lsrc/qemu/qemu.git/linux-user/main.c:155
>> #2 0x00005555555a0cee in wait_safe_cpu_work () at /home/alex/lsrc/qemu/qemu.git/cpu-exec-common.c:87
>> #3 0x00005555555cb8fe in cpu_exec_end (cpu=0x555555bb67e0) at /home/alex/lsrc/qemu/qemu.git/linux-user/main.c:222
>> #4 0x00005555555cc7a7 in cpu_loop (env=0x555555bbea58) at /home/alex/lsrc/qemu/qemu.git/linux-user/main.c:749
>> #5 0x00005555555db0b2 in clone_func (arg=0x7fffffffc9c0) at /home/alex/lsrc/qemu/qemu.git/linux-user/syscall.c:5424
>> #6 0x00007ffff6bed6fa in start_thread (arg=0x7ffefeca7700) at pthread_create.c:333
>> #7 0x00007ffff6923b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>>
>> <a bunch of other threads doing the same and then...>
>>
>> Thread 3 (Thread 0x7ffff7f38700 (LWP 2904)):
>> #0 0x00005555555faf5d in safe_syscall_base ()
>> #1 0x00005555555cfeaf in safe_futex (uaddr=0x7ffff528a0a4, op=128, val=1, timeout=0x0, uaddr2=0x0, val3=-162668384)
>> at /home/alex/lsrc/qemu/qemu.git/linux-user/syscall.c:706
>> #2 0x00005555555dd7cc in do_futex (uaddr=4132298916, op=128, val=1, timeout=0, uaddr2=0, val3=-162668384)
>> at /home/alex/lsrc/qemu/qemu.git/linux-user/syscall.c:6246
>> #3 0x00005555555e8cdb in do_syscall (cpu_env=0x555555a81118, num=240, arg1=-162668380, arg2=128, arg3=1, arg4=0, arg5=0, arg6=-162668384,
>> arg7=0, arg8=0) at /home/alex/lsrc/qemu/qemu.git/linux-user/syscall.c:10642
>> #4 0x00005555555cd20e in cpu_loop (env=0x555555a81118) at /home/alex/lsrc/qemu/qemu.git/linux-user/main.c:883
>> #5 0x00005555555db0b2 in clone_func (arg=0x7fffffffc9c0) at /home/alex/lsrc/qemu/qemu.git/linux-user/syscall.c:5424
>> #6 0x00007ffff6bed6fa in start_thread (arg=0x7ffff7f38700) at pthread_create.c:333
>> #7 0x00007ffff6923b5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>>
>> So everything is stalled awaiting this thread waking up and draining
>> its queue. So for linux-user I think we need some mechanism to kick
>> these syscalls which I assume means throwing a signal at it.
>
> Nice catch! How did you get it?
Running pigz (armhf, debian) to compress stuff.
> We always go through cpu_exec_end()
> before serving a guest syscall and always go through cpu_exec_start()
> before entering the guest code execution loop. If we always schedule
> safe work on the current thread's queue then I think there's a way to
> make it safe and avoid kicking syscalls.
Not let the signals complete until safe work is done?
>
> Thanks,
> Sergey
--
Alex Bennée
next prev parent reply other threads:[~2016-06-30 10:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-19 22:28 [Qemu-devel] [RFC 0/8] cpu-exec: Safe work in quiescent state Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 1/8] cpus: pass CPUState to run_on_cpu helpers Sergey Fedorov
2016-06-20 1:23 ` David Gibson
2016-06-20 13:02 ` Alex Bennée
2016-06-20 13:07 ` Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 2/8] cpus: Move common code out of {async_, }run_on_cpu() Sergey Fedorov
2016-06-27 8:54 ` Alex Bennée
2016-06-19 22:28 ` [Qemu-devel] [RFC 3/8] cpus: Add 'qemu_work_cond' usage wrappers Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 4/8] linux-user: Rework exclusive operation mechanism Sergey Fedorov
2016-06-27 9:02 ` Alex Bennée
2016-06-29 14:57 ` Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 5/8] linux-user: Add qemu_cpu_is_self() and qemu_cpu_kick() Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 6/8] linux-user: Support CPU work queue Sergey Fedorov
2016-06-27 9:31 ` Alex Bennée
2016-06-29 14:59 ` Sergey Fedorov
2016-06-29 16:17 ` Alex Bennée
2016-06-30 9:39 ` Sergey Fedorov
2016-06-30 10:32 ` Alex Bennée [this message]
2016-06-30 10:35 ` Sergey Fedorov
2016-07-01 8:56 ` Sergey Fedorov
2016-07-01 9:04 ` Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 7/8] cpu-exec-common: Introduce async_safe_run_on_cpu() Sergey Fedorov
2016-06-27 9:36 ` Alex Bennée
2016-06-29 15:03 ` Sergey Fedorov
2016-06-29 16:09 ` Alex Bennée
2016-07-01 16:29 ` Alvise Rigo
2016-07-01 16:55 ` Sergey Fedorov
2016-06-19 22:28 ` [Qemu-devel] [RFC 8/8] tcg: Make tb_flush() thread safe Sergey Fedorov
2016-06-28 16:18 ` Alex Bennée
2016-06-29 15:03 ` Sergey Fedorov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87furvq85v.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=crosthwaite.peter@gmail.com \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=rth@twiddle.net \
--cc=serge.fdrv@gmail.com \
--cc=sergey.fedorov@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).