From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B8ECC3793D5 for ; Tue, 17 Mar 2026 09:36:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773740212; cv=none; b=Fs3UpCtlnsTBh1TKDAZw5aQSMFUVgMtiAT8YB2yu6PSbhekvno0nY5TOVRPmYY60m6ZLXqWuq3iCl9ntLsXpctmfyWFWqWBXI6go9pNfB0Xg1VbvQFxXfpsIn1E44kgEjOT5NyaSOYX+EpfiQu2AP2I242cgAsH8XYro+B+9ZFQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773740212; c=relaxed/simple; bh=4SCDOiq9rl4foqU1rtIybvEj4LfxaerqJSjx6s3Exzs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=B0V8MTxnWw3dbIEseGnUrW6RGORqDQ8Aq5JKrAcMbGG3T6MPJldT2JFDBpDZwLlAX8K3gtLapwuFiP6TWv2mNqbPX3BS2yfnurVd3telVqUAgltqij6Ync4Y36IiLuYGCwC9hqTvVujY+IeYyEdKAqcCxjLw0I4fQQCmxvUNq2c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a5dCEwfV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a5dCEwfV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03175C19425; Tue, 17 Mar 2026 09:36:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773740212; bh=4SCDOiq9rl4foqU1rtIybvEj4LfxaerqJSjx6s3Exzs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=a5dCEwfVxyCaqjQQjippFrAhiAU83cJuXn5bnxoot39DPF3j6lXs0n2/WSPBBXGcX 3ta2Xu7Jc8M/BEaA1CWy1ahPe8pyPp1DU81+qu6DCNOFqt2OZdZHoL3BarRwStXmhJ ffD30kv/k8iaBeZz4umRTTNTk1ywGAkFQYffovgfUGp6dk5Bf4TKZuxcbF0fjklvMO 73g1hSgPGH9jO8rbgyDKEAZjp+0KVKadwBmqByKBOUd9U6Qf8zGldiOGP8wMebz0Lx wCGj+gZdIpPvykM5VRgvjWgcrf/gT9Zcs6Roa/v07D0AMTaXTMD87E9OXDuxuvg27w d+4c7ryN72nSw== From: Thomas Gleixner To: Florian Weimer Cc: LKML , Mathieu Desnoyers , =?utf-8?Q?Andr=C3=A9?= Almeida , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [patch 8/8] x86/vdso: Implement __vdso_futex_robust_try_unlock() In-Reply-To: References: <20260316162316.356674433@kernel.org> <20260316164951.484640267@kernel.org> Date: Tue, 17 Mar 2026 10:36:48 +0100 Message-ID: <87ecliokzz.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Mar 17 2026 at 09:28, Florian Weimer wrote: > * Thomas Gleixner: > >> Arguably this could be avoided by providing separate functions and making >> the IP range for the quick check in the exit to user path cover the whole >> text section which contains the two functions. But that's not a win at all >> because: >> >> 1) User space needs to handle the two variants instead of just >> relying on a bit which can be saved in the mutex at >> initialization time. > > I'm pretty sure that on the user-space side, we wouldn't have > cross-word-size operations (e.g., 64-bit code working on both 64-bit and > 32-bit robust mutexes). Certainly not within libcs. The other point > about complexity is of course still valid. Right, I know that no libc implementation supports such an insanity, but the kernel unfortunately allows to do so and it's used in the wild :( So we have to deal with it somehow and the size modifier was the most straight forward solution I could come up with. I'm all ears if someone has a better idea. That said, do you see any issue from libc size versus extending the WAKE/UNLOCK_PI functionality with that UNLOCK_ROBUST functionality? I did some basic performance tests in the meanwhile with an open coded mutex implementation. I can't observe any significant difference between doing the unlock in user space or letting the kernel do it, but that needs of course more scrunity. Thanks, tglx