From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BA7553A3E88 for ; Fri, 29 May 2026 21:31:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780090261; cv=none; b=saV8b4WvbfibnjELqsVP/3FLtx/ruqRWH1ohrqmvswyBMQbg+kPV7v4kFMz/PVrSJFhFU+mZXLFqziG0Ea3MuwQDPR6h5iEkPeAwqENAuSYl5pQL0haCL0hjrp1W0l3xYQ6Gt5NesOW4p/VusmNg0/0U6iZzdGRIOeLrjmuqaoM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780090261; c=relaxed/simple; bh=R1J96f29fQRTP3wHHF4HGhJXIwG8Sra8ndTpmnGobpI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=KLW8CM5uBMGx2m+O2mONGAhbW0mvpI2t2jQ4Hc6jrKDmi1mojVnZuh0T3sr2E7oVloNBzilINVhV5/riTLIPFkaeamuHqAywoMcakH7bS0tyOUHO2KuaUN57vKGoXtixW5pqnzbCqtsfvr8JxJ8ohToLFn6NyCim/wssEb0zk9w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z9etfjo+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z9etfjo+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7BBB1F00893; Fri, 29 May 2026 21:30:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780090260; bh=/p35P73T4WWjxaAVQQn3z4oo900xhvCC0PVPXpimY2A=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Z9etfjo+0/yO9D+N9L2vmhbdqfp5ljEviWzhHw8vt3Ok6sAsb0mTVPqe5g+UiXW1M 8YMtOVbLLHgXlyziXL9hDzKyulsFTyxnAW0+IspxLggH90I9OV7QFn6KjLnW5qYwfv RkIqPMhx5yoNSk2UfMIxc83l62+2cErzl2BYLSQJscTbEu977V3qEIWJvlqDOMiZCe o6PbJUrCk1uBCQ9uDRbJeuwCmnIlYk1NusGh+5X9H7ZDLAr7P7Bi5uJuby/VP/sX9D qJroC+Ae/BjlzCNlCsYHBGnFlPUlX65jP/ODsdcPHU7p1cEFsUGkce8CnUfvJqZoin LFzAc+P2pvejw== From: Thomas Gleixner To: =?utf-8?Q?Andr=C3=A9?= Almeida 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 , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= Subject: Re: [patch V4 09/14] futex: Add robust futex unlock IP range In-Reply-To: <591f2298-8b89-490b-bcee-32876fb0fb3e@igalia.com> References: <20260402151131.876492985@kernel.org> <20260402151940.213884829@kernel.org> <591f2298-8b89-490b-bcee-32876fb0fb3e@igalia.com> Date: Fri, 29 May 2026 23:30:57 +0200 Message-ID: <87a4th9a3y.ffs@fw13> 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 On Wed, May 27 2026 at 22:02, Andr=C3=A9 Almeida wrote: > 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> To support multi size robust list applications (gaming) this provides two >> ranges when COMPAT is enabled. >>=20 >> 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, un= signed int idx, >> + unsigned long vdso, unsigned long start, >> + unsigned long end, bool sz32) >> +{ >> + fd->unlock.cs_ranges[idx].start_ip =3D vdso + start; >> + fd->unlock.cs_ranges[idx].len =3D end - start; >> + fd->unlock.cs_ranges[idx].pop_size32 =3D sz32; >> +} > > Can we have the "vdso +" done by the caller? VDSO_SYMBOL() that I used=20 > for aarch64 adds the base address as well, see here:=20 > https://lore.kernel.org/lkml/f8e83a24-0b04-4c88-9f67-0879875be25c@t-8ch.d= e/ Sure. Let me change that.