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 EEF04199EAD for ; Thu, 28 May 2026 01:03:15 +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=1779930199; cv=none; b=ABeZtbRR80BfBf22wOtMMMqMCxs9WuB7SqcfcbRkpVsP9e02FRaUnjnOBPpt27gxcXCYGTwCzMBQPNxGbiDxQxcNgl+Ilw+VuBrN3vowGVUXizyk+Gq58CJ34h1mS6VP7U7akgKQTAFivt4kwr/w9bWvxr/q7nbqfdv/KWDk6Zw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779930199; c=relaxed/simple; bh=DVzxjpjsSSHNSNrGoo/2jk+51/S1XLq9dg9w7IcM86U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pURiJS5tzAxMCpOTU/7HpdOVaDG7BgEhszk+GC+nlqNogvBSCIr7qrZYyJuUCnejH1fNkvf3kUKe2XcsSmVfZt5PLrkzBGqZ9Z319K94u0PbhOea/Y31uNs1/900fzSB3jbhwmYMBDjppnf0U4TuAImV76MPQI9OIs6rLp66QFw= 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=d4XKHPk9; 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="d4XKHPk9" 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=8Y48gSl2S8STZ/IatAl5sfisTrR0FvTzjKeVU4BfTAU=; b=d4XKHPk9UbKeyRQ0DxOu87JB/7 hKRcl/mTY/qP4A7FTMOv7ef5wb1+2vgVoPv4DmNNhI4lShGMiaFDldgj125U8JM9y1k/jVat8KoCg ri1+KZTEv81JvofRaddhwvIlS/ZceuQ4Med5zvXKVi4Hh4qEBdlzqB/XVxoHXp8OlF+pbZrErJXE8 /eKCIbU2mIhhDwWL1C1t7oBdzKNZFojuw1PJUFuYCSuGlrxsmQHfHLYkJaPtsJTf9s86BQNpiDDSY Vld1rNeW1Q97sMC92zuTfiEChFDfynrhmWv1cB4JHVNBDD4f9MY7hHuw6mheuHLo7q+YeMmzm7clO Q0+5j91A==; 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 1wSP8u-0099FD-Lh; Thu, 28 May 2026 03:02:36 +0200 Message-ID: <591f2298-8b89-490b-bcee-32876fb0fb3e@igalia.com> Date: Wed, 27 May 2026 22:02:28 -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 09/14] futex: Add robust futex unlock IP range To: Thomas Gleixner Cc: Mathieu Desnoyers , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , LKML , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" , Uros Bizjak , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= References: <20260402151131.876492985@kernel.org> <20260402151940.213884829@kernel.org> Content-Language: en-US From: =?UTF-8?Q?Andr=C3=A9_Almeida?= In-Reply-To: <20260402151940.213884829@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Em 02/04/2026 12:21, Thomas Gleixner escreveu: > There will be a VDSO function to unlock robust futexes in user space. The > unlock sequence is racy vs. clearing the list_pending_op pointer in the > tasks robust list head. To plug this race the kernel needs to know the > instruction window. As the VDSO is per MM the addresses are stored in > mm_struct::futex. > > Architectures which implement support for this have to update these > addresses when the VDSO is (re)mapped and indicate the pending op pointer > size which is matching the IP. > > Arguably this could be resolved by chasing mm->context->vdso->image, but > that's architecture specific and requires to touch quite some cache > lines. Having it in mm::futex reduces the cache line impact and avoids > having yet another set of architecture specific functionality. > > To support multi size robust list applications (gaming) this provides two > ranges when COMPAT is enabled. > > Signed-off-by: Thomas Gleixner [...] > +void futex_reset_cs_ranges(struct futex_mm_data *fd); > + > +static inline void futex_set_vdso_cs_range(struct futex_mm_data *fd, unsigned int idx, > + unsigned long vdso, unsigned long start, > + unsigned long end, bool sz32) > +{ > + fd->unlock.cs_ranges[idx].start_ip = vdso + start; > + fd->unlock.cs_ranges[idx].len = end - start; > + fd->unlock.cs_ranges[idx].pop_size32 = sz32; > +} Can we have the "vdso +" done by the caller? VDSO_SYMBOL() that I used for aarch64 adds the base address as well, see here: https://lore.kernel.org/lkml/f8e83a24-0b04-4c88-9f67-0879875be25c@t-8ch.de/ Apart from that: Reviewed-by: André Almeida