From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) (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 086CE54774 for ; Thu, 12 Mar 2026 13:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.97.179.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773323175; cv=none; b=mzHoGHBzE8PsNQRMPmoK/Mqz/qoUTiuGnf9w0slHTeqFuiLqDuHMNdZQ/pFprlSD6ccCxB1rLnvYzMFoURawm0DLjqyYdweR00D6fmOWq8p0BrZgVCzt/v3BmqS/69uG35iFHn16NADLTNcUo/JXkBUpYmDxtw97iqWLRWF7EL0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773323175; c=relaxed/simple; bh=c+FNef/phnJmWgiqLoVPM3jdy/FHU/4ksrTy5U/Nivw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ti+noY1NhiNDvBPZ1OVwUXtI4ScujlQhGnV49gZcbL4+xB1lGWKNMjSDCuZWzcrdJEbbFsFY6UWh7SAS+ofzzE/VHHt3DpOuPSjVB3B5bwmKSjScrppCUAhH6pFdHNIUE92IwrBbMwVmPru4E19OtHojWc1emUiDijT6g9L27TM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=b3DhHAGK; arc=none smtp.client-ip=213.97.179.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="b3DhHAGK" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6ICjxYbIZsjTxFoCfVKWw/Ic80tNyB6uJZ6tzCwgbvU=; b=b3DhHAGKN1LAMDPl+k4f7Xg/ZR uXI4v9JYRsPhsURE9Et2TuaOFhVs6SF3ctBY0gVvk3rNTgIjhUyNgM9c5rLQzEZOun2RLfSSGlYI8 Zut91nfa4CwfZ67hFlGSQr5pLND+3FoB2qj7pGmkWRAY+VBmPwgdTfuMmjHN6dUVzDDkaMl4F76kx hn/PU4vcskYGWIBbI9bga20/ZmIG7eqDg1ZBeWiOcAbq1Dh1uVhatRZviNxB7VDXENUwHQ21yhDDB mxHsl5MmAT/UnIBmdC0JIQOcZD4l2mgUotIxgY/wcMX31vuzeE58nwMpKGA3lcskqp31kLwaTS7g0 AV6Njf7w==; Received: from [187.57.51.179] (helo=[192.168.15.100]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1w0gMa-00EWR9-V8; Thu, 12 Mar 2026 14:46:09 +0100 Message-ID: <2993f778-c4f4-4aa8-8e42-1dca4d5e29e1@igalia.com> Date: Thu, 12 Mar 2026 10:46:03 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock To: Mathieu Desnoyers Cc: linux-kernel@vger.kernel.org, Carlos O'Donell , Sebastian Andrzej Siewior , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Thomas Gleixner , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Mathieu, Thanks for your patch! Em 11/03/2026 15:54, Mathieu Desnoyers escreveu: > This vDSO unlocks the robust futex by exchanging the content of > *uaddr with 0 with a store-release semantic. If the futex has > waiters, it sets bit 1 of *op_pending_addr, else it clears > *op_pending_addr. Those operations are within a code region > known by the kernel, making them safe with respect to asynchronous > program termination either from thread context or from a nested > signal handler. > > Expected use of this vDSO: > > if ((__vdso_robust_futex_unlock((u32 *) &mutex->__data.__lock, &pd->robust_head.list_op_pending) > & FUTEX_WAITERS) != 0) > futex_wake((u32 *) &mutex->__data.__lock, 1, private); > WRITE_ONCE(pd->robust_head.list_op_pending, 0); > [...] > + > +u32 __vdso_robust_futex_unlock(u32 *uaddr, uintptr_t *op_pending_addr) > +{ The interface that I would propose here would be a bit more "generic" or "flexible": __vdso_robust_futex_unlock(void *uaddr, int uval, struct robust_list_head *head, unsigned int flags) First because we have FUTEX2_SIZE's, so uaddr could have different size here. And we need `flags` to determine the size. Also `flags` is a great way to expand this funciton in the future without the need to create __vdso_robust_futex_unlock2(). I would also have `uval` instead of `val = 0`, because even though the most common semanthics for futex is that (LOCK_FREE == 0), futex has no predetermined semanthics of what each value means, and the userspace is free to choose what value they want to choose for a free lock. And as you already highlighted in the other thread, I agree that `struct robust_list_head` instead of just the op_pending address is more flexible as well. Thanks!