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 7BBE73D333A for ; Wed, 3 Jun 2026 14:42:31 +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=1780497752; cv=none; b=USvPM3G55ZIp7qumcfQ0iZZsRs1PxJr1JwNUgFP+Ft28DTuytxiCHtz01maQ3p/lTHqrVA6Wqhf/ueKepCEvvBh6Hsc3jTg1O7v5fEnMUQHY9M0eWcedkyeVcNYcRPDuW0epRQerFFsok+JptjVWXAhd0Qfj3DZ8PpyWj9oD+mA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780497752; c=relaxed/simple; bh=Ry0ar+Yacduuw3L7xnO36zEnWLi0plH3S/sGA2Zftv8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=b4hIlqXVzzgtIK6x8zqLOfbP0melzyBt5emfz4VwU/3bY9i6JdjnditbPXqM7DmSZDyxCLdihytnofaB6NSQs6qpdPjxqoc6PVBgcYDc8gUgFP4PQR0ig4X+Sknfoxu3/BNpO+euzLYDS4VbFB11HvsWZRJVGOiewcwklGQBDkM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U+fUpHq4; 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="U+fUpHq4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB7671F00893; Wed, 3 Jun 2026 14:42:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780497751; bh=fxj6WMRxMRnnnCHsd8weIF3OGkD71ocOeQbck/9JMdY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=U+fUpHq4Os7U9h2nTqViRuYgDFnunSx4u5QGNrd6JzKCxQ9yqO24ihDeCXbJkc9D4 oJP66qmlp15Kx2KwDZOSCVyHD4JlXGNyYhTUpFjdHku3lgnenPLeTZ8Sp45jbpRdMG UNu20J/64RLLnybj3eI/VZHLpMiazbP2XAzPWvxKqLMStdyG1VkpQmtQGJT4JqghRr 6HhOsVnUB4wW2b33RGO0k0WBfDNMfMRFOKkezsvHKk8XztyV1xh6uNKGdqOkpN4kzH 1YAymZ7sa3vjgzHo99JJiftqw6B28/ZXEy8hm4tJdBHOTN5z62C7kd6DNqrrULtv2c G/Lq/BRrmeyNA== 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: <20260603092346.GV3102624@noisy.programming.kicks-ass.net> References: <20260602084648.462672743@kernel.org> <20260602090535.773669210@kernel.org> <20260603092346.GV3102624@noisy.programming.kicks-ass.net> Date: Wed, 03 Jun 2026 16:42:28 +0200 Message-ID: <87jysf7kiz.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:23, Peter Zijlstra wrote: > 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. Yes.