From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 54E6B35DA45 for ; Thu, 12 Mar 2026 14:12:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773324741; cv=none; b=ZR8JJN9OAHr0YhnJUrq1QrwhneFz7P9BqLJcFpg/9+9T9ta/jlIXd6/UAfI+FEm7bYNVEmc/a+wvqCvA1JbZzWT9fCK1MAKlj3iedRw/2GsKvjHaQXSYuCfw9UgAUu6wSn9f2CEILp4OBrHgK3NxL28B4Dtq6JJ22HvEY0nhzSg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773324741; c=relaxed/simple; bh=GcSRGAEaK+asjsvJUsssV2kOHmN2MALdL1CHOs5pgsU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=JbQkkCovaTotfWVlko41CvWNZnOb40AwBKcVckRqNxltNB62yygVzotGS5T2Z/O0rwtFguak1IIXih1EZ091U9IFDLytS1f2o/1WXHrqn+LiyrB+uyPyCc2v5sHtZ63Q+d0IFaW/z4cDUswPhm5uvnToIbDjqj+diTVPT87tNW8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XyX5fe42; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XyX5fe42" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773324739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5ZwOOjYIfaKxA6R2Xs83cmil7DoJaSVZFumAzvB1hDA=; b=XyX5fe426ornrPsX1jleYZsCSECUsCgwER639pTSD/uIgjHqIMnJDdU9VggdYz0fAsM7p3 qufDNZE1AG5pWKPUiYGBi3qclZcl0UPlsata0ai8+rd7RqD5SG1lPesWegpa3j0PKFpKQb 7/K+gdi/zcExgvInyQF10BI2ohRR9Vs= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-ftJpxICdPdCHtaF94LQ07w-1; Thu, 12 Mar 2026 10:12:16 -0400 X-MC-Unique: ftJpxICdPdCHtaF94LQ07w-1 X-Mimecast-MFC-AGG-ID: ftJpxICdPdCHtaF94LQ07w_1773324734 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 602F019560A6; Thu, 12 Mar 2026 14:12:12 +0000 (UTC) Received: from fweimer-oldenburg.csb.redhat.com (unknown [10.2.16.175]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8AC9A1800361; Thu, 12 Mar 2026 14:12:07 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: =?utf-8?Q?Andr=C3=A9?= Almeida , 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" Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock In-Reply-To: <3c41d2d6-ccaa-4c09-83fe-f4c5ba898dbf@efficios.com> (Mathieu Desnoyers's message of "Thu, 12 Mar 2026 09:13:47 -0400") References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> <3c41d2d6-ccaa-4c09-83fe-f4c5ba898dbf@efficios.com> Date: Thu, 12 Mar 2026 15:12:05 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 * 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. Thanks, Florian