From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [104.156.224.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2604C344DB8 for ; Fri, 27 Mar 2026 16:50:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=104.156.224.86 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774630222; cv=none; b=MN9Ue0bQyX4ozWshvMZcR2KlmRcn+3XoubY1RTVvtzpzUlRJjefZc7IXxSVVAk053w7DQwvGrhjY7iTW6uKGKFXjLgQO7A52b743gXWy6saQrhfjioYYoTXr/LVlF4hbE0mHyF3iFckSyrFH7FjOUK6Z3MZ9qnVksUPmtzcVXSk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774630222; c=relaxed/simple; bh=La3S3V7yC9UH1BkwjGPI24pjaFz62AP1EnF4B05wtRg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZyvA4AYAdjNQrTfMFqxa5m8EwPM6kF7A7xL38UcKSvAQDp+5HTz5TCRDQQBbey5rIndh7MBqvvE6bRWxmngsGqF3ajZgDZz5NHweyeQVRGj63ytdV15aMBDmW1icNalDogN6GOeu8Iz51iKa191nLcg4M9jI4NVoQCYcXI+H/Nw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=aerifal.cx; spf=pass smtp.mailfrom=aerifal.cx; arc=none smtp.client-ip=104.156.224.86 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=aerifal.cx Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aerifal.cx Date: Fri, 27 Mar 2026 12:50:18 -0400 From: Rich Felker To: =?utf-8?B?QW5kcsOp?= Almeida Cc: LKML , Mathieu Desnoyers , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Torvald Riegel , Darren Hart , Thomas Gleixner , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Uros Bizjak , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Subject: Re: [patch v2 00/11] futex: Address the robust futex unlock race for real Message-ID: <20260327165018.GF18807@brightrain.aerifal.cx> References: <20260319225224.853416463@kernel.org> <87bjgackw7.ffs@tglx> <20260326220815.GE18807@brightrain.aerifal.cx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) On Fri, Mar 27, 2026 at 12:42:35AM -0300, André Almeida wrote: > Em 26/03/2026 19:08, Rich Felker escreveu: > > On Thu, Mar 26, 2026 at 10:59:20PM +0100, Thomas Gleixner wrote: > > > On Fri, Mar 20 2026 at 00:24, Thomas Gleixner wrote: > > > > If the functionality itself is agreed on we only need to agree on the names > > > > and signatures of the functions exposed through the VDSO before we set them > > > > in stone. That will hopefully not take another 15 years :) > > > > > > Have the libc folks any further opinion on the syscall and the vDSO part > > > before I prepare v3? > > > > This whole conversation has been way too much for me to keep up with, > > so I'm not sure where it's at right now. > > > > From musl's perspective, the way we make robust mutex unlocking safe > > right now is by inhibiting munmap/mremap/MAP_FIXED and > > pthread_mutex_destroy while there are any in-flight robust unlocks. It > > will be nice to be able to conditionally stop doing that if vdso is > > available, but I can't see using a fallback that requires a syscall, > > as that would just be a lot more expensive than what we're doing right > > now and still not work on older kernels. So I think the only part > > we're interested in is the fully-userspace approach in vdso. > > > > You just need the syscall for the contented case (where you would need a > syscall anyway for a FUTEX_WAKE). > > As Thomas wrote in patch 09/11: > > The resulting code sequence for user space is: > > if (__vdso_futex_robust_list$SZ_try_unlock(lock, tid, &pending_op) != tid) > err = sys_futex($OP | FUTEX_ROBUST_UNLOCK,....); > > Both the VDSO unlock and the kernel side unlock ensure that the pending_op > pointer is always cleared when the lock becomes unlocked. > > > 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. The path where the vdso function is missing would go straight to 3. Does this sound right? Rich