From: Florian Weimer <fweimer@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "André Almeida" <andrealmeid@igalia.com>,
"Carlos O'Donell" <carlos@redhat.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Peter Zijlstra" <peterz@infradead.org>,
"Rich Felker" <dalias@aerifal.cx>,
"Torvald Riegel" <triegel@redhat.com>,
"Darren Hart" <dvhart@infradead.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"Arnd Bergmann" <arnd@arndb.de>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Michal Hocko" <mhocko@suse.com>,
kernel-dev@igalia.com, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org,
libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [RFC PATCH 0/2] futex: how to solve the robust_list race condition?
Date: Mon, 23 Feb 2026 12:13:59 +0100 [thread overview]
Message-ID: <lhusearzp8o.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <a1e24288-6ffc-438d-8a2a-d152134c9555@efficios.com> (Mathieu Desnoyers's message of "Fri, 20 Feb 2026 18:17:36 -0500")
* Mathieu Desnoyers:
> Trying to find a backward compatible way to solve this may be tricky.
> Here is one possible approach I have in mind: Introduce a new syscall,
> e.g. sys_cleanup_robust_list(void *addr)
>
> This system call would be invoked on pthread_mutex_destroy(3) of
> robust mutexes, and do the following:
>
> - Calculate the offset of @addr within its mapping,
> - Iterate on all processes which map the backing store which contain
> the lock address @addr.
> - Iterate on each thread sibling within each of those processes,
> - If the thread has a robust list, and its list_op_pending points
> to the same offset within the backing store mapping, clear the
> list_op_pending pointer.
>
> The overhead would be added specifically to pthread_mutex_destroy(3),
> and only for robust mutexes.
Would we have to do this for pthread_mutex_destroy only, or also for
pthread_join? It is defined to exit a thread with mutexes still locked,
and the pthread_join call could mean that the application can determine
by its own logic that the backing store can be deallocated.
Thanks,
Florian
next prev parent reply other threads:[~2026-02-23 11:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 20:26 [RFC PATCH 0/2] futex: how to solve the robust_list race condition? André Almeida
2026-02-20 20:26 ` [RFC PATCH 1/2] futex: Create reproducer for robust_list race condition André Almeida
2026-03-12 9:04 ` Sebastian Andrzej Siewior
2026-03-12 13:36 ` André Almeida
2026-02-20 20:26 ` [RFC PATCH 2/2] futex: hack: Add debug delays André Almeida
2026-02-20 20:51 ` [RFC PATCH 0/2] futex: how to solve the robust_list race condition? Liam R. Howlett
2026-02-27 19:15 ` André Almeida
2026-02-20 21:42 ` Mathieu Desnoyers
2026-02-20 22:41 ` Mathieu Desnoyers
2026-02-20 23:17 ` Mathieu Desnoyers
2026-02-23 11:13 ` Florian Weimer [this message]
2026-02-23 13:37 ` Mathieu Desnoyers
2026-02-23 13:47 ` Rich Felker
2026-02-27 19:16 ` André Almeida
2026-02-27 19:59 ` Mathieu Desnoyers
2026-02-27 20:41 ` Suren Baghdasaryan
2026-03-01 15:49 ` Mathieu Desnoyers
2026-03-02 7:31 ` Florian Weimer
2026-03-02 14:57 ` Mathieu Desnoyers
2026-03-02 15:32 ` Florian Weimer
2026-03-02 16:32 ` Mathieu Desnoyers
2026-03-02 16:42 ` Florian Weimer
2026-03-02 16:56 ` Mathieu Desnoyers
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=lhusearzp8o.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=andrealmeid@igalia.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=carlos@redhat.com \
--cc=dalias@aerifal.cx \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=kernel-dev@igalia.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=triegel@redhat.com \
/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.