From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B9603A0EA2 for ; Tue, 24 Feb 2026 14:59:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771945187; cv=none; b=slBmPqGtowtHfhTX7p2yQJ8NezbZ5OgxjJ/Tvz+AVwf8H0L7whyUTkCnCpt9ntMb5b6zuH8/JJqqSRhDwOubeMzC69MIy2k2PC8tfljEwz0zBfR7Oc4FQOMLM8kFO1TZnOMUPAAV5Jr42K6fVVJ72Y0b0dd4bnLQsUd7q9Toz8c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771945187; c=relaxed/simple; bh=C+SICMbSZoasgbfHvRJZkup+SrquRyrZMqGkCR2mVl8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=i5Ke3rLcQ5zBHZrbf7Og+GYdiDx+UnkQEIGaIN7KEJSVCVNiWa/r9cLv6kgMnu0LH/R0UkfWYwYq1m2Pv5mP7A30+jb+FFnsk4SgRtflT05dmKyJyZwPiqtIkKCDps90OIo/tn8qU6eaMvDV0VAfGNyLy0uRv5tbRsAXHhpN+MI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ISZZOICY; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ISZZOICY" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4837f27cf2dso48007825e9.2 for ; Tue, 24 Feb 2026 06:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771945184; x=1772549984; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=TqHplH+h8EQaTKmAgyeNcMMJXXR2BpXlZZAvChCxNd4=; b=ISZZOICYvaAzhKN8vVwIBt7OkFi7yRs4IiWn3cR+A7CL/59n3P/BKe1zlsaORk0cRV +/KTT3WcdoJb9JlH/1eBI/fAsPmzyBtVtof1FOx4IAicH3pbZJBvaJMLn0dR/pP5w3I4 cdTV4jJpujoYAPDZyX1E+lyGUenPgpETRnxJk/Uc98v0cfRLFkD6CRGfdrNcFOMqZUv/ RUBEFQ7O69+y+MxKvKFIOTeLCQ5DP7RWgFl1gOycf1c5UDzf+gqUG/2FFkCG8VCMzYv6 TvTC8u7py3DTQOJValQnITo27VJBUUbTgzmoSCF+qB44Zl9xwoYrUOZMdbtAnq6B9u67 y8Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771945184; x=1772549984; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TqHplH+h8EQaTKmAgyeNcMMJXXR2BpXlZZAvChCxNd4=; b=WC+Ht3QdEPFXHgXzJl7RiGSwL9Iw83uIHWeZsKIrVXYp4fX0M/+HrDvZHTpF4raiNt YxQb+ay1CJM0lj0OQpaqhO/aKq9/Ri8pgLgFVAzmKZZcD3heKfqokgfYDyNgt48zILiF lRMrik84nbKqL1v5gbXDemflsF6FVFb59+19SlDX0Yfw6pKoSsOJtCCw3EnHFzDMXSFo gmwgxoKvgnkZLanHIiEgzOUfsB2bf71+EzD2yktMTACuXNN56KC//zaG/tna1qH4lWOV Q6MuWryTJlMqkWtPTaXZJbc/tNuIHeHvNVveZiLnm5Teyh0/QZuJkIlV1Xb/7JCVi23u rp8g== X-Forwarded-Encrypted: i=1; AJvYcCUhQvclSHF7VUF/XhWuGmvhzpj1NUmVFxCUd5x+S8wAGhbZFo5NJBzIOT954qxWLpJIzjYjS+nuDOLd8Io=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+p2PmT/+pJEzZnnHkRee4HZwRpxVtjLrCcIRC68MMjbqiijh/ Kpx/YviKCqHmxmYvV7rg1eIIZ98anLlOcJXJRAYoo67ed2Icf1AFovK1zAiwmJ+f X-Gm-Gg: AZuq6aIEnf++JgleGoY3b8FuIWyGTl/tq00q4tEB61rH1bNtqQUppntu8jbO6PV6Dg4 0b8GUNH+OaiyjAsNFooZPRRa9MdLew/UabjocofE7v5OcV0KE3KCwmWPHlXJxBPabythUOHYTLu /UQjTFdlo7UIXKCW7dHihyyXf7FOBLGBvQpQzHbZ4PfKElnrvxDeBsy7wghmiVSoVrmuCwoZCNE tAv8mNCzCeI+NZ9gsZ1Ezi6ninbXIg8Hs+1qEGdXjShOXQa3HN7KXw7koJ3N+NrjCbLyg0zOHSm pnBsZi6ytBBcz4Mv6Y4RhzAwZj7eGi/OJxOc3v1w/DtbDCxG0b6uLSgddDeT6yoxq2GHMu8OAXs ifHfONjginVYZksHjE1Pytci0pwO1MyxzC782srhQkQGYl1SrQT8UZWaL93z3pVYCJuew9cpEuw dtzIU2d2kislGLIv7klNTc/6ncruBufLV8ZZ+F8tKiktmBgPUyNNVqBphC4c+Z59lw X-Received: by 2002:a05:600c:4751:b0:475:de12:d3b5 with SMTP id 5b1f17b1804b1-483a963df99mr190663015e9.34.1771945184388; Tue, 24 Feb 2026 06:59:44 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483b88f95adsm20844665e9.17.2026.02.24.06.59.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 06:59:44 -0800 (PST) Date: Tue, 24 Feb 2026 14:59:42 +0000 From: David Laight To: Mathieu Desnoyers Cc: Heiko Carstens , Peter Zijlstra , linux-kernel@vger.kernel.org, Thomas Gleixner , Mark Rutland , cmarinas@kernel.org, maddy@linux.ibm.com, ryan.roberts@arm.com Subject: Re: [RFC] in-kernel rseq Message-ID: <20260224145942.6e0d43b2@pumpkin> In-Reply-To: <2d3612eb-7afe-4acd-b527-588763a02a55@efficios.com> References: <20260223163843.GR1282955@noisy.programming.kicks-ass.net> <20260224111646.20006Ddc-hca@linux.ibm.com> <2d3612eb-7afe-4acd-b527-588763a02a55@efficios.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 24 Feb 2026 08:48:03 -0500 Mathieu Desnoyers wrote: > On 2026-02-24 06:16, Heiko Carstens wrote: > > On Mon, Feb 23, 2026 at 05:38:43PM +0100, Peter Zijlstra wrote: > >> This means, it needs to be woven into the asm... and I'm not that handy > >> with arm64 asm. > >> > >> The pseudo code would be something like: > >> > >> current->sched_seq = &_R; > >> ... > >> > >> _start: compute per cpu-addr > >> load addr > >> $OP > >> _commit: store addr > >> > >> ... > >> current->sched_rseq = NULL; > >> > >> > >> Then when preemption happens (from interrupt), the instruction pointer > >> is 'simply' reset to _start and it tries again. > > > > I guess also on every interrupt, exception, and nmi current->sched_rseq needs > > to be saved on entry, and restored on exit, since other contexts can make use > > of this_cpu ops as well. > > If we do a design similar to userspace rseq, we'd abort the rseq > critical section on interrupt, exception, nmi (by changing the pt_regs > instruction pointer) rather than save/restore it. This is what > userspace rseq does for signal handlers nesting on top of rseq critical > sections. Does that mean that 'start' would have to include the code to setup the rseq? (rather than being after it as above). David > > Thanks, > > Mathieu >