From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 79C5D3E5EFD for ; Tue, 31 Mar 2026 14:12:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774966348; cv=none; b=VKb/PH/MUdz9+X/bnuxXnR9mGvkYvrrHGjm5oZkyEx9HlZfPbnRPJRIpvc0lHw7yt1SKLTUs3D7mWyuF1FGpomnTvxVjeLdfkTXosfN2+Csiqycpvk5i75GEcF0OImW0yBTJtrx22cPQSjAgkvWRjvVyuClFSgCCOpV1wZyHD9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774966348; c=relaxed/simple; bh=j/uKdsOMwlgFtEXjc54gtghSAfF3XJYVuyU8dTRWJ8U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gEJDVUUUGtqQdaf8dOPcXhBF54Bq6ZdesGAedBHRvG+kaEt7wFVEPd642G2UPkWRkJvB94/SUSOvYlzLu4VlsOHc3uvl/yLm3VSseXvtBfjR+fmMEE2w8uWxB6RKijNJSY8aeVknAdjdrURoDRBkPcLEYx9oZLDCR97durIkz+U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=rG5DYB5U; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="rG5DYB5U" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7FBE6497F; Tue, 31 Mar 2026 07:12:19 -0700 (PDT) Received: from J2N7QTR9R3.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BDE043F641; Tue, 31 Mar 2026 07:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774966345; bh=j/uKdsOMwlgFtEXjc54gtghSAfF3XJYVuyU8dTRWJ8U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rG5DYB5UDrXdxNtVlY0q+gPi4y1XFD4XgWU3YbejgSwKD8gKBgDM7qs7rDZJMtqL0 45f1+79Lfi+svaIw2utZdKo/Bq3tELFjNybqmoNVu4Ze9PeaBbI3BaicxFEbXxznyY L32ftYo5WjJIyypUGuB2U3KG2h364Z2hcZ972hvI= Date: Tue, 31 Mar 2026 15:12:17 +0100 From: Mark Rutland To: Thomas Gleixner Cc: LKML , Mathieu Desnoyers , =?utf-8?B?QW5kcsOo?= Almeida , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Uros Bizjak , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Subject: Re: [patch V3 00/14] futex: Address the robust futex unlock race for real Message-ID: References: <20260330114212.927686587@kernel.org> <87pl4l9kj7.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; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pl4l9kj7.ffs@tglx> On Mon, Mar 30, 2026 at 09:36:44PM +0200, Thomas Gleixner wrote: > On Mon, Mar 30 2026 at 14:45, Mark Rutland wrote: > > On Mon, Mar 30, 2026 at 02:01:58PM +0200, Thomas Gleixner wrote: > >> User space can't solve this problem without help from the kernel. This > >> series provides the kernel side infrastructure to help it along: > [ 6 more citation lines. Click/Enter to show. ] > >> > >> 1) Combined unlock, pointer clearing, wake-up for the contended case > >> > >> 2) VDSO based unlock and pointer clearing helpers with a fix-up function > >> in the kernel when user space was interrupted within the critical > >> section. > > > > I see the vdso bits in this series are specific to x86. Do other > > architectures need something here? > > Yes. Cool. Thanks for confirming! > > I might be missing some context; I'm not sure whether that's not > > necessary or just not implemented by this series, and so I'm not sure > > whether arm64 folk and other need to go dig into this. > > The VDSO functions __vdso_futex_robust_list64_try_unlock() and > __vdso_futex_robust_list32_try_unlock() are architecture specific. > > The scheme in x86 ASM 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 > > .Lstart is the start of the critical section, .Lend the end. These two > addresses need to be retrieved from the VDSO when the VDSO is mapped to > user space and stored in mm::futex:unlock::cs_ranges[]. See patch 11/14. > > If the cmpxchg was successful, then the pending pointer has to be > cleared when user space was interrupted before reaching .Lend. > > So .Lstart has to be immediately after the instruction which did the try > compare exchange and the architecture needs to have their ASM variant > and the helper function which tells the generic code whether the pointer > has to be cleared or not. On x86 that is: > > return regs->flags & X86_EFLAGS_ZF ? (void __user *)regs->dx : NULL; > > as the result of CMPXCHG is in the Zero Flag and the pointer is in > [ER]DX. The former is defined by the ISA, the latter is enforced by the > ASM constraints and has to be kept in sync between the VDSO ASM and the > evaluation helper. > > Do you see a problem with that on AARGH64? I think something like that should be possible. The one pain point I see immediately is how to work with LL/SC and LSE atomics. For LL/SC atomics, we need to retry even if the value hasn't changed; I think that just makes the critical section and helper a bit more complicated. LL/SC and LSE atomics indicate success differently, but again that's probably just some additional logic in the helper function, and special care when laying out the asm for patching. Mark.