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 46FC1146D5A for ; Mon, 16 Mar 2026 23:29:21 +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=1773703761; cv=none; b=fljTyTtHxyuj8WzzVNBfRTIAAdf+4ghWbdYT7ng5swmYIID7DnRI8MPIwnu6xZaK/TvFBPucUNK5RLK8e8aB+0OUf63hOamgTwrhPHsAD8QDGelNW7FSbwuqgYwFuia/VifR8XSYhJAIoC3DrczZHZK8tj0n5GpGHC7iqkWI+U4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773703761; c=relaxed/simple; bh=urZSwz/Jca84upD9qTyYg1qgCc9p3Q5C29ssWY3AVqs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Uy+LwyLHawUuLQZOJX66eWO8VobLh4vypm6ABP8BdKHF1ct8zN2NZ9UxIx8T8pyhKWrrzJE4aaxB/YsR8Esdz30cNHOxpuRF+YdDdvUdVLvH7vWfTOd0BnmuAJt6306CUXfwutI/fEeDN+2MLamVyZSCZIwkeo9L/7jFGDm3uDY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NZuSyxc5; 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="NZuSyxc5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FCD7C2BCAF; Mon, 16 Mar 2026 23:29:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773703761; bh=urZSwz/Jca84upD9qTyYg1qgCc9p3Q5C29ssWY3AVqs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NZuSyxc59BePCrk3ZypnaXoK9DDM48pHlxBJB8eGLHx1ZM5ugS/ZjJOOPytqmKAqU poN9mOiX5LGTOXvVwKVHGXIHkdJF2XWzUeLp+C/p29gSyGdxESFZnzvV/n2hedDrGf EzD1+0pm6GGPF7ta+u7VKX3ePvXvk+XKz/BRUZGmgfDm7Vg29tyb8qf0ylajK6znaV HaJ8pIj9OSQENre41zEJr8PuO4dXcdZg4gCyE/z/MrOvuIXl26A0NJ36O+fjltUtwe P8hlu79vJIwHdI4vP7jgwUwvW22Vk4vgc8CFQn/mBYaWJ6pAGVy5bkZIsUgn6EN0zz 8SrpSefXaEnIg== From: Thomas Gleixner To: Mathieu Desnoyers , =?utf-8?Q?Andr?= =?utf-8?Q?=C3=A9?= Almeida Cc: linux-kernel@vger.kernel.org, Carlos O'Donell , Sebastian Andrzej Siewior , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [RFC PATCH] futex: Introduce __vdso_robust_futex_unlock In-Reply-To: <2c8b81cf-af1d-44ba-9a4d-d033a8ddb2a1@efficios.com> References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> <87eclopu0j.ffs@tglx> <874imfpukd.ffs@tglx> <871phjplj4.ffs@tglx> <87ms07o1s4.ffs@tglx> <2c8b81cf-af1d-44ba-9a4d-d033a8ddb2a1@efficios.com> Date: Tue, 17 Mar 2026 00:29:17 +0100 Message-ID: <87jyvbnyk2.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 On Mon, Mar 16 2026 at 18:30, Mathieu Desnoyers wrote: > On 2026-03-16 18:19, Thomas Gleixner wrote: >> What I clearly described is the sequence: >> >> set_pointer(); >> unlock(); >> sys_exit(); >> >> The kernel does not care about that at all as that's what user space >> asked for. That is clearly in the category of "I want to shoot myself >> into the foot". >> >> The only case where the kernel has to provide help to user space is the >> involuntary exit caused by a crash or external signal between unlock() >> and clear_pointer(). Simply because there is no way that user space can >> solve that problem on its own. >> >> If you want to prevent user space from shooting itself into the foot >> then the above crude scenario is the least of your problems. > > So the extra scenario I am concerned about is: > > Thread A Thread B > ---------------------------------------- > set_pointer(); > unlock(); > syscall exit_group(2) > > This does not fall under the "async" program termination per se, because > it is issued by Thread B, but it's not the result of an "exit(2)" call > from Thread A. > > Is this scenario too far fetched, or something we should care about ? It's a legit scenario, but you still fail to try to look at the code and understand how all of this works even after I gave you enough hints. I'm truly amazed that you even failed to ask any AI agent the obvious question: "When a task invokes the exit_group syscall on Linux how does the Linux kernel manage to tear down all tasks which belong to the same process?" Both agents which https://arena.ai randomly picked out for me provided very comprehensive explanations. Let me paste you one of them: "3. Terminate All Other Threads do_group_exit calls zap_other_threads, which: Iterates over all tasks in the thread group using for_each_thread (traversing the thread group list in task_struct). Sends an uncatchable SIGKILL signal to every thread except the current one (using SEND_SIG_FORCED to bypass any signal blocking). Since SIGKILL cannot be caught or ignored, these threads will terminate immediately." If that's not a sufficient answer for you, may I recommed to look at: https://training.linuxfoundation.org/ Thanks, tglx