The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: "Rich Felker" <dalias@aerifal.cx>,
	"André Almeida" <andrealmeid@igalia.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
	"Carlos O'Donell" <carlos@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Florian Weimer" <fweimer@redhat.com>,
	"Torvald Riegel" <triegel@redhat.com>,
	"Darren Hart" <dvhart@infradead.org>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	"Uros Bizjak" <ubizjak@gmail.com>,
	"Thomas Weißschuh" <linux@weissschuh.net>
Subject: Re: [patch v2 00/11] futex: Address the robust futex unlock race for real
Date: Sat, 28 Mar 2026 13:41:20 +0100	[thread overview]
Message-ID: <87se9kazyn.ffs@tglx> (raw)
In-Reply-To: <20260327165018.GF18807@brightrain.aerifal.cx>

On Fri, Mar 27 2026 at 12:50, Rich Felker wrote:
> On Fri, Mar 27, 2026 at 12:42:35AM -0300, André Almeida wrote:
>> So you call the vDSO first. If it fails, it means that the lock is contented
>> and you need to call futex(). It will wake a waiter, release the lock and
>> clean list_op_pending.
>
> So would we use the vdso function presence as signal that this
> functionality is available? In that case, I think what we would do is:
>
> 1. Try an uncontended unlock using the vdso.
> 2. If it fails, attempt FUTEX_ROBUST_UNLOCK.
> 3. If that fails (note: this could be due to seccomp!), fallback to
> the old kernel code path, holding off any munmap/etc. while we perform
> the userspace unlock.

FUTEX_ROBUST_UNLOCK is a flag similar to FUTEX_PRIVATE which is or'ed on
FUTEX_WAKE, FUTEX_WAKE_BITSET and FUTEX_UNLOCK_PI to tell the kernel
that it should do the unlock for FUTEX_WAKE* and the pointer clearing
for all three variants. UNLOCK_PI already does the contended unlock
today. So yeah, seccomp might refuse, but then it might refuse plain
FUTEX_WAKE* too which leaves you in a creek without a paddle.

If the kernel supports ROBUST UNLOCK, but does not expose the VDSO
function or lacks VDSO at all, you can still use the syscall for the
contended case unlock and limit your user space workaround to the
successful uncontended unlock case by using try_cmpxchg() in the library
code, which is obviously not covered by the fixup as the kernel does not
know about it.

I briefly pondered to allow user space to register the critical section
(that's how I evaluated the approach in the first place).

But that's a can of worms we should not open at all because the kernel
needs to know the registers used (to retrieve the pending op pointer)
and the condition for successful uncontended unlock. Keeping that in
sync would be a nightmare. With the VDSO that's not an issue as the
kernel can keep the changes synchronized and validate with selftests
that it actually is correct.

Thanks,

        tglx





      reply	other threads:[~2026-03-28 12:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 23:24 [patch v2 00/11] futex: Address the robust futex unlock race for real Thomas Gleixner
2026-03-19 23:24 ` [patch v2 01/11] futex: Move futex task related data into a struct Thomas Gleixner
2026-03-20 14:59   ` André Almeida
2026-03-19 23:24 ` [patch v2 02/11] futex: Move futex related mm_struct " Thomas Gleixner
2026-03-20 15:00   ` André Almeida
2026-03-19 23:24 ` [patch v2 03/11] futex: Provide UABI defines for robust list entry modifiers Thomas Gleixner
2026-03-20 15:01   ` André Almeida
2026-03-19 23:24 ` [patch v2 04/11] uaccess: Provide unsafe_atomic_store_release_user() Thomas Gleixner
2026-03-20  9:11   ` Peter Zijlstra
2026-03-20 12:38     ` Thomas Gleixner
2026-03-20 16:07   ` André Almeida
2026-03-19 23:24 ` [patch v2 05/11] x86: Select ARCH_STORE_IMPLIES_RELEASE Thomas Gleixner
2026-03-20 16:08   ` André Almeida
2026-03-19 23:24 ` [patch v2 06/11] futex: Cleanup UAPI defines Thomas Gleixner
2026-03-20 16:09   ` André Almeida
2026-03-19 23:24 ` [patch v2 07/11] futex: Add support for unlocking robust futexes Thomas Gleixner
2026-03-20 17:14   ` André Almeida
2026-03-26 22:23     ` Thomas Gleixner
2026-03-27  0:48       ` André Almeida
2026-03-19 23:24 ` [patch v2 08/11] futex: Add robust futex unlock IP range Thomas Gleixner
2026-03-20  9:07   ` Peter Zijlstra
2026-03-20 12:07     ` Thomas Gleixner
2026-03-27 13:24   ` Sebastian Andrzej Siewior
2026-03-27 16:19     ` Thomas Gleixner
2026-03-19 23:24 ` [patch v2 09/11] futex: Provide infrastructure to plug the non contended robust futex unlock race Thomas Gleixner
2026-03-20 13:35   ` Thomas Gleixner
2026-03-19 23:24 ` [patch v2 10/11] x86/vdso: Prepare for robust futex unlock support Thomas Gleixner
2026-03-19 23:25 ` [patch v2 11/11] x86/vdso: Implement __vdso_futex_robust_try_unlock() Thomas Gleixner
2026-03-20  7:14   ` Uros Bizjak
2026-03-20 12:48     ` Thomas Gleixner
2026-03-26 21:59 ` [patch v2 00/11] futex: Address the robust futex unlock race for real Thomas Gleixner
2026-03-26 22:08   ` Rich Felker
2026-03-27  3:42     ` André Almeida
2026-03-27 10:08       ` Thomas Gleixner
2026-03-27 16:50       ` Rich Felker
2026-03-28 12:41         ` Thomas Gleixner [this message]

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=87se9kazyn.ffs@tglx \
    --to=tglx@kernel.org \
    --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=fweimer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=triegel@redhat.com \
    --cc=ubizjak@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox