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 34739378826 for ; Wed, 3 Jun 2026 09:23:56 +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=1780478638; cv=none; b=Lf2bBWAL1Jz/ZBrXSqCWhzcYoQNvmUCcyFhaCQgL7uWBej715v+R8ezNgY/7u+39/P/UTELFRqsRvC8cHD5Vq9rbwxEaOYmh9bcKtgNbX1vHaaP3iqfMNTczdNBe3Zp5BD3WPE4ECnaftRr6BMF6HRmJ/SDeToFhNYOBhKZqkOY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780478638; c=relaxed/simple; bh=H+hGfwPJQDug71SOEMALDaJmKVnSbal5KZubinvf864=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hH3VttwD+URTZdn8isvweuXrutXV7rzKi1dKT6SE/llmhPBeRBbshcOis3xtfeVGSrmjcOyTw8gvc6SkVn3dg4r/js9LkkvkKuOgynJghxWvv3hQfAOJnFLunnUsa+QPPA8cUHNo6XBaKN3z997EWzyuu0pzM2QbnCNd7YbcPr8= 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=OkmSj+3J; 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="OkmSj+3J" 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=Ciw1zNbjj+VEJbWYqWnb+qCN+056WpjUhE2XYPE86T8=; b=OkmSj+3JoXrF3W6BFARAfIXe2l 55KPr5YBYuSCLNA6/a5OzOJmJ5VB5WCIxLbbg0iT/noNX2sGGf+6/41A6o9FRId8jY7JkyQluiiGS InFxssbWrmrpUFrbnKBhMlqjnTLSh/gOv9QEY3o8sk+NLReVb2dsn0HhXOWrdfwerrerbgBW62plc CpBUqSrv6oBG6tcyVVafwLBE1wbj1izXuV75HLxHBlKFVmq9ygiJtW1VfAnnZ+WmKoEXz9aI/pZVk WvOzQjcGGQhlQqq9VdZqVaaWxeumZ456ocYbVF15ZX3P+asUzoNEbXZBxU2JEgQJdx4XsN406ITGV q+TU/lOg==; 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 1wUhpD-0000000BhfZ-2Ta3; Wed, 03 Jun 2026 09:23:47 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id F2A5B301218; Wed, 03 Jun 2026 11:23:46 +0200 (CEST) Date: Wed, 3 Jun 2026 11:23:46 +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: <20260603092346.GV3102624@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, ....); > > That still leaves a minimal race window between #3 and #4 where the mutex > could be acquired by some other task, which observes that it is the last > user and: > > 1) unmaps the mutex memory > 2) maps a different file, which ends up covering the same address > > When then the original task exits before reaching #5 then the kernel robust > list handling observes the pending op entry and tries to fix up user space. This #5 reference, should be #4, yeah? Same bit of Changelog is replicated in a later patch and has the same issue.