2009-04-24 22:03:15 +04:00
|
|
|
/*
|
|
|
|
* Wrappers around mutex/cond/thread functions
|
|
|
|
*
|
|
|
|
* Copyright Red Hat, Inc. 2009
|
|
|
|
*
|
|
|
|
* Author:
|
|
|
|
* Marcelo Tosatti <mtosatti@redhat.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*
|
|
|
|
*/
|
2016-01-29 20:49:55 +03:00
|
|
|
#include "qemu/osdep.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/thread.h"
|
2013-09-25 10:20:59 +04:00
|
|
|
#include "qemu/atomic.h"
|
2014-12-02 14:05:45 +03:00
|
|
|
#include "qemu/notify.h"
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
#include "trace.h"
|
2009-04-24 22:03:15 +04:00
|
|
|
|
2014-01-30 14:20:31 +04:00
|
|
|
static bool name_threads;
|
|
|
|
|
|
|
|
void qemu_thread_naming(bool enable)
|
|
|
|
{
|
|
|
|
name_threads = enable;
|
2014-03-12 15:48:18 +04:00
|
|
|
|
|
|
|
#ifndef CONFIG_THREAD_SETNAME_BYTHREAD
|
|
|
|
/* This is a debugging option, not fatal */
|
|
|
|
if (enable) {
|
|
|
|
fprintf(stderr, "qemu: thread naming not supported on this host\n");
|
|
|
|
}
|
|
|
|
#endif
|
2014-01-30 14:20:31 +04:00
|
|
|
}
|
|
|
|
|
2009-04-24 22:03:15 +04:00
|
|
|
static void error_exit(int err, const char *msg)
|
|
|
|
{
|
|
|
|
fprintf(stderr, "qemu: %s: %s\n", msg, strerror(err));
|
2011-09-21 11:28:31 +04:00
|
|
|
abort();
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_mutex_init(QemuMutex *mutex)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2015-03-05 18:47:14 +03:00
|
|
|
err = pthread_mutex_init(&mutex->lock, NULL);
|
2009-04-24 22:03:15 +04:00
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
2017-07-04 15:23:25 +03:00
|
|
|
mutex->initialized = true;
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
2010-07-07 22:58:01 +04:00
|
|
|
void qemu_mutex_destroy(QemuMutex *mutex)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(mutex->initialized);
|
|
|
|
mutex->initialized = false;
|
2010-07-07 22:58:01 +04:00
|
|
|
err = pthread_mutex_destroy(&mutex->lock);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
|
2009-04-24 22:03:15 +04:00
|
|
|
void qemu_mutex_lock(QemuMutex *mutex)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(mutex->initialized);
|
2009-04-24 22:03:15 +04:00
|
|
|
err = pthread_mutex_lock(&mutex->lock);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
|
|
|
|
trace_qemu_mutex_locked(mutex);
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int qemu_mutex_trylock(QemuMutex *mutex)
|
|
|
|
{
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(mutex->initialized);
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
err = pthread_mutex_trylock(&mutex->lock);
|
|
|
|
if (err == 0) {
|
|
|
|
trace_qemu_mutex_locked(mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (err != EBUSY) {
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
return -EBUSY;
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_mutex_unlock(QemuMutex *mutex)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(mutex->initialized);
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
trace_qemu_mutex_unlocked(mutex);
|
2009-04-24 22:03:15 +04:00
|
|
|
err = pthread_mutex_unlock(&mutex->lock);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
|
2016-10-27 13:49:07 +03:00
|
|
|
void qemu_rec_mutex_init(QemuRecMutex *mutex)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
pthread_mutexattr_t attr;
|
|
|
|
|
|
|
|
pthread_mutexattr_init(&attr);
|
|
|
|
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
|
|
|
|
err = pthread_mutex_init(&mutex->lock, &attr);
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
|
|
|
if (err) {
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
2017-07-04 15:23:25 +03:00
|
|
|
mutex->initialized = true;
|
2016-10-27 13:49:07 +03:00
|
|
|
}
|
|
|
|
|
2009-04-24 22:03:15 +04:00
|
|
|
void qemu_cond_init(QemuCond *cond)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = pthread_cond_init(&cond->cond, NULL);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
2017-07-04 15:23:25 +03:00
|
|
|
cond->initialized = true;
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
2010-07-07 22:58:01 +04:00
|
|
|
void qemu_cond_destroy(QemuCond *cond)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(cond->initialized);
|
|
|
|
cond->initialized = false;
|
2010-07-07 22:58:01 +04:00
|
|
|
err = pthread_cond_destroy(&cond->cond);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
|
2009-04-24 22:03:15 +04:00
|
|
|
void qemu_cond_signal(QemuCond *cond)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(cond->initialized);
|
2009-04-24 22:03:15 +04:00
|
|
|
err = pthread_cond_signal(&cond->cond);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_cond_broadcast(QemuCond *cond)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(cond->initialized);
|
2009-04-24 22:03:15 +04:00
|
|
|
err = pthread_cond_broadcast(&cond->cond);
|
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(cond->initialized);
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
trace_qemu_mutex_unlocked(mutex);
|
2009-04-24 22:03:15 +04:00
|
|
|
err = pthread_cond_wait(&cond->cond, &mutex->lock);
|
trace: add qemu mutex lock and unlock trace events
These trace events were very useful to help me to understand and find a
reordering issue in vfio, for example:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
that also helped me to see the desired result after the fix:
qemu_mutex_lock locked mutex 0x10905ad8
vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4)
vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4)
qemu_mutex_unlock unlocked mutex 0x10905ad8
So it could be a good idea to have these traces implemented. It's worth
mentioning that they should be surgically enabled during the debugging,
otherwise it can flood the trace logs with lock/unlock messages.
How to use it:
trace-event qemu_mutex_lock on|off
trace-event qemu_mutex_unlock on|off
or
trace-event qemu_mutex* on|off
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
Message-Id: <1493054398-26013-1-git-send-email-joserz@linux.vnet.ibm.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Also handle trylock, cond_wait and win32; trace "unlocked" while still
in the critical section, so that "unlocked" always comes before the
next "locked" tracepoint. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-24 20:19:58 +03:00
|
|
|
trace_qemu_mutex_locked(mutex);
|
2009-04-24 22:03:15 +04:00
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
|
2011-08-08 16:36:41 +04:00
|
|
|
void qemu_sem_init(QemuSemaphore *sem, int init)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2017-09-05 15:19:32 +03:00
|
|
|
#ifndef CONFIG_SEM_TIMEDWAIT
|
2012-11-02 18:43:21 +04:00
|
|
|
rc = pthread_mutex_init(&sem->lock, NULL);
|
|
|
|
if (rc != 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
|
|
|
rc = pthread_cond_init(&sem->cond, NULL);
|
|
|
|
if (rc != 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
|
|
|
if (init < 0) {
|
|
|
|
error_exit(EINVAL, __func__);
|
|
|
|
}
|
|
|
|
sem->count = init;
|
|
|
|
#else
|
2011-08-08 16:36:41 +04:00
|
|
|
rc = sem_init(&sem->sem, 0, init);
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(errno, __func__);
|
|
|
|
}
|
2012-11-02 18:43:21 +04:00
|
|
|
#endif
|
2017-07-04 15:23:25 +03:00
|
|
|
sem->initialized = true;
|
2011-08-08 16:36:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_sem_destroy(QemuSemaphore *sem)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(sem->initialized);
|
|
|
|
sem->initialized = false;
|
2017-09-05 15:19:32 +03:00
|
|
|
#ifndef CONFIG_SEM_TIMEDWAIT
|
2012-11-02 18:43:21 +04:00
|
|
|
rc = pthread_cond_destroy(&sem->cond);
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
|
|
|
rc = pthread_mutex_destroy(&sem->lock);
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
|
|
|
#else
|
2011-08-08 16:36:41 +04:00
|
|
|
rc = sem_destroy(&sem->sem);
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(errno, __func__);
|
|
|
|
}
|
2012-11-02 18:43:21 +04:00
|
|
|
#endif
|
2011-08-08 16:36:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_sem_post(QemuSemaphore *sem)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(sem->initialized);
|
2017-09-05 15:19:32 +03:00
|
|
|
#ifndef CONFIG_SEM_TIMEDWAIT
|
2012-11-02 18:43:21 +04:00
|
|
|
pthread_mutex_lock(&sem->lock);
|
2013-07-03 12:58:14 +04:00
|
|
|
if (sem->count == UINT_MAX) {
|
2012-11-02 18:43:21 +04:00
|
|
|
rc = EINVAL;
|
|
|
|
} else {
|
2013-07-03 12:58:14 +04:00
|
|
|
sem->count++;
|
|
|
|
rc = pthread_cond_signal(&sem->cond);
|
2012-11-02 18:43:21 +04:00
|
|
|
}
|
|
|
|
pthread_mutex_unlock(&sem->lock);
|
|
|
|
if (rc != 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
|
|
|
#else
|
2011-08-08 16:36:41 +04:00
|
|
|
rc = sem_post(&sem->sem);
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(errno, __func__);
|
|
|
|
}
|
2012-11-02 18:43:21 +04:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static void compute_abs_deadline(struct timespec *ts, int ms)
|
|
|
|
{
|
|
|
|
struct timeval tv;
|
|
|
|
gettimeofday(&tv, NULL);
|
|
|
|
ts->tv_nsec = tv.tv_usec * 1000 + (ms % 1000) * 1000000;
|
|
|
|
ts->tv_sec = tv.tv_sec + ms / 1000;
|
|
|
|
if (ts->tv_nsec >= 1000000000) {
|
|
|
|
ts->tv_sec++;
|
|
|
|
ts->tv_nsec -= 1000000000;
|
|
|
|
}
|
2011-08-08 16:36:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int qemu_sem_timedwait(QemuSemaphore *sem, int ms)
|
|
|
|
{
|
|
|
|
int rc;
|
2012-11-02 18:43:21 +04:00
|
|
|
struct timespec ts;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(sem->initialized);
|
2017-09-05 15:19:32 +03:00
|
|
|
#ifndef CONFIG_SEM_TIMEDWAIT
|
2013-07-03 12:58:14 +04:00
|
|
|
rc = 0;
|
2012-11-02 18:43:21 +04:00
|
|
|
compute_abs_deadline(&ts, ms);
|
|
|
|
pthread_mutex_lock(&sem->lock);
|
2013-07-03 12:58:14 +04:00
|
|
|
while (sem->count == 0) {
|
2012-11-02 18:43:21 +04:00
|
|
|
rc = pthread_cond_timedwait(&sem->cond, &sem->lock, &ts);
|
|
|
|
if (rc == ETIMEDOUT) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (rc != 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
|
|
|
}
|
2013-07-03 12:58:14 +04:00
|
|
|
if (rc != ETIMEDOUT) {
|
|
|
|
--sem->count;
|
|
|
|
}
|
2012-11-02 18:43:21 +04:00
|
|
|
pthread_mutex_unlock(&sem->lock);
|
|
|
|
return (rc == ETIMEDOUT ? -1 : 0);
|
|
|
|
#else
|
2011-08-08 16:36:41 +04:00
|
|
|
if (ms <= 0) {
|
|
|
|
/* This is cheaper than sem_timedwait. */
|
|
|
|
do {
|
|
|
|
rc = sem_trywait(&sem->sem);
|
|
|
|
} while (rc == -1 && errno == EINTR);
|
|
|
|
if (rc == -1 && errno == EAGAIN) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
2012-11-02 18:43:21 +04:00
|
|
|
compute_abs_deadline(&ts, ms);
|
2011-08-08 16:36:41 +04:00
|
|
|
do {
|
|
|
|
rc = sem_timedwait(&sem->sem, &ts);
|
|
|
|
} while (rc == -1 && errno == EINTR);
|
|
|
|
if (rc == -1 && errno == ETIMEDOUT) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(errno, __func__);
|
|
|
|
}
|
|
|
|
return 0;
|
2012-11-02 18:43:21 +04:00
|
|
|
#endif
|
2011-08-08 16:36:41 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_sem_wait(QemuSemaphore *sem)
|
|
|
|
{
|
2013-07-03 12:58:14 +04:00
|
|
|
int rc;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(sem->initialized);
|
2017-09-05 15:19:32 +03:00
|
|
|
#ifndef CONFIG_SEM_TIMEDWAIT
|
2012-11-02 18:43:21 +04:00
|
|
|
pthread_mutex_lock(&sem->lock);
|
2013-07-03 12:58:14 +04:00
|
|
|
while (sem->count == 0) {
|
|
|
|
rc = pthread_cond_wait(&sem->cond, &sem->lock);
|
|
|
|
if (rc != 0) {
|
|
|
|
error_exit(rc, __func__);
|
|
|
|
}
|
2012-11-02 18:43:21 +04:00
|
|
|
}
|
2013-07-03 12:58:14 +04:00
|
|
|
--sem->count;
|
2012-11-02 18:43:21 +04:00
|
|
|
pthread_mutex_unlock(&sem->lock);
|
|
|
|
#else
|
2011-08-08 16:36:41 +04:00
|
|
|
do {
|
|
|
|
rc = sem_wait(&sem->sem);
|
|
|
|
} while (rc == -1 && errno == EINTR);
|
|
|
|
if (rc < 0) {
|
|
|
|
error_exit(errno, __func__);
|
|
|
|
}
|
2012-11-02 18:43:21 +04:00
|
|
|
#endif
|
2011-08-08 16:36:41 +04:00
|
|
|
}
|
|
|
|
|
2013-09-25 10:20:59 +04:00
|
|
|
#ifdef __linux__
|
2017-01-12 21:07:54 +03:00
|
|
|
#include "qemu/futex.h"
|
2013-09-25 10:20:59 +04:00
|
|
|
#else
|
2017-01-12 21:07:54 +03:00
|
|
|
static inline void qemu_futex_wake(QemuEvent *ev, int n)
|
2013-09-25 10:20:59 +04:00
|
|
|
{
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(ev->initialized);
|
2015-02-02 18:36:51 +03:00
|
|
|
pthread_mutex_lock(&ev->lock);
|
2013-09-25 10:20:59 +04:00
|
|
|
if (n == 1) {
|
|
|
|
pthread_cond_signal(&ev->cond);
|
|
|
|
} else {
|
|
|
|
pthread_cond_broadcast(&ev->cond);
|
|
|
|
}
|
2015-02-02 18:36:51 +03:00
|
|
|
pthread_mutex_unlock(&ev->lock);
|
2013-09-25 10:20:59 +04:00
|
|
|
}
|
|
|
|
|
2017-01-12 21:07:54 +03:00
|
|
|
static inline void qemu_futex_wait(QemuEvent *ev, unsigned val)
|
2013-09-25 10:20:59 +04:00
|
|
|
{
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(ev->initialized);
|
2013-09-25 10:20:59 +04:00
|
|
|
pthread_mutex_lock(&ev->lock);
|
|
|
|
if (ev->value == val) {
|
|
|
|
pthread_cond_wait(&ev->cond, &ev->lock);
|
|
|
|
}
|
|
|
|
pthread_mutex_unlock(&ev->lock);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Valid transitions:
|
|
|
|
* - free->set, when setting the event
|
2017-01-12 21:07:54 +03:00
|
|
|
* - busy->set, when setting the event, followed by qemu_futex_wake
|
2013-09-25 10:20:59 +04:00
|
|
|
* - set->free, when resetting the event
|
|
|
|
* - free->busy, when waiting
|
|
|
|
*
|
|
|
|
* set->busy does not happen (it can be observed from the outside but
|
|
|
|
* it really is set->free->busy).
|
|
|
|
*
|
|
|
|
* busy->free provably cannot happen; to enforce it, the set->free transition
|
|
|
|
* is done with an OR, which becomes a no-op if the event has concurrently
|
|
|
|
* transitioned to free or busy.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define EV_SET 0
|
|
|
|
#define EV_FREE 1
|
|
|
|
#define EV_BUSY -1
|
|
|
|
|
|
|
|
void qemu_event_init(QemuEvent *ev, bool init)
|
|
|
|
{
|
|
|
|
#ifndef __linux__
|
|
|
|
pthread_mutex_init(&ev->lock, NULL);
|
|
|
|
pthread_cond_init(&ev->cond, NULL);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ev->value = (init ? EV_SET : EV_FREE);
|
2017-07-04 15:23:25 +03:00
|
|
|
ev->initialized = true;
|
2013-09-25 10:20:59 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_event_destroy(QemuEvent *ev)
|
|
|
|
{
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(ev->initialized);
|
|
|
|
ev->initialized = false;
|
2013-09-25 10:20:59 +04:00
|
|
|
#ifndef __linux__
|
|
|
|
pthread_mutex_destroy(&ev->lock);
|
|
|
|
pthread_cond_destroy(&ev->cond);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_event_set(QemuEvent *ev)
|
|
|
|
{
|
2016-09-19 12:10:57 +03:00
|
|
|
/* qemu_event_set has release semantics, but because it *loads*
|
|
|
|
* ev->value we need a full memory barrier here.
|
|
|
|
*/
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(ev->initialized);
|
2016-09-19 12:10:57 +03:00
|
|
|
smp_mb();
|
|
|
|
if (atomic_read(&ev->value) != EV_SET) {
|
2013-09-25 10:20:59 +04:00
|
|
|
if (atomic_xchg(&ev->value, EV_SET) == EV_BUSY) {
|
|
|
|
/* There were waiters, wake them up. */
|
2017-01-12 21:07:54 +03:00
|
|
|
qemu_futex_wake(ev, INT_MAX);
|
2013-09-25 10:20:59 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_event_reset(QemuEvent *ev)
|
|
|
|
{
|
2016-09-19 12:10:57 +03:00
|
|
|
unsigned value;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(ev->initialized);
|
2016-09-19 12:10:57 +03:00
|
|
|
value = atomic_read(&ev->value);
|
|
|
|
smp_mb_acquire();
|
|
|
|
if (value == EV_SET) {
|
2013-09-25 10:20:59 +04:00
|
|
|
/*
|
|
|
|
* If there was a concurrent reset (or even reset+wait),
|
|
|
|
* do nothing. Otherwise change EV_SET->EV_FREE.
|
|
|
|
*/
|
|
|
|
atomic_or(&ev->value, EV_FREE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_event_wait(QemuEvent *ev)
|
|
|
|
{
|
|
|
|
unsigned value;
|
|
|
|
|
2017-07-04 15:23:25 +03:00
|
|
|
assert(ev->initialized);
|
2016-09-19 12:10:57 +03:00
|
|
|
value = atomic_read(&ev->value);
|
|
|
|
smp_mb_acquire();
|
2013-09-25 10:20:59 +04:00
|
|
|
if (value != EV_SET) {
|
|
|
|
if (value == EV_FREE) {
|
|
|
|
/*
|
|
|
|
* Leave the event reset and tell qemu_event_set that there
|
|
|
|
* are waiters. No need to retry, because there cannot be
|
2015-09-09 00:45:14 +03:00
|
|
|
* a concurrent busy->free transition. After the CAS, the
|
2013-09-25 10:20:59 +04:00
|
|
|
* event will be either set or busy.
|
|
|
|
*/
|
|
|
|
if (atomic_cmpxchg(&ev->value, EV_FREE, EV_BUSY) == EV_SET) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2017-01-12 21:07:54 +03:00
|
|
|
qemu_futex_wait(ev, EV_BUSY);
|
2013-09-25 10:20:59 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-02 14:05:45 +03:00
|
|
|
static pthread_key_t exit_key;
|
|
|
|
|
|
|
|
union NotifierThreadData {
|
|
|
|
void *ptr;
|
|
|
|
NotifierList list;
|
|
|
|
};
|
|
|
|
QEMU_BUILD_BUG_ON(sizeof(union NotifierThreadData) != sizeof(void *));
|
|
|
|
|
|
|
|
void qemu_thread_atexit_add(Notifier *notifier)
|
|
|
|
{
|
|
|
|
union NotifierThreadData ntd;
|
|
|
|
ntd.ptr = pthread_getspecific(exit_key);
|
|
|
|
notifier_list_add(&ntd.list, notifier);
|
|
|
|
pthread_setspecific(exit_key, ntd.ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_thread_atexit_remove(Notifier *notifier)
|
|
|
|
{
|
|
|
|
union NotifierThreadData ntd;
|
|
|
|
ntd.ptr = pthread_getspecific(exit_key);
|
|
|
|
notifier_remove(notifier);
|
|
|
|
pthread_setspecific(exit_key, ntd.ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void qemu_thread_atexit_run(void *arg)
|
|
|
|
{
|
|
|
|
union NotifierThreadData ntd = { .ptr = arg };
|
|
|
|
notifier_list_notify(&ntd.list, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __attribute__((constructor)) qemu_thread_atexit_init(void)
|
|
|
|
{
|
|
|
|
pthread_key_create(&exit_key, qemu_thread_atexit_run);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-03-12 15:48:18 +04:00
|
|
|
#ifdef CONFIG_PTHREAD_SETNAME_NP
|
qemu-thread: fix races on threads that exit very quickly
If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
The backtrace is:
#0 0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f46c602a8c8 in __GI_abort () at abort.c:90
#2 0x00000000008543c9 in PAT_abort ()
#3 0x000000000085140d in patchIllInsHandler ()
#4 <signal handler called>
#5 pthread_detach (th=139933037614848) at pthread_detach.c:50
#6 0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
#7 0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
at io/task.c:141
#8 0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
destroy=destroy@entry=0x0) at io/channel_socket.c:194
#9 0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
#10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
#11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
#13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
#14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
#15 0x000000000056a511 in main_loop () at vl.c:2076
#16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
The cause of this problem is a glibc bug; for more information, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19951.
The solution for this bug is to use pthread_attr_setdetachstate.
There is a similar issue with pthread_setname_np, which is moved
from creating thread to created thread.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Simplify the code by removing qemu_thread_set_name, and free the arguments
before invoking the start routine. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-11-28 07:46:56 +03:00
|
|
|
typedef struct {
|
|
|
|
void *(*start_routine)(void *);
|
|
|
|
void *arg;
|
|
|
|
char *name;
|
|
|
|
} QemuThreadArgs;
|
|
|
|
|
|
|
|
static void *qemu_thread_start(void *args)
|
|
|
|
{
|
|
|
|
QemuThreadArgs *qemu_thread_args = args;
|
|
|
|
void *(*start_routine)(void *) = qemu_thread_args->start_routine;
|
|
|
|
void *arg = qemu_thread_args->arg;
|
|
|
|
|
|
|
|
/* Attempt to set the threads name; note that this is for debug, so
|
|
|
|
* we're not going to fail if we can't set it.
|
|
|
|
*/
|
|
|
|
pthread_setname_np(pthread_self(), qemu_thread_args->name);
|
|
|
|
g_free(qemu_thread_args->name);
|
|
|
|
g_free(qemu_thread_args);
|
|
|
|
return start_routine(arg);
|
2014-03-12 15:48:18 +04:00
|
|
|
}
|
qemu-thread: fix races on threads that exit very quickly
If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
The backtrace is:
#0 0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f46c602a8c8 in __GI_abort () at abort.c:90
#2 0x00000000008543c9 in PAT_abort ()
#3 0x000000000085140d in patchIllInsHandler ()
#4 <signal handler called>
#5 pthread_detach (th=139933037614848) at pthread_detach.c:50
#6 0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
#7 0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
at io/task.c:141
#8 0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
destroy=destroy@entry=0x0) at io/channel_socket.c:194
#9 0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
#10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
#11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
#13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
#14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
#15 0x000000000056a511 in main_loop () at vl.c:2076
#16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
The cause of this problem is a glibc bug; for more information, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19951.
The solution for this bug is to use pthread_attr_setdetachstate.
There is a similar issue with pthread_setname_np, which is moved
from creating thread to created thread.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Simplify the code by removing qemu_thread_set_name, and free the arguments
before invoking the start routine. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-11-28 07:46:56 +03:00
|
|
|
#endif
|
|
|
|
|
2014-03-12 15:48:18 +04:00
|
|
|
|
2014-01-30 14:20:32 +04:00
|
|
|
void qemu_thread_create(QemuThread *thread, const char *name,
|
2009-04-24 22:03:15 +04:00
|
|
|
void *(*start_routine)(void*),
|
2011-12-12 20:21:31 +04:00
|
|
|
void *arg, int mode)
|
2009-04-24 22:03:15 +04:00
|
|
|
{
|
2011-12-12 20:21:31 +04:00
|
|
|
sigset_t set, oldset;
|
2009-04-24 22:03:15 +04:00
|
|
|
int err;
|
2011-12-12 20:21:32 +04:00
|
|
|
pthread_attr_t attr;
|
2009-04-24 22:03:15 +04:00
|
|
|
|
2011-12-12 20:21:32 +04:00
|
|
|
err = pthread_attr_init(&attr);
|
|
|
|
if (err) {
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
2010-06-03 17:20:32 +04:00
|
|
|
|
qemu-thread: fix races on threads that exit very quickly
If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
The backtrace is:
#0 0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f46c602a8c8 in __GI_abort () at abort.c:90
#2 0x00000000008543c9 in PAT_abort ()
#3 0x000000000085140d in patchIllInsHandler ()
#4 <signal handler called>
#5 pthread_detach (th=139933037614848) at pthread_detach.c:50
#6 0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
#7 0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
at io/task.c:141
#8 0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
destroy=destroy@entry=0x0) at io/channel_socket.c:194
#9 0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
#10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
#11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
#13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
#14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
#15 0x000000000056a511 in main_loop () at vl.c:2076
#16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
The cause of this problem is a glibc bug; for more information, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19951.
The solution for this bug is to use pthread_attr_setdetachstate.
There is a similar issue with pthread_setname_np, which is moved
from creating thread to created thread.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Simplify the code by removing qemu_thread_set_name, and free the arguments
before invoking the start routine. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-11-28 07:46:56 +03:00
|
|
|
if (mode == QEMU_THREAD_DETACHED) {
|
|
|
|
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
|
|
|
|
}
|
|
|
|
|
2011-12-12 20:21:31 +04:00
|
|
|
/* Leave signal handling to the iothread. */
|
2010-06-03 17:20:32 +04:00
|
|
|
sigfillset(&set);
|
|
|
|
pthread_sigmask(SIG_SETMASK, &set, &oldset);
|
|
|
|
|
qemu-thread: fix races on threads that exit very quickly
If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
The backtrace is:
#0 0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f46c602a8c8 in __GI_abort () at abort.c:90
#2 0x00000000008543c9 in PAT_abort ()
#3 0x000000000085140d in patchIllInsHandler ()
#4 <signal handler called>
#5 pthread_detach (th=139933037614848) at pthread_detach.c:50
#6 0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
#7 0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
at io/task.c:141
#8 0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
destroy=destroy@entry=0x0) at io/channel_socket.c:194
#9 0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
#10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
#11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
#13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
#14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
#15 0x000000000056a511 in main_loop () at vl.c:2076
#16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
The cause of this problem is a glibc bug; for more information, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19951.
The solution for this bug is to use pthread_attr_setdetachstate.
There is a similar issue with pthread_setname_np, which is moved
from creating thread to created thread.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Simplify the code by removing qemu_thread_set_name, and free the arguments
before invoking the start routine. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-11-28 07:46:56 +03:00
|
|
|
#ifdef CONFIG_PTHREAD_SETNAME_NP
|
2014-01-30 14:20:32 +04:00
|
|
|
if (name_threads) {
|
qemu-thread: fix races on threads that exit very quickly
If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
The backtrace is:
#0 0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f46c602a8c8 in __GI_abort () at abort.c:90
#2 0x00000000008543c9 in PAT_abort ()
#3 0x000000000085140d in patchIllInsHandler ()
#4 <signal handler called>
#5 pthread_detach (th=139933037614848) at pthread_detach.c:50
#6 0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
#7 0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
at io/task.c:141
#8 0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
destroy=destroy@entry=0x0) at io/channel_socket.c:194
#9 0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
#10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
#11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
#13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
#14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
#15 0x000000000056a511 in main_loop () at vl.c:2076
#16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
The cause of this problem is a glibc bug; for more information, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19951.
The solution for this bug is to use pthread_attr_setdetachstate.
There is a similar issue with pthread_setname_np, which is moved
from creating thread to created thread.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Simplify the code by removing qemu_thread_set_name, and free the arguments
before invoking the start routine. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-11-28 07:46:56 +03:00
|
|
|
QemuThreadArgs *qemu_thread_args;
|
|
|
|
qemu_thread_args = g_new0(QemuThreadArgs, 1);
|
|
|
|
qemu_thread_args->name = g_strdup(name);
|
|
|
|
qemu_thread_args->start_routine = start_routine;
|
|
|
|
qemu_thread_args->arg = arg;
|
|
|
|
|
|
|
|
err = pthread_create(&thread->thread, &attr,
|
|
|
|
qemu_thread_start, qemu_thread_args);
|
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
err = pthread_create(&thread->thread, &attr,
|
|
|
|
start_routine, arg);
|
2014-01-30 14:20:32 +04:00
|
|
|
}
|
|
|
|
|
qemu-thread: fix races on threads that exit very quickly
If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
The backtrace is:
#0 0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f46c602a8c8 in __GI_abort () at abort.c:90
#2 0x00000000008543c9 in PAT_abort ()
#3 0x000000000085140d in patchIllInsHandler ()
#4 <signal handler called>
#5 pthread_detach (th=139933037614848) at pthread_detach.c:50
#6 0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
#7 0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
at io/task.c:141
#8 0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
destroy=destroy@entry=0x0) at io/channel_socket.c:194
#9 0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
#10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
#11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
#13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
#14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
#15 0x000000000056a511 in main_loop () at vl.c:2076
#16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
The cause of this problem is a glibc bug; for more information, see
https://sourceware.org/bugzilla/show_bug.cgi?id=19951.
The solution for this bug is to use pthread_attr_setdetachstate.
There is a similar issue with pthread_setname_np, which is moved
from creating thread to created thread.
Signed-off-by: linzhecheng <linzhecheng@huawei.com>
Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
[Simplify the code by removing qemu_thread_set_name, and free the arguments
before invoking the start routine. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-11-28 07:46:56 +03:00
|
|
|
if (err)
|
|
|
|
error_exit(err, __func__);
|
|
|
|
|
2010-06-03 17:20:32 +04:00
|
|
|
pthread_sigmask(SIG_SETMASK, &oldset, NULL);
|
2011-12-12 20:21:32 +04:00
|
|
|
|
|
|
|
pthread_attr_destroy(&attr);
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
2011-03-12 19:43:51 +03:00
|
|
|
void qemu_thread_get_self(QemuThread *thread)
|
2009-04-24 22:03:15 +04:00
|
|
|
{
|
|
|
|
thread->thread = pthread_self();
|
|
|
|
}
|
|
|
|
|
2012-05-02 19:21:31 +04:00
|
|
|
bool qemu_thread_is_self(QemuThread *thread)
|
2009-04-24 22:03:15 +04:00
|
|
|
{
|
2011-03-12 19:43:51 +03:00
|
|
|
return pthread_equal(pthread_self(), thread->thread);
|
2009-04-24 22:03:15 +04:00
|
|
|
}
|
|
|
|
|
2010-07-07 22:58:01 +04:00
|
|
|
void qemu_thread_exit(void *retval)
|
|
|
|
{
|
|
|
|
pthread_exit(retval);
|
|
|
|
}
|
2011-12-12 20:21:32 +04:00
|
|
|
|
|
|
|
void *qemu_thread_join(QemuThread *thread)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
void *ret;
|
|
|
|
|
|
|
|
err = pthread_join(thread->thread, &ret);
|
|
|
|
if (err) {
|
|
|
|
error_exit(err, __func__);
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|