Test case for 'false ownership' of mutex via TID reuse

Test case for 'false ownership' of mutex via TID reuse

[Rich Felker]

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

The attached test case exhibits a bug I'm about to fix in musl, and
which also exists in glibc, whereby happening to get the same TID as a
previous mutex owner who exited with the mutex locked allows the new
thread to unlock the mutex. See also:

http://austingroupbugs.net/view.php?id=755

Sadly it's rather slow and impractical to add to libc-test. I'm not
sure if it's possible to run it in a container with a smaller pid/tid
space to get the reuse to happen sooner. It can also have false
negatives if some other process claims the tid before it gets reused
for a new thread in the test process. Ideas to make the test more
practical and reliable would be nice.

Rich

[-- Attachment #2: false_ownership_2.c --]
[-- Type: text/plain, Size: 621 bytes --]

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

void *f(void *p)
{
	static int init;
	static pthread_mutex_t m;
	pthread_mutexattr_t ma;
	if (!init) {
		init = 1;
		pthread_mutexattr_init(&ma);
		pthread_mutexattr_settype(&ma, PTHREAD_MUTEX_ERRORCHECK);
		pthread_mutex_init(&m, &ma);
		pthread_mutex_lock(&m);
		pthread_mutexattr_destroy(&ma);
		return 0;
	}
	if (!pthread_mutex_unlock(&m)) {
		printf("unlocked mutex via false ownership\n");
		exit(1);
	}
	return 0;
}


int main()
{
	int i;
	pthread_t td;
	for (i=0; i<100000; i++) {
		pthread_create(&td, 0, f, 0);
		pthread_join(td, 0);
	}
	return 0;
}

Re: Test case for 'false ownership' of mutex via TID reuse

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2014-08-16 19:06:11 -0400]:
> 
> http://austingroupbugs.net/view.php?id=755
> 
> Sadly it's rather slow and impractical to add to libc-test. I'm not
> sure if it's possible to run it in a container with a smaller pid/tid
> space to get the reuse to happen sooner. It can also have false
> negatives if some other process claims the tid before it gets reused
> for a new thread in the test process. Ideas to make the test more
> practical and reliable would be nice.

i already had a test for this, but did not commit it because of the
slowness

i could speed up the test by increasing the max user process limit
(RLIMIT_NPROC) and creating a lot of zombies, but that's probably
not practical