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 8A1C1175A68 for ; Thu, 12 Mar 2026 14:14:54 +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=1773324896; cv=none; b=lOYs7EW0rGiZi7mXvwjyHVwvjsKD9gMCUvjoT70CFKDWJYED3qFc1Zb9xal8H4w97t1Bu7/AA3V+p1o/GdtM7StW10sKuZS/mZ1NlkyMlKk+wq+ETxGpcdGdlfXascbRmOumYmlTFeCF/Ct7DnusmvqfYHIYl9g5WYdtk82SleY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773324896; c=relaxed/simple; bh=GxRec2XNgcCR5Hab5HXyJmws+mwV5CZh/ZwYaLHigp0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rmZQljtSQst0n5VzmgejCx1syQ1ym5jgnhzh6XM13FNT6YwvxW0SPfamqU0JuaQMTxJMyf58dYnkUDrzr0uqwQDhGBJ4Ti3s21XIXLEpprVlxRzwOgjQBPtnk42DaYzI4f1Q2uhC+/skV3k5oPSCz6D5x2YL29wT+od6CDTYkuI= 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=VMGpCClr; 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="VMGpCClr" 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=W3Tm81LCvf3l6A56UN5jqZGL1/Cm1Ng65C053g9FRoY=; b=VMGpCClr8eXh1/+FVQn7EEs5FM QUkZfVvF9cwI1v44/wk6JW8K6xF9CIOz0d7oYA3pdsEx53ruznq61Qus5zhsU8A5m3X6q7rpeb5Lv nN89vBQil+tSy07rbhSyinx2xsgwnBQ4yCVTu547UpWuM055R2Xao/A3GcjBfd2mWmlqF+h46env0 bW/qH7/hQZlQo4iaGXP+wL8MJG18wjavkv9/ZlgT6hB909qXhcJZR9S9VEyISpPVKjEjGy6ay3Ew7 REV6gBQahVaBe9uuvvdWNiG34APE9PIg7QcAwtIgayfoCIfiqbhcty1xAsKNUQ/hhwJj+wyVXmdw8 FyELamTw==; 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 1w0goJ-00EX3s-9i; Thu, 12 Mar 2026 15:14:47 +0100 Message-ID: Date: Thu, 12 Mar 2026 11:14:39 -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: Florian Weimer , Mathieu Desnoyers Cc: linux-kernel@vger.kernel.org, Carlos O'Donell , Sebastian Andrzej Siewior , Peter Zijlstra , 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> <3c41d2d6-ccaa-4c09-83fe-f4c5ba898dbf@efficios.com> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Em 12/03/2026 11:12, Florian Weimer escreveu: > * Mathieu Desnoyers: > >> On 2026-03-12 04:49, Florian Weimer wrote: >>> * Mathieu Desnoyers: >>> >>>> + * 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); >>> The comment could perhaps say that pd->robust_head is the >>> thread-specific robust list that has been registered with >>> set_robust_list. > >> Good point. Considering that "robust_head" is the thread-specific >> robust list registered with set_robust_list, I wonder if passing >> &robust_head->list_op_pending is the right ABI choice there, >> or if we should rather pass the robust_head pointer and offset it >> within the vDSO. > > I think set_robust_list has pointer and size arguments, so we should > pass those two at least. > The size argument for set_robust_list() has never been useful it seems, it just checks if (size == sizeof(*head)). I believe it was added in case the struct would ever be expanded, but that never happened and with set_robust_list2() in the horizon this is even less likely to ever happen.