[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 1/2] tls: add macros for coroutine-safe TLS variables
From: |
Stefan Hajnoczi |
Subject: |
Re: [RFC 1/2] tls: add macros for coroutine-safe TLS variables |
Date: |
Tue, 26 Oct 2021 14:36:25 +0100 |
On Mon, Oct 25, 2021 at 03:14:36PM +0100, Daniel P. Berrangé wrote:
> On Mon, Oct 25, 2021 at 03:07:15PM +0100, Stefan Hajnoczi wrote:
> > Compiler optimizations can cache TLS values across coroutine yield
> > points, resulting in stale values from the previous thread when a
> > coroutine is re-entered by a new thread.
> >
> > Serge Guelton developed an __attribute__((noinline)) wrapper and tested
> > it with clang and gcc. I formatted his idea according to QEMU's coding
> > style and wrote documentation.
> >
> > These macros must be used instead of __thread from now on to prevent
> > coroutine TLS bugs.
>
> Does this apply to all __thread usage in the QEMU process that can
> be used from coroutine context, or just certain __thread usage ?
>
> Mostly I'm wondering if this is going to have implications on external
> libraries we use. eg if block layer is using librbd.so APIs, is librbd.sp
> safe to use __thread directly in any way it desires ?
There is a theoretical problem but I'm not sure if it will occur in
practice:
If a __thread variable is in an extern function then there's little
risk of the value being cached. The function executes and returns back
to QEMU, never yielding.
The only case I can think of is when the library accesses a __thread
variable, invokes a callback into QEMU, and that callback yields. If the
coroutine is re-entered from another thread and returns back to the
library, then we have a problem. This seems like a very rare case
though.
It gets trickier if the library has the __thread variable in a header
file, because then the compiler may optimize it into a QEMU coroutine
function and cache its value.
Stefan
signature.asc
Description: PGP signature
[RFC 2/2] util/async: replace __thread with QEMU TLS macros, Stefan Hajnoczi, 2021/10/25
Re: [RFC 0/2] tls: add macros for coroutine-safe TLS variables, Philippe Mathieu-Daudé, 2021/10/25
Re: [RFC 0/2] tls: add macros for coroutine-safe TLS variables, Richard Henderson, 2021/10/25