__thread and fork() is a big no-no

[Eric Paris <eparis@redhat.com>]

Looking at the set*createcon cache patch we realized it wasn't working
right.  Quickly putting together a test program we found that:

static __thread pid_t tid = 0;

int main(void)
{
        pid_t child;
 
        tid = syscall(__NR_gettid);
        printf("parent=%d\n", tid);
 
        child = fork();
        if (child == 0)
                printf("child=%d\n", tid);
         return 0;
}

We expected to get results like:
parent=6500
child=0

Instead you find result like:
parent=6500
child=6500

Thread local storage is NOT initialized across fork().  It's always been
known that threads and fork() don't play well together:
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them

But we weren't threading the parent or the child, so we expected it to
work.  Instead we've had to add a call to pthread_atfork() which
explicitly resets tid at fork.  Basically just:

static void clear(void)
{
        tid = 0;
}
 
int main(void)
{
...
        int rc;
        rc = pthread_atfork(NULL, NULL, clear);
        if (rc)
                return rc;
...
}

We actually call this ptherad_atfork() inside the init_procattr()
function which is only called once.  I'm wondering if we suffer from the
same problems with __thread variables and fork() in the library callers
elsewhere in the code.  I'll take a look.

Just letting folks know something interesting we found yesterday, in
case they find it interesting...

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.