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 94D64372684 for ; Mon, 16 Mar 2026 22:19:43 +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=1773699583; cv=none; b=BnQb6nnE36AvYeHux/gzDaYQFF1o9bnjFqTom1IrsYr0o6yvya5cPL0S9LmBnhjyt8KhPe5R9UlHiKdDdNR7AhAlZf42tXbK5twSiDpjh+MqVweLhpYyVuMIpTlkPf+HkRL2+FY8xHsojD4VRjtqrDB2T3mmaEj2E1VyxyUzEyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773699583; c=relaxed/simple; bh=DQsB5Oo1TfLC26KK8s5g9r980ekFRvlXCMRaLA6Aki0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hKR/eKtfhmLaQgASvD/1936uV3gaMdXHtlStmC59J9VPO1KKIm3Cvc/W6Yf392/BZVSKVWifKXcFb1zr7sy1/fmPBWLD6caZaOE36DWc1jB6Da0ClydZ5tbDUOYNySXqA3oOEiF37Cglu/mWKzslS9C0ux8Zq8m6cAlgYVXvntg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RGzN8Fkp; 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="RGzN8Fkp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D967C19421; Mon, 16 Mar 2026 22:19:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773699583; bh=DQsB5Oo1TfLC26KK8s5g9r980ekFRvlXCMRaLA6Aki0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RGzN8FkpOCw0inOunZr7XlU3WKRD0EXSc6RuhIptBxr+prRM3F4mKlgN7TABN8s/h ax4SDkvADxSqok5HPEahvmdIkKiTG7hKh0AMN7EC20LOUOE+YBVZ/iZdtBJhjMFRuq 1LszkIxZyg9VB7gn/Z8PwBk35F98sXmeVlzcal0nkDdpeKRWEanYJs2YcDzNO/APop svFZIYnWdtC73Uf8z2TzF3jiBgeA85rb/LMcWKLV3TJFa1ZwCqmGTEJojzemB1ybC1 by8Xvz4RjloSz+0uOAYtQjvGUiaOq3BxS14gNKzVMK31vfBPRNCEK9PJLEUetPfKPt QOpGGqsREvTFg== 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: References: <20260311185409.1988269-1-mathieu.desnoyers@efficios.com> <87eclopu0j.ffs@tglx> <874imfpukd.ffs@tglx> <871phjplj4.ffs@tglx> Date: Mon, 16 Mar 2026 23:19:39 +0100 Message-ID: <87ms07o1s4.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 17:01, Mathieu Desnoyers wrote: > On 2026-03-16 16:27, Thomas Gleixner wrote: >> On Mon, Mar 16 2026 at 15:36, Mathieu Desnoyers wrote: >>> On 2026-03-16 13:12, Thomas Gleixner wrote: >>>> sys_exit() is different because there a task voluntarily exits and if >>>> it does so between the unlock and the clearing of the op pointer, >>>> then so be it. That'd be wilfull ignorance or malice and not any >>>> different from the task doing the corruption itself in user space >>>> right away. >>> >>> I'm not sure about this one. How about the two following scenario: >>> A concurrent thread calls sys_exit concurrently with the vdso. Is this >>> something we should handle or consider it "wilfull ignorance/malice" ? >> >> I don't understand your question. What has the exit to do with the VDSO? > > You mentioned that "if a task exits between unlock and clearing of the op > pointer, then so be it". > > But that exit could be issued by another thread, not necessarily by the > thread doing the unlock + pointer clear. > > But I understand that your series takes care of this by: > > - clearing the op pointer within the futex syscall, > - tracking the insn range and ZF state within the vDSO. > > I'm fine with your approach, I was just not sure about your comment > about it being "different" for sys_exit. 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. Thanks, tglx