Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kselftest@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] arm64/signal: Restore TPIDR2 register rather than memory state
Date: Fri, 23 Jun 2023 18:28:12 +0100	[thread overview]
Message-ID: <ZJXWLAsAVuHNOqpS@arm.com> (raw)
In-Reply-To: <ZJSAuOrkgJyULV+v@finisterre.sirena.org.uk>

On Thu, Jun 22, 2023 at 06:11:20PM +0100, Mark Brown wrote:
> On Thu, Jun 22, 2023 at 05:42:54PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 22, 2023 at 02:39:45PM +0100, Mark Brown wrote:
> 
> > > -		current->thread.tpidr2_el0 = tpidr2_el0;
> > > +		write_sysreg_s(tpidr2_el0, SYS_TPIDR2_EL0);
> 
> > I guess the other way around may also be true - the libc sets tpidr2_el0
> > to something else and doesn't want the kernel to restore its original
> > value from sigcontext.
> 
> > For tpidr_el0 we don't bother with sigcontext, not sure what the use for
> > tpidr2_el0 in signals is. If we assume the context saved is only
> > informative (like esr), we can simply ignore restoring it from the
> > signal stack.
> 
> TPIDR2 is intended to go along with the thread stack, it's intended to
> be used to allow lazy save of the (rather large) ZA register state when
> a called function needs it rather than forcing it to be caller saved.
> TPIDR2 is used to point to memory allocated for managing this process,
> something that provides a new value should be making a deliberate
> decision to do so and editing the stack frame.

OK, so if the signal handler invokes a function that touches the ZA
state, it may use TPIDR2 for lazy saving in any callee. In this case we
need to restore the original TPIDR2 of the interrupted context on
sigreturn.

So I convinced myself this is the only option that makes sense ;). I'll
queue the patches.

-- 
Catalin

  reply	other threads:[~2023-06-23 17:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 13:39 [PATCH v2 0/2] arm64/signal: Fix handling of TPIDR2 Mark Brown
2023-06-22 13:39 ` [PATCH v2 1/2] arm64/signal: Restore TPIDR2 register rather than memory state Mark Brown
2023-06-22 16:42   ` Catalin Marinas
2023-06-22 17:11     ` Mark Brown
2023-06-23 17:28       ` Catalin Marinas [this message]
2023-06-23 18:22         ` Mark Brown
2023-06-22 13:39 ` [PATCH v2 2/2] kselftest/arm64: Add a test case for TPIDR2 restore Mark Brown
2023-06-23 17:37 ` [PATCH v2 0/2] arm64/signal: Fix handling of TPIDR2 Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZJXWLAsAVuHNOqpS@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=szabolcs.nagy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox