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 0DB8B280CF6 for ; Wed, 28 Jan 2026 13:16:34 +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=1769606195; cv=none; b=ooRFUgYXrTtUlxkb/DQm+EDkHgwU8qCzpsESL2HROtcgdPV/HThVDbfEe8N+BaAFHS/CrKzONPzZDKsCctx+dDNZSkFABdAVj6N7bNCCavyAYQNs3c/GmDpNwFIJxN2FaZj7qvurtAcS9Qi0geshk3CUu+5OS3hwsyZxRRI21kI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769606195; c=relaxed/simple; bh=zviQD/Y+TF1qaNtY0CQpS5aiW44pdgYmL+EqZKmx0tM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Gnr8Q2NKImMPPe9I/G5Xs+WZLD5T4UTmW7o/od9t9AcCYAIcTOyW7D1ddMsh/dtNLjDIgoWlOqroXSxN/PW/xkO7Bcoe1RJop+JN4jddfv2MQmCaxr+T2/o8zuJ2u5HZNxfTtTVs7m+wNufZ8zHLAGjgE7WHJtH6tOeHEfZE2aA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RQVvxi6b; 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="RQVvxi6b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7058C4CEF1; Wed, 28 Jan 2026 13:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769606194; bh=zviQD/Y+TF1qaNtY0CQpS5aiW44pdgYmL+EqZKmx0tM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RQVvxi6bq7ZoLc/JFaCuFsy4ZNQ2H01WrGDaWaDEtlsJGert4z4N/Z3Z+9zIPzJZS fe6yh99nGgzyP+68f7EZJEnr30AZZpdRysvKXhvauayFcl7MfwV7V8l+wl7WHa1FW+ xPztZPTBTkXJke/Se07M8ZRcaIZvLpLp3f3bQ4i3bSWJFxI046hUe8J5SwmD+ilqPc hwLHUkGCsW6C1zctsBgNrupeYXFC7ndh/jiFYbFw5jxutCnoB9JsI09LZ9WIc4BKpa Cf/78hTEEl4iK7bckDt/qsj1OeR+bZQ2rQ5wVwUOZviSi5X6J6m49C4g8vWDGANVBC 8xSStVtAhzkoA== From: Thomas Gleixner To: Dmitry Vyukov , Mathieu Desnoyers Cc: David Matlack , Marco Elver , Peter Zijlstra , LKML , Michael Jeanson , Jens Axboe , "Paul E. McKenney" , X86 ML , Sean Christopherson , Wei Liu Subject: Re: SIGSEGVs after 39a167560a61 ("rseq: Optimize event setting") In-Reply-To: References: <20260126204745.GP171111@noisy.programming.kicks-ass.net> <87zf60avr1.ffs@tglx> <199b8846-40c3-4307-8fd5-c93b59268dc4@efficios.com> <5f3843ba-31d4-4acf-b3b9-0d2a131dca23@efficios.com> Date: Wed, 28 Jan 2026 14:16:31 +0100 Message-ID: <874io5andc.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 Wed, Jan 28 2026 at 12:40, Dmitry Vyukov wrote: > On Wed, 28 Jan 2026 at 12:28, Mathieu Desnoyers > wrote: >> I suspect that tcmalloc's aliasing of the rseq cpu_id_start field >> with its own data structure, corrupting its content, and expecting the >> kernel to update it on every preemption does not work anymore, because >> the kernel only updates it when the cpu_id actually changes. > > I can't recall now why tcmalloc would need updates on every > preemption... Do you know why? >From the tcmalloc docs: "To understand that the cached pointer is not valid anymore when a thread is rescheduled to another CPU, we overlap the top 4 bytes of the cached address with `__rseq_abi.cpu_id_start`. When a thread is rescheduled the kernel overwrites `cpu_id_start` with the current CPU number, which gives us the signal that the cached address is not valid anymore." That's still the case as the kernel updates the CPU number when the task is migrated to a different CPU. What it not longer does is updating the CPU number for the preemption case on the same CPU because that's just a massive waste of CPU cycles. Now the interesting part of that documentation: "To distinguish the high part of the cached address from the CPU number, we set the top bit in the cached address, real CPU numbers (`<2^31`) do not have this bit set. With these arrangements, slabs address calculation on allocation/deallocation fast paths reduces to load and check of the cached address: ``` slabs = __rseq_abi[-4]; if ((slabs & (1 << 63)) == 0) goto slowpath; slabs &= ~(1 << 63); ```" which means the code fiddles in rseq_abi::cpu_id_start. That never worked on a RSEQ DEBUG enabled kernel because the kernel detects that user space fiddled with data which is defined as USER_RO in the ABI and kills the offender. I have not looked at the code, but I suspect that this is also (undocumented) abused as a light weight preemption indicator and that indication is not longer given as the kernel only updates when the CPU number changed. As this was never correctly using the ABI (enable CONFIG_RSEQ_DEBUG on a pre 6.19 kernel and watch the show or ask David) this is a pure tcmalloc problem and not a regression. And no, we are not catering to that abuse for the cost of performance regressions which have been observed after glibc enabled rseq. Thanks, tglx