All of lore.kernel.org
 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: Thu, 22 Jun 2023 17:42:54 +0100	[thread overview]
Message-ID: <ZJR6DvGofAvxSVYW@arm.com> (raw)
In-Reply-To: <20230621-arm64-fix-tpidr2-signal-restore-v2-1-c8e8fcc10302@kernel.org>

On Thu, Jun 22, 2023 at 02:39:45PM +0100, Mark Brown wrote:
> Currently when restoring the TPIDR2 signal context we set the new value
> from the signal frame in the thread data structure but not the register,
> following the pattern for the rest of the data we are restoring. This does
> not work in the case of TPIDR2, the register always has the value for the
> current task. This means that either we return to userspace and ignore the
> new value or we context switch and save the register value on top of the
> newly restored value.
> 
> Load the value from the signal context into the register instead.
> 
> Fixes: 39e54499280f ("arm64/signal: Include TPIDR2 in the signal context")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Cc: stable@vger.kernel.org
> ---
>  arch/arm64/kernel/signal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 2cfc810d0a5b..10b407672c42 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -398,7 +398,7 @@ static int restore_tpidr2_context(struct user_ctxs *user)
>  
>  	__get_user_error(tpidr2_el0, &user->tpidr2->tpidr2, err);
>  	if (!err)
> -		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.

I guess we need to ask Szabolcs what his preference is. The current code
is wrong either way since current->thread.tpidr2_el0 would be overridden
at thread switch.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
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: Thu, 22 Jun 2023 17:42:54 +0100	[thread overview]
Message-ID: <ZJR6DvGofAvxSVYW@arm.com> (raw)
In-Reply-To: <20230621-arm64-fix-tpidr2-signal-restore-v2-1-c8e8fcc10302@kernel.org>

On Thu, Jun 22, 2023 at 02:39:45PM +0100, Mark Brown wrote:
> Currently when restoring the TPIDR2 signal context we set the new value
> from the signal frame in the thread data structure but not the register,
> following the pattern for the rest of the data we are restoring. This does
> not work in the case of TPIDR2, the register always has the value for the
> current task. This means that either we return to userspace and ignore the
> new value or we context switch and save the register value on top of the
> newly restored value.
> 
> Load the value from the signal context into the register instead.
> 
> Fixes: 39e54499280f ("arm64/signal: Include TPIDR2 in the signal context")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Cc: stable@vger.kernel.org
> ---
>  arch/arm64/kernel/signal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 2cfc810d0a5b..10b407672c42 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -398,7 +398,7 @@ static int restore_tpidr2_context(struct user_ctxs *user)
>  
>  	__get_user_error(tpidr2_el0, &user->tpidr2->tpidr2, err);
>  	if (!err)
> -		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.

I guess we need to ask Szabolcs what his preference is. The current code
is wrong either way since current->thread.tpidr2_el0 would be overridden
at thread switch.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-06-22 16:43 UTC|newest]

Thread overview: 16+ 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 ` 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 13:39   ` Mark Brown
2023-06-22 16:42   ` Catalin Marinas [this message]
2023-06-22 16:42     ` Catalin Marinas
2023-06-22 17:11     ` Mark Brown
2023-06-22 17:11       ` Mark Brown
2023-06-23 17:28       ` Catalin Marinas
2023-06-23 17:28         ` Catalin Marinas
2023-06-23 18:22         ` Mark Brown
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-22 13:39   ` Mark Brown
2023-06-23 17:37 ` [PATCH v2 0/2] arm64/signal: Fix handling of TPIDR2 Catalin Marinas
2023-06-23 17:37   ` 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=ZJR6DvGofAvxSVYW@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.