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 8C16733262A for ; Thu, 26 Mar 2026 22:23:59 +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=1774563839; cv=none; b=Czfmk/FnTBE9605So1beWGURMmWYnw5BJCUavmGVkiPigIVCQYjBH5SeUd72TMFZKEkWQnxzrY++UGmhKW92CQBENdSjduRJO4I90rzlHfodqCo90vywSouDWfTcJu9PubRcTBcRfsZ25S5vQeFiumezQbQl4/ZQueXdytu7pXo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774563839; c=relaxed/simple; bh=Vxg1LZcPMXnbi+XkyTlusmY7ehWjegJZytSi3Bt9JIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=aqW0V1jgdgYdYTbvkmT+0+lUgArfsputklzh2hNIRp4ucwuiBsh4EEbYsp8pK5tHlkEL3uLG74gYY92Z2mxhOckfVlIGYH9Eo6qEdDkJ5jfteZITKKJaZHZAp93H6iA7hK0CBf1aAM2mOmrE3c6mgjwinpvU3CvPz/Jsq4oif30= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hAdMaz7B; 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="hAdMaz7B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AA17C116C6; Thu, 26 Mar 2026 22:23:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774563839; bh=Vxg1LZcPMXnbi+XkyTlusmY7ehWjegJZytSi3Bt9JIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hAdMaz7B2PgvlqTO78qqS1LGRlpw78UD8Wn5Tujlmu1C3EIbPrxHcUDiuxeLDPW05 f6lU7z9XgkxOWEJwPkxSc4rFyl+V04c/9KHQYb/4lRL8ZT1TqjUfoJDPEPtptKzGLt dCQRubuFKdvnd6fM+fGGd7Z07ExgEv/lsqIxezlhIos7vITnYDjYqi2ZFNt3NI8CHS 4kTvcCSLP+zyi8HQ8SFoqn90jbCGNepLDpTgb61I+a5oHFoK1CUFSTcZffDhxvhrbP TrROIJYlxhMMMJHOB5Lj+d/O1y8VTFzY6WS7wtCuBuYOOLUY7QQTF6xRT5w+gzNdu8 DigIQHpTtfTpg== From: Thomas Gleixner To: =?utf-8?Q?Andr=C3=A9?= Almeida Cc: Mathieu Desnoyers , Sebastian Andrzej Siewior , LKML , 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 v2 07/11] futex: Add support for unlocking robust futexes In-Reply-To: References: <20260319225224.853416463@kernel.org> <20260319231239.613218128@kernel.org> Date: Thu, 26 Mar 2026 23:23:55 +0100 Message-ID: <878qbecjr8.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=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 20 2026 at 14:14, Andr=C3=A9 Almeida wrote: > Em 19/03/2026 20:24, Thomas Gleixner escreveu: >>=20 >> The sys_futex() case [ab]uses the @uaddr2 argument to hand the pointer to >> the kernel. This argument is only evaluated when the FUTEX_ROBUST_UNLOCK >> bit is set and is therefore backward compatible. >>=20 > I didn't find anywhere in the commit message that says what this=20 > pointers points to, so I would add: > > "@uaddr2 argument to hand the address of robust list pending op to the=20 > kernel" Right. > and also explain why we can't use=20 > current->futex.robust_list->list_op_pending (if I understood it=20 > correctly why): > > "Instead of using the list_op_pending address found at=20 > current->futex.robust_list, use the address explicitly set by the user=20 > in the syscall arguments to avoid racing with set_robust_list()" No. The task can't be in the futex syscall and update the robust list pointer concurrently. :) The reason is to avoid the lookup of the robust list pointer and retrieving the pending op pointer. User space has the pointer already there so it can just put it into the @uaddr2 argument. Aside of that this allows the usage of multiple robust lists in the future w/o any changes to the internal functions as they just operate on the supplied pointer. Only in the unresolvable fault case the kernel checks whether there is a matching robust list registered and clears it to avoid further trouble. I'll amend the change log. Thanks, tglx