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 EE5A7282F02 for ; Fri, 13 Mar 2026 08:20:43 +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=1773390045; cv=none; b=OLiwZzuJYCsbaHbCIEzItqS18yp6C71sBXpK0pYM/CIygGgnybsajkuhZQR76nS0bESWhiwv/ailbTvyygD3B8szYHv74AkPAXvcasLG151W7T/juuvwT0ltWo5sgQLF+euUYn6K5Q/TTxgTm15ePdB0bDedUTeq4Mz/W5cuI1c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773390045; c=relaxed/simple; bh=JcYPMY56rucyzLngVzzM2f2Tg6Y5G0h0cm/wu/ap4JY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=f1ZZkWH3nG2ZCB6JRG7eZ1DznaOMybpFf1CniUH/CaPz2bk8aPKsfK9Pqtw1btIgN1rJraqSWzu+6mcivY2ftcV2WlNPuWRmYFnYeXmgFTsIDwiZrgH1hWbOqHp7dFOLqC4c8ekJ2a2uWA9/eBMvSjuZn4mDtADiNZi/Ka7RhBQ= 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=E/Lom/O3; 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="E/Lom/O3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773390042; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uuZFS6JF0kj5aqRvscYRGRPVBsgYq0e50MlQshFkuHE=; b=E/Lom/O3XrLaBISz3q138XFKhBqcHwcB/XhpgZrj4B7eG4abpvkvCqoNGfmFBfTqhssHD6 nV8Euum3XtveF0Sbwu8+VRe93+5fG4gHAtJ7mHfR4Llx48oUVhj1YegKWWd14A5wAVIGsn vYhFAO0WjPuSRcIUu3gOGOoohYuOuGs= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-353-ObuFnyveNjuVBLf2Xc3-qg-1; Fri, 13 Mar 2026 04:20:28 -0400 X-MC-Unique: ObuFnyveNjuVBLf2Xc3-qg-1 X-Mimecast-MFC-AGG-ID: ObuFnyveNjuVBLf2Xc3-qg_1773390027 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9A970180047F; Fri, 13 Mar 2026 08:20:25 +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 78D881800351; Fri, 13 Mar 2026 08:20:19 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Thomas Gleixner , =?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 , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock In-Reply-To: <86f1a404-905c-4d52-862b-4f93c5dae6a4@efficios.com> (Mathieu Desnoyers's message of "Thu, 12 Mar 2026 15:16:38 -0400") References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> <2993f778-c4f4-4aa8-8e42-1dca4d5e29e1@igalia.com> <87pl58q2x6.ffs@tglx> <86f1a404-905c-4d52-862b-4f93c5dae6a4@efficios.com> Date: Fri, 13 Mar 2026 09:20:17 +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; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 * Mathieu Desnoyers: > On 2026-03-12 15:10, Thomas Gleixner wrote: >> On Thu, Mar 12 2026 at 10:04, Mathieu Desnoyers wrote: >>> On 2026-03-12 09:46, Andr=C3=A9 Almeida wrote: >>>> 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) >>> >>> I agree on adding explicit "uval" and pointer to robust list head, >>> I'm not convinced that the rest is an improvement. >>> >>> This would require the caller to deal with errors, making it >>> more complex than a simple replacement for atomic xchg/cmpxchg. >>> >>> "flags" could be unsupported, so the handler would have to deal with >>> -EINVAL. >> What's the problem with that? pthread_mutex_unlock() has a return >> value >> too. > > My aim is to use this vDSO as a replacement for atomic xchg and atomic > cmpxchg within library code. I am trying to make the transition as > straightforward as possible considering that this is a design bug > fix. > > If adding error handling at that precise point of the libc robust mutex > unlock code is straightforward, I don't mind internally checking flags > and returning -EINVAL, but I'd want to hear about preference from the > libc people on this topic beforehand. As a deallocation operation, unlock must not fail. We would therefore ignore the error return value (because EINVAL can only happen for invalid arguments), or we'd terminate the process on failure. Thanks, Florian