From: Dave Martin <Dave.Martin@arm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-rt-users@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Mike Galbraith <efault@gmx.de>, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RT v3] arm64: fpsimd: use preemp_disable in addition to local_bh_disable()
Date: Fri, 27 Jul 2018 16:35:59 +0100 [thread overview]
Message-ID: <20180727153559.GA4240@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20180726150634.cl3wccqur6qhle6p@linutronix.de>
On Thu, Jul 26, 2018 at 05:06:34PM +0200, Sebastian Andrzej Siewior wrote:
> In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
> code disables BH and expects that it is not preemptible. On -RT the
> task remains preemptible but remains the same CPU. This may corrupt the
> content of the SIMD registers if the task is preempted during
> saving/restoring those registers.
>
> Add preempt_disable()/enable() to enfore the required semantic on -RT.
Does this supersede the local_lock based approach?
That would have been nice to have, but if there are open questions about
how to do it then I guess something like this patch makes sense as a
stopgap solution.
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> This should work. Compiling currently gcc-6 on the box to see what
> happens. Since the crypto disables preemption "frequently" and I don't
> expect or see anything to worry about.
>
> arch/arm64/kernel/fpsimd.c | 30 ++++++++++++++++++++++++++++--
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -157,6 +157,15 @@ static void sve_free(struct task_struct
> __sve_free(task);
> }
>
> +static void *sve_free_atomic(struct task_struct *task)
> +{
> + void *sve_state = task->thread.sve_state;
> +
> + WARN_ON(test_tsk_thread_flag(task, TIF_SVE));
> +
> + task->thread.sve_state = NULL;
> + return sve_state;
> +}
This feels a bit excessive. Since there's only one call site, I'd
prefer if the necessary code were simply inlined. We wouldn't need the
WARN either in that case, since (IIUC) it's only there to check for
accidental misuse of this helper.
> /* Offset of FFR in the SVE register dump */
> static size_t sve_ffr_offset(int vl)
> @@ -594,6 +603,7 @@ int sve_set_vector_length(struct task_st
> * non-SVE thread.
> */
> if (task == current) {
> + preempt_disable();
> local_bh_disable();
>
> task_fpsimd_save();
> @@ -604,8 +614,10 @@ int sve_set_vector_length(struct task_st
> if (test_and_clear_tsk_thread_flag(task, TIF_SVE))
> sve_to_fpsimd(task);
>
> - if (task == current)
> + if (task == current) {
> local_bh_enable();
> + preempt_enable();
> + }
>
> /*
> * Force reallocation of task SVE state to the correct size
> @@ -837,6 +849,7 @@ asmlinkage void do_sve_acc(unsigned int
>
> sve_alloc(current);
>
> + preempt_disable();
> local_bh_disable();
I think we should have local helpers for the preempt+local_bh
maintenance, since they're needed all over the place in this
file.
[...]
Cheers
---Dave
next prev parent reply other threads:[~2018-07-27 15:35 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 12:40 [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable() Sebastian Andrzej Siewior
2018-05-17 18:19 ` Dave Martin
2018-05-18 12:46 ` Dave Martin
2018-05-23 14:34 ` Sebastian Andrzej Siewior
2018-05-23 14:31 ` Sebastian Andrzej Siewior
2018-05-23 14:55 ` Dave Martin
2018-05-22 17:10 ` Steven Rostedt
2018-05-22 17:21 ` Sebastian Andrzej Siewior
2018-05-22 17:24 ` Steven Rostedt
2018-05-22 17:33 ` Sebastian Andrzej Siewior
2018-07-11 13:25 ` Steven Rostedt
2018-07-11 13:31 ` Sebastian Andrzej Siewior
2018-07-11 13:33 ` Steven Rostedt
2018-07-13 17:49 ` [PATCH RT v2] " Sebastian Andrzej Siewior
2018-07-13 17:50 ` [PATCH RT] locallock: add local_lock_bh() Sebastian Andrzej Siewior
2018-07-13 22:03 ` [PATCH RT v2] arm64: fpsimd: use a local_lock() in addition to local_bh_disable() Mike Galbraith
2018-07-15 7:22 ` Mike Galbraith
2018-07-18 10:30 ` Mike Galbraith
2018-07-18 9:27 ` Sebastian Andrzej Siewior
2018-07-18 10:28 ` Mike Galbraith
2018-07-18 10:36 ` Sebastian Andrzej Siewior
2018-07-16 15:17 ` Dave Martin
2018-07-18 9:12 ` Sebastian Andrzej Siewior
2018-07-18 9:24 ` Sebastian Andrzej Siewior
2018-07-24 14:45 ` Dave Martin
2018-07-24 15:15 ` Ard Biesheuvel
2018-07-24 13:46 ` Steven Rostedt
2018-07-24 13:57 ` Sebastian Andrzej Siewior
2018-07-26 15:06 ` [PATCH RT v3] arm64: fpsimd: use preemp_disable " Sebastian Andrzej Siewior
2018-07-27 3:17 ` Mike Galbraith
2018-07-27 7:56 ` Sebastian Andrzej Siewior
2018-07-27 15:35 ` Dave Martin [this message]
2018-07-27 16:26 ` Sebastian Andrzej Siewior
2018-07-11 17:07 ` [PATCH RT] arm64: fpsimd: use a local_lock() " Mike Galbraith
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=20180727153559.GA4240@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=efault@gmx.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/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;
as well as URLs for NNTP newsgroup(s).