Re: [RFC 1/2] tls: add macros for coroutine-safe TLS variables

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]