From: Jiri Slaby <jirislaby@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org, boqun.feng@gmail.com,
bristot@redhat.com, bsegall@google.com, dietmar.eggemann@arm.com,
jstultz@google.com, juri.lelli@redhat.com, longman@redhat.com,
mgorman@suse.de, mingo@redhat.com, rostedt@goodmis.org,
swood@redhat.com, vincent.guittot@linaro.org,
vschneid@redhat.com, will@kernel.org
Subject: Re: [PATCH v3 7/7] locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock.
Date: Mon, 15 Jan 2024 13:54:32 +0100 [thread overview]
Message-ID: <c737a604-d441-49c6-a5cd-ef01e9f2a454@kernel.org> (raw)
In-Reply-To: <9f75eb59-9b7a-4b49-9081-e6a3cbb00187@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
On 15. 01. 24, 12:52, Jiri Slaby wrote:
> On 15. 01. 24, 12:40, Jiri Slaby wrote:
>> On 15. 09. 23, 17:19, Peter Zijlstra wrote:
>>> On Fri, Sep 15, 2023 at 02:58:35PM +0200, Thomas Gleixner wrote:
>>>
>>>> I spent quite some time to convince myself that this is correct. I was
>>>> not able to poke a hole into it. So that really should be safe to
>>>> do. Famous last words ...
>>>
>>> IKR :-/
>>>
>>> Something like so then...
>>>
>>> ---
>>> Subject: futex/pi: Fix recursive rt_mutex waiter state
>>
>> So this breaks some random test in APR:
>>
>> From
>> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:G/apr/standard/x86_64:
>> testprocmutex : Line 122: child did not terminate with success
>>
>> The child in fact terminates on
>> https://github.com/apache/apr/blob/trunk/test/testprocmutex.c#L93:
>> while ((rv = apr_proc_mutex_timedlock(proc_lock, 1))) {
>> if (!APR_STATUS_IS_TIMEUP(rv))
>> exit(1); <----- here
>>
>> The test creates 6 children and does some
>> pthread_mutex_timedlock/unlock() repeatedly (200 times) in parallel
>> while sleeping 1 us inside the lock. The timeout is 1 us above. And
>> the test expects all them to fail (to time out). But the time out does
>> not always happen in 6.7 (it's racy, so the failure is semi-random:
>> like 1 of 1000 attempts is bad).
>
> This is not precise as I misinterpreted. The test is: either it succeeds
> or times out.
>
> But since the commit, futex() yields 22/EINVAL, i.e. fails.
A simplified reproducer attached (in particular, no APR anymore). Build
with -pthread, obviously. If you see
BADx rv=22
that's bad.
regards,
--
js
suse labs
[-- Attachment #2: pokus2.c --]
[-- Type: text/x-csrc, Size: 1744 bytes --]
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/time.h>
#include <sys/wait.h>
#define MAX_WAIT_USEC (1000*1000)
#define CHILDREN 16
#define MAX_ITER 200
#define NS_PER_S 1000000000
static pthread_mutex_t *proc_lock;
static void child()
{
int rv, i = 0;
do {
int wait_usec = 0;
struct timespec abstime;
clock_gettime(CLOCK_REALTIME, &abstime);
abstime.tv_nsec += 1000;
if (abstime.tv_nsec >= NS_PER_S) {
abstime.tv_sec++;
abstime.tv_nsec -= NS_PER_S;
}
while ((rv = pthread_mutex_timedlock(proc_lock, &abstime))) {
if (rv != ETIMEDOUT) {
fprintf(stderr, "BADx rv=%d\n", rv);
abort();
}
if (++wait_usec >= MAX_WAIT_USEC)
abort();
}
//fprintf(stderr, "[%d] rv=%d\n", getpid(), rv);
i++;
usleep(1);
if (pthread_mutex_unlock(proc_lock))
abort();
} while (i < MAX_ITER);
exit(0);
}
int main(int argc, char **argv)
{
proc_lock = mmap(NULL, sizeof(*proc_lock),
PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED,
-1, 0);
pthread_mutexattr_t mattr;
pthread_mutexattr_init(&mattr);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_SHARED);
pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST);
pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutex_init(proc_lock, &mattr);
pthread_mutexattr_destroy(&mattr);
for (unsigned a = 0; a < CHILDREN; a++)
if (!fork())
child();
for (unsigned a = 0; a < CHILDREN; a++)
wait(NULL);
pthread_mutex_destroy(proc_lock);
return 0;
}
next prev parent reply other threads:[~2024-01-15 12:54 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 16:22 [PATCH v3 0/7] locking/rtmutex: Avoid PI state recursion through sched_submit_work() Sebastian Andrzej Siewior
2023-09-08 16:22 ` [PATCH v3 1/7] sched: Constrain locks in sched_submit_work() Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2023-09-08 16:22 ` [PATCH v3 2/7] locking/rtmutex: Avoid unconditional slowpath for DEBUG_RT_MUTEXES Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] " tip-bot2 for Sebastian Andrzej Siewior
2023-09-08 16:22 ` [PATCH v3 3/7] sched: Extract __schedule_loop() Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2023-09-08 16:22 ` [PATCH v3 4/7] sched: Provide rt_mutex specific scheduler helpers Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2023-09-08 16:22 ` [PATCH v3 5/7] locking/rtmutex: Use " Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] " tip-bot2 for Sebastian Andrzej Siewior
2023-09-08 16:22 ` [PATCH v3 6/7] locking/rtmutex: Add a lockdep assert to catch potential nested blocking Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] " tip-bot2 for Thomas Gleixner
2023-09-08 16:22 ` [PATCH v3 7/7] locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock Sebastian Andrzej Siewior
2023-09-09 18:29 ` Peter Zijlstra
2023-09-11 14:11 ` Peter Zijlstra
2023-09-12 10:57 ` Peter Zijlstra
2023-09-12 11:26 ` Sebastian Andrzej Siewior
2023-09-12 11:17 ` Sebastian Andrzej Siewior
2023-09-12 11:24 ` Peter Zijlstra
2023-09-12 11:25 ` Sebastian Andrzej Siewior
2023-09-12 11:25 ` Peter Zijlstra
2023-09-12 11:28 ` Sebastian Andrzej Siewior
2023-09-15 12:58 ` Thomas Gleixner
2023-09-15 13:15 ` Sebastian Andrzej Siewior
2023-09-15 15:19 ` Peter Zijlstra
2023-09-15 18:59 ` Thomas Gleixner
2023-09-19 11:03 ` Sebastian Andrzej Siewior
2023-09-20 7:36 ` [tip: locking/core] futex/pi: Fix recursive rt_mutex waiter state tip-bot2 for Peter Zijlstra
2024-01-15 11:40 ` [PATCH v3 7/7] locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock Jiri Slaby
2024-01-15 11:52 ` Jiri Slaby
2024-01-15 12:16 ` Sebastian Andrzej Siewior
2024-01-15 12:54 ` Jiri Slaby [this message]
2024-01-15 15:32 ` Yann Ylavic
2024-01-15 18:33 ` Sebastian Andrzej Siewior
2024-01-16 7:07 ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c737a604-d441-49c6-a5cd-ef01e9f2a454@kernel.org \
--to=jirislaby@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=swood@redhat.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.