Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 May 2018 10:06:17 +1000
From: Patrick Oppenlander <patrick.oppenlander@...il.com>
To: musl@...ts.openwall.com
Subject: Re: pthread cancel cleanup and pthread_mutex_lock

I accidentally hit send before I finished typing..

> I've recently been running some of the open posix testsuite tests from
> the linux test project.
>
> One particular test has been giving me headaches:
> https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_mutex_init/1-2.c
>
> There are a couple of different tests in there but the most
> interesting one is the deadlock test which does the following:
>
> Thread A:          Thread B:
> pthread_create
>                    pthread_cleanup_push(...)
>                    pthread_mutex_lock(M)
>                    pthread_setcanceltype(ASYNC)
>                    pthread_setcancelstate(ENABLE)
                     pthread_mutex_lock(M) <-- blocks here
  pthread_cancel(B)
  pthread_join(B)

The test then expects the cleanup handler to run and unlock mutex M
allowing thread B to run to completion and the join to succeed.

I've run this test with musl, glibc and on some different platforms
with varying results:

x86_64 linux 4.16.11, glibc: test runs to completion
x86_64 linux 4.16.11, musl: deadlock (cleanup handler doesn't run)
arm linux 4.16.5, musl: test runs to completion

I'm not even sure that this test is valid -- I can't find any
documentation which says that pthread_mutex_lock is a cancellation
point, or that you're allowed to call pthread_mutex_unlock from an
async cancel handler.

However, it's still concerning to see different results on different platforms.

What's the expected behaviour here?

Patrick

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ