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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
