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 ABBE138888F for ; Mon, 8 Jun 2026 09:15:36 +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=1780910137; cv=none; b=VXB0SEEF2PxSCUQ/wa0AE5poO9uQ2EUqA8O8z+GHsOdtG5ZZsMPxJ8ArqmN9PRMRYSoWRUDTKBsejGIWhMxIY/2UWmYDx9mvh2rGLkzcYfG8n39+c+koONBV1+T2SkQNfAmFhoak7r6rk11uB1vUgfqsNJ/I0PvIt7OIn9vJ2Kg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780910137; c=relaxed/simple; bh=gzM8Ra4K+8xVPLBKBtqe8iTbKvNs9a1FqPdYGogMQ9Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=NV2agW0P5F2wf2DjoZxFE2NYstsy+TpuY5quQWRrV5Y3weTnSmcNjT//lBaQWjLUTnxnAlVsTKj6l2Ts2fJl9Ftym3WBGoiksmR1KEKw9ZFsdX7FaSTTvRpShd4uNLzepFT2ffg/537kSVOoImZzEJOdNBRSchoBtn+QaHASbNI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wq/EaOX8; 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="Wq/EaOX8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9EDC71F00899; Mon, 8 Jun 2026 09:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780910136; bh=dwEPH8vi9mXcQWSKAlRPmEN4E7dxqsw4cLIxarGQkL0=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Wq/EaOX8x8nCY4+71pSpsWAL8fkoNbLiFeOMRmvy4EplNpZsIZvmJCh9En24VL/rG f5j9XgmCgMXM2Hha+MsNkO5BDhyMluTupEn3NUD3LKuGMWwSPCgu2iv+bj9dN2uplC ymVFutchRZ6/i0IcHTpUjbCHf75zaeDfhhr3ZLS8iCAABMunEDI26KTkqTGfU3/D1Y o1ZlInszHJEn4lR1omtJYa8q+CxSTbWeqNNDHPOyh5QmuWSDlaEBpkpmSFlgIYR09F K5OZZhDF0e7AwPiVesAAbSGHOivcyXUQ4dVzEE701n3rkaRTjgCr616M5P54y9rINE JCWeSjFv4wosA== From: Thomas Gleixner To: Yuanhe Shu , Mathieu Desnoyers , Peter Zijlstra Cc: "Paul E . McKenney" , Boqun Feng , linux-kernel@vger.kernel.org, Yuanhe Shu Subject: Re: [PATCH] rseq: don't promote transient TLS faults to SIGSEGV In-Reply-To: <20260608021553.1037128-1-xiangzao@linux.alibaba.com> References: <20260608021553.1037128-1-xiangzao@linux.alibaba.com> Date: Mon, 08 Jun 2026 11:15:32 +0200 Message-ID: <87o6hl4cln.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 Mon, Jun 08 2026 at 10:15, Yuanhe Shu wrote: > On return to user space the rseq slow path writes the new cpu_id / > mm_cid into the user-space rseq TLS. rseq_update_usr() already > classifies its failures in rseq_event::fatal: the flag is set only > when corrupt user data is positively identified (e.g. a bad rseq_cs > signature or an out-of-bounds abort IP) and stays clear when the > access merely hit an unresolved page fault. > > rseq_slowpath_update_usr() ignores that and calls force_sig(SIGSEGV) > on any failure, so a transient page fault on a still-registered rseq > area becomes a fatal SIGSEGV. This is reachable since glibc >= 2.35 It's not transient. rseq_slowpath_update_usr() does the full pagefault resolution, which means if that returns without resolving the fault, then it's game over. We also cannot return to user space in that case because the rseq area, which is not accessible, has not been updated. Thanks, tglx