[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEg67GmfoPSOimj00AQ8LMo3QbYuEeiqzqU-O+uG5zUkcfYxjw@mail.gmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
