From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9C983EE1E2 for ; Mon, 16 Mar 2026 20:29:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773692993; cv=none; b=djjr6Pv/ZtNHFgf1K3zx/ZfUwYeket3IsPZJ99vukmUWyr/sU/5NEo49uu8+p3FGXof9TgdG6tG6I2cWSpv1GhoXbTLpVIYsmYXD4cLZ+VSEs00MdhHhcJcZqPDx1lnM49lNmdS/wCcb+y6WRJAj6OvyU8nhLe+yIuuxdDYKXNw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773692993; c=relaxed/simple; bh=yGQNWPi/ozF3w43bhejcu5B6wXN855FHYN6ZCdeFGVo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=LSmdGDh6eBHg8Vw9LZqz3fUX2gIbXTawvaf3pQbJFqsK/hOF7Xf+HKtBbqTJPlRtfVQlbsi/0T0E5EahUZH2HOHtNW2Yjfdl8nk8hkxbY9O7hTDLmsO3HJA/f+P5pXck4XGtshGSaUIPVtnEhowWkUg6WXGNa3cuJJ3H3x1Noo0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G20to3Si; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G20to3Si" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0FD4C19421; Mon, 16 Mar 2026 20:29:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773692993; bh=yGQNWPi/ozF3w43bhejcu5B6wXN855FHYN6ZCdeFGVo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G20to3SiCt3qwtLDoLv8qh+PqtODpAEq7/B71h4RRyjAmyQTjLBncb0PRI+MivqFf 55o3ndzt0idmuSMhQCaDEpBtusAb17J4IqvPI3ylKe+t+VSbudv+zCw+GS7l8TRjTK RA+cW5SQkl3USdhpyLUZl3JEKJutLmEyLrtaIbQqonnD9MW4hOvU/eYbNAm3h0/z6U cDQED0z/gaCiRY0e6gQ6gdM5mc99YbQkiH/tAr1Qyq6GeZ8N3sJNmE8WRUYmROdlYk 5tXo79rpuwtzDl3fkJ6jHht+1exbqd4r7iYTK9FUWTJ7Kl30rka6/YGMIthXTTHOtB AHaYCmjnryCyQ== From: Thomas Gleixner To: Mathieu Desnoyers , LKML Cc: =?utf-8?Q?Andr=C3=A9?= Almeida , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [patch 6/8] futex: Provide infrastructure to plug the non contended robust futex unlock race In-Reply-To: <03f563a3-caaa-4b72-bedb-b2b2a316b545@efficios.com> References: <20260316162316.356674433@kernel.org> <20260316164951.345973752@kernel.org> <03f563a3-caaa-4b72-bedb-b2b2a316b545@efficios.com> Date: Mon, 16 Mar 2026 21:29:50 +0100 Message-ID: <87y0jro6v5.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Mar 16 2026 at 14:35, Mathieu Desnoyers wrote: > On 2026-03-16 13:13, Thomas Gleixner wrote: >> When the FUTEX_ROBUST_UNLOCK mechanism is used for unlocking (PI-)futexes, >> then the unlock sequence in user space looks like this: >> >> 1) robust_list_set_op_pending(mutex); >> 2) robust_list_remove(mutex); >> >> lval = gettid(); >> 3) if (atomic_try_cmpxchg(&mutex->lock, lval, 0)) >> 4) robust_list_clear_op_pending(); >> else >> 5) sys_futex(OP | FUTEX_ROBUST_UNLOCK, ....); >> >> That still leaves a minimal race window between #3 and #4 where the mutex >> could be acquired by some other task, which observes that it is the last >> user and: >> >> 1) unmaps the mutex memory >> 2) maps a different file, which ends up covering the same address >> >> When then the original task exits before reaching #6 then the kernel robust > > "... before reaching #4 ...". > > [...] > >> >> As this is only relevant when the task was interrupted in user space, this >> is tied to RSEQ and the generic entry code as RSEQ keeps track of user >> space interrupts unconditionally even if the task does not have a RSEQ >> region installed. That makes the decision very lightweight: >> >> if (current->rseq.user_irq && within(regs, unlock_ip_range)) >> futex_fixup_robust_unlock(regs); > > Nice trick to re-use the rseq infra, but where is the added dependency > on CONFIG_RSEQ=y ? Here: +config FUTEX_ROBUST_UNLOCK + def_bool FUTEX && HAVE_GENERIC_VDSO && GENERIC_IRQ_ENTRY && RSEQ && HAVE_FUTEX_ROBUST_UNLOCK