From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 F166C43D4E2 for ; Wed, 3 Jun 2026 08:42:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780476170; cv=none; b=oeMRnBmC3arn2qx/HG7ng7v4nUJ93FG96VB2YyScjcYLrHBH/cKo6Jrcn39oa5z7wFjPMNXqlfw+ss4tzT9GJDyP4uV8wTi73ZdXNabBU7bGY7ScOZPbIljvVyroM8FeQvZbL9HhsNYD6kIgDDHID3YIap4imvCxgjEUaprIALU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780476170; c=relaxed/simple; bh=onVsZ0qrq7IlSWpWgO4bgbi1pjSIT0g8M0n8vldYAa8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AgiWEqdBm1PClUms51NdJrDh0UF3mKiqmtnZuEtxPcmwq+3ue6uoj2/qpiR9HuA4iJBYfyojqjc7foaHgSNMSpj5KNn5T1JX+Rmt9igKIQfniluuQmPprIzk1T+KQnY973RIPy7zj4/81dgVwkRAez3jQmVzmibgJhANQEk1sDs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=pt5QeNGY; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="pt5QeNGY" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vU2iTBH5VuFutmt461y5eyPeLnE6lH/it+xfxvD3poE=; b=pt5QeNGYUw2FONYagXxvfnWUdV aZJNFP+FQi4cDQibDsUwNQcOAQO9i6F4PuDUO7ZY5ZR8kD3MLgmGszCX20V+m+qS8+5gHzDTlYbst MzoxHeoCRYUr1AUTBkqAzaAGFKyT7CKkdf1LZMmwBFpXLDSCx2xlY0cGQ7qaJCtKDGBFVb+WxLHlZ 12F+c3X+wXKonBbgS+xdowPkSOAMNud9W/3KwA5sRKbRi1/haiSj+BY3UyW92CM7x+uA46x/1IAr2 RZRaOpmcuCuaJ217cfyBIU2rEvtuBhDwQE+XeqUep6bYB600jqJTVVQV2W42lgVFuDf6F5p4LQlFq J5FexQlg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wUhBR-0000000Bc3o-2lRh; Wed, 03 Jun 2026 08:42:41 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 685D7300642; Wed, 03 Jun 2026 10:42:40 +0200 (CEST) Date: Wed, 3 Jun 2026 10:42:40 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: LKML , Mathieu Desnoyers , =?iso-8859-1?Q?Andr=E9?= 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 =?iso-8859-1?Q?Wei=DFschuh?= , Mark Brown , Richard Weinberger Subject: Re: [patch V5 11/16] futex: Provide infrastructure to plug the non contended robust futex unlock race Message-ID: <20260603084240.GT3102624@noisy.programming.kicks-ass.net> References: <20260602084648.462672743@kernel.org> <20260602090535.773669210@kernel.org> 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: <20260602090535.773669210@kernel.org> On Tue, Jun 02, 2026 at 11:10:04AM +0200, Thomas Gleixner wrote: > When the FUTEX_ROBUST_UNLOCK mechanism is used for unlocking (PI-)futexes, > then the unlock sequence in user space looks like this: > > 1) robust_list_set_op_pending(mutex); > 2) robust_list_remove(mutex); > > lval = gettid(); > 3) if (atomic_try_cmpxchg(&mutex->lock, lval, 0)) > 4) robust_list_clear_op_pending(); > else > 5) sys_futex(OP | FUTEX_ROBUST_UNLOCK, ....); Ah!, see, your uapi patch earlier called that FUTEX_UNLOCK_ROBUST. I'll fix it all up if I don't fine real issues.