Skip to content
Snippets Groups Projects
  • Stefan Hajnoczi's avatar
    c1fe6943
    coroutine-win32: use QEMU_DEFINE_STATIC_CO_TLS() · c1fe6943
    Stefan Hajnoczi authored
    
    Thread-Local Storage variables cannot be used directly from coroutine
    code because the compiler may optimize TLS variable accesses across
    qemu_coroutine_yield() calls. When the coroutine is re-entered from
    another thread the TLS variables from the old thread must no longer be
    used.
    
    Use QEMU_DEFINE_STATIC_CO_TLS() for the current and leader variables.
    
    I think coroutine-win32.c could get away with __thread because the
    variables are only used in situations where either the stale value is
    correct (current) or outside coroutine context (loading leader when
    current is NULL). Due to the difficulty of being sure that this is
    really safe in all scenarios it seems worth converting it anyway.
    
    Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    Message-Id: <20220307153853.602859-4-stefanha@redhat.com>
    Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    c1fe6943
    History
    coroutine-win32: use QEMU_DEFINE_STATIC_CO_TLS()
    Stefan Hajnoczi authored
    
    Thread-Local Storage variables cannot be used directly from coroutine
    code because the compiler may optimize TLS variable accesses across
    qemu_coroutine_yield() calls. When the coroutine is re-entered from
    another thread the TLS variables from the old thread must no longer be
    used.
    
    Use QEMU_DEFINE_STATIC_CO_TLS() for the current and leader variables.
    
    I think coroutine-win32.c could get away with __thread because the
    variables are only used in situations where either the stale value is
    correct (current) or outside coroutine context (loading leader when
    current is NULL). Due to the difficulty of being sure that this is
    really safe in all scenarios it seems worth converting it anyway.
    
    Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    Message-Id: <20220307153853.602859-4-stefanha@redhat.com>
    Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>