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 5D9BD186284 for ; Fri, 29 May 2026 15:37:07 +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=1780069032; cv=none; b=H0YCrvlpGDH9c8Q3J6hesF1cv+nGau23gqqbN3MYHzI+W16ZrTba08uYzEz5NcHD0In7LPTMpeeIQU5WY9i7PRQ8dWrUon6UvyiROAyqC8F5pa2mJkl3WGyfShB2Hqg3KU1Fn302Iomnkano8DnqwKiaGjAvcEEqhBGRMzlcHfQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780069032; c=relaxed/simple; bh=FcrRL49a8Q0+gB2mPq3mm4YftaNL1Iecs0JrHBvz7c4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=r317UABmHTsUW9DpK2+7bLiOqyoWS5fRRm51NcQn8g3oHs71hZClhDMwaJexO+cjEvpPnKgmaRTpNad2PAlICj6Rnoz6V6F/WsdMjOs3A74PjikvX7557zXZgsVctQ5ecAUIyTO0eJFDRNCcwXlVNH6roWmqdFLeCboGP+DfJlg= 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=Q2ow53EE; 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="Q2ow53EE" 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=zjq7bfxDbJOeIX4Uvy58G/99XxWjk1XpfMwyKk68vPs=; b=Q2ow53EE4WdATsrDXw+B5tyWxx liCLhR9/78eIR4j4bQLLLZP8RJyQkxpTdGtKFu4RnTwvO67s8h+qNoPzpEJmDJ8S7IY3Ol6tX3tKI X9pMkqv/nFa3hngdRvgWY3mcbmGLhnirY1FBJsBHjh6T3afT6PcUSQNbNYl3wKCzPak15we1fW9WW gbEAevslOpbhU8XcLuUVUjfCNvO9c0BZBFESqPZPw0zudpbfA2uOmJguyqTMxjBggFT5iGhrUWfeZ EAOQDSUaduchjRZrakErkX8DHRr0BHtdEnymWQng07OYJcBrnxVdZf/ZldNKpO0X5c5nl4TUduVoW MtvM2+AQ==; Received: from [179.118.191.12] (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 1wSzGK-009vZN-Rt; Fri, 29 May 2026 17:36:41 +0200 Message-ID: Date: Fri, 29 May 2026 12:36:31 -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 Subject: Re: [patch V4 12/14] x86/vdso: Implement __vdso_futex_robust_try_unlock() To: Thomas Gleixner Cc: Mathieu Desnoyers , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , LKML , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Uros Bizjak , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , kernel-dev@igalia.com References: <20260402151131.876492985@kernel.org> <20260402151940.418303527@kernel.org> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <20260402151940.418303527@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Em 02/04/2026 12:22, Thomas Gleixner escreveu: > When the FUTEX_ROBUST_UNLOCK mechanism is used for unlocking (PI-)futexes, > then the unlock sequence in userspace looks like this: > > 1) robust_list_set_op_pending(mutex); > 2) robust_list_remove(mutex); > > lval = gettid(); > 3) if (atomic_try_cmpxchg(&mutex->lock, lval, 0)) > 4) robust_list_clear_op_pending(); > else > 5) sys_futex(OP,...FUTEX_ROBUST_UNLOCK); > > That still leaves a minimal race window between #3 and #4 where the mutex > could be acquired by some other task which observes that it is the last > user and: > > 1) unmaps the mutex memory > 2) maps a different file, which ends up covering the same address > > When then the original task exits before reaching #5 then the kernel robust > list handling observes the pending op entry and tries to fix up user space. > > In case that the newly mapped data contains the TID of the exiting thread > at the address of the mutex/futex the kernel will set the owner died bit in > that memory and therefore corrupt unrelated data. > > Provide a VDSO function which exposes the critical section window in the > VDSO symbol table. The resulting addresses are updated in the task's mm > when the VDSO is (re)map()'ed. > > The core code detects when a task was interrupted within the critical > section and is about to deliver a signal. It then invokes an architecture > specific function which determines whether the pending op pointer has to be > cleared or not. The unlock assembly sequence on 64-bit is: > > mov %esi,%eax // Load TID into EAX > xor %ecx,%ecx // Set ECX to 0 > lock cmpxchg %ecx,(%rdi) // Try the TID -> 0 transition > .Lstart: > jnz .Lend > movq %rcx,(%rdx) // Clear list_op_pending > .Lend: > ret > > So the decision can be simply based on the ZF state in regs->flags. The > pending op pointer is always in DX independent of the build mode > (32/64-bit) to make the pending op pointer retrieval uniform. The size of > the pointer is stored in the matching criticial section range struct and > the core code retrieves it from there. So the pointer retrieval function > does not have to care. It is bit-size independent: > > return regs->flags & X86_EFLAGS_ZF ? regs->dx : NULL; > > There are two entry points to handle the different robust list pending op > pointer size: > > __vdso_futex_robust_list64_try_unlock() > __vdso_futex_robust_list32_try_unlock() > > The 32-bit VDSO provides only __vdso_futex_robust_list32_try_unlock(). > > The 64-bit VDSO provides always __vdso_futex_robust_list64_try_unlock() and > when COMPAT is enabled also the list32 variant, which is required to > support multi-size robust list pointers used by gaming emulators. > > The unlock function is inspired by an idea from Mathieu Desnoyers. > > Signed-off-by: Thomas Gleixner > Acked-by: Uros Bizjak > Link: https://lore.kernel.org/20260311185409.1988269-1-mathieu.desnoyers@efficios.com Reviewed-by: André Almeida