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 BD5E414883F for ; Wed, 3 Jun 2026 14:47:08 +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=1780498029; cv=none; b=E2tT18j6EvfW6NH4bniNLfNgVbJ0hL25zyALfyFhGtrfjLjR/zxksTSewTPCaHH9pLmgB7ngEY60ufhBP2v5hkJD8g8ydXAVs745TmeYngUIwojtnA3HUJvEPn2nUbQWIAhfyq5iBRApplPOyaisDIQsFeIXCF9b7BXEGPjdB4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780498029; c=relaxed/simple; bh=2kg0NAl7ppFcqCTUePK13Sixi+78J9CT65Dk7m2V/sI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lau7cYMWqCuRcwBZ3j0mkhHko9y5SMnNocpRNNTkQ7AoheRVg1mPoKs9AxhS9hicNVvu/4iKD+pfhc/LDRX1QlQAyucGEdVGUq9GJhFm5yC+iAVlFzk0Q79biSJIJjoS54ZuUVhu7nnrsuzQXPIO03tadZISWApm1Eh3vJ2BNDc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kgrdg3Oc; 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="kgrdg3Oc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93C471F00893; Wed, 3 Jun 2026 14:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780498028; bh=q13MgONbgas8A6dv2mVl+jfearFMUk5+NSKR3+BeTgk=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=kgrdg3OcWjkRhkHuOEnriwr7DjVOYF4PbGL+pk+BmkGnlzELzQhMCvmRK/ySGwVPD Vo3cPTa/VvFYLEZdPQUnjGad9HC7tU62graVP6VRo1runi/tC8iGEDvSyx3byW8VHQ MXZS9S04oKYbrJpd5kd3tsWCWo107quZecBMZ6NjjJCkHoDPj1saojAS/10OEi+48C sqQI9DdOYSJCVG11JWJNJQppI6OdHUgs2EulLJNI8CZusK0c4uGOcqbjhA3UDJfPi8 eb9Do8aAfTpxY703WgLSo6RIJ+ugTpvWvNsJNG99+R7Kdl7kOWoxafVAgiFmQ8D4LA odRJu4djeMUqw== From: Thomas Gleixner To: Peter Zijlstra Cc: LKML , Mathieu Desnoyers , =?utf-8?Q?Andr=C3=A9?= Almeida , Sebastian Andrzej Siewior , Carlos O'Donell , 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?= , Mark Brown , Richard Weinberger Subject: Re: [patch V5 11/16] futex: Provide infrastructure to plug the non contended robust futex unlock race In-Reply-To: <20260603091415.GU3102624@noisy.programming.kicks-ass.net> References: <20260602084648.462672743@kernel.org> <20260602090535.773669210@kernel.org> <20260603091415.GU3102624@noisy.programming.kicks-ass.net> Date: Wed, 03 Jun 2026 16:47:05 +0200 Message-ID: <87h5nj7kba.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 On Wed, Jun 03 2026 at 11:14, Peter Zijlstra wrote: > On Tue, Jun 02, 2026 at 11:10:04AM +0200, Thomas Gleixner wrote: >> This is only relevant when user space was interrupted and a signal is >> pending. The fix-up has to be done before signal delivery is attempted >> because: >> >> 1) The signal might be fatal so get_signal() ends up in do_exit() >> >> 2) The signal handler might crash or the task is killed before returning >> from the handler. At that point the instruction pointer in pt_regs is >> not longer the instruction pointer of the initially interrupted unlock >> sequence. > > However, due to the pending field being strictly per thread (thread > local storage and all that), the whole construct of futex robust unlock > is not signal safe in the sense that signal handlers must not use it. > > A signal handler trying to use this would result in nested use of the > pending field, and that leads to corrupted state. That's true already today and this unlock magic does not change it. >> Other architectures might need to do more complex evaluations due to LLSC, >> but the approach is valid in general. The size of the pointer is determined >> from the matching range struct, which covers both 32-bit and 64-bit builds >> including COMPAT. > > So my initial thoughts today were that we should probably also move the > IP to .Lend, to avoid userspace from writing to that location again. > > However, due to the above mentioned restrictions vs signals, there > cannot be a situation where this matters, and so the point is moot. > > A double store is harmless and it makes the kernel just this little bit > simpler. > > The only reason I'm sending this email is to have this more explicitly > documented for posterity I suppose ;-) Indeed :)