linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] arm64/sve: Make kernel FPU protection RT friendly
Date: Thu, 29 Jul 2021 14:54:59 +0100	[thread overview]
Message-ID: <20210729135459.GL1724@arm.com> (raw)
In-Reply-To: <20210729105215.2222338-3-bigeasy@linutronix.de>

On Thu, Jul 29, 2021 at 12:52:15PM +0200, Sebastian Andrzej Siewior wrote:
> Non RT kernels need to protect FPU against preemption and bottom half
> processing. This is achieved by disabling bottom halves via
> local_bh_disable() which implictly disables preemption.
> 
> On RT kernels this protection mechanism is not sufficient because
> local_bh_disable() does not disable preemption. It serializes bottom half
> related processing via a CPU local lock.
> 
> As bottom halves are running always in thread context on RT kernels
> disabling preemption is the proper choice as it implicitly prevents bottom
> half processing.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  arch/arm64/kernel/fpsimd.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index e098f6c67b1de..a208514bd69a9 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -177,10 +177,19 @@ static void __get_cpu_fpsimd_context(void)
>   *
>   * The double-underscore version must only be called if you know the task
>   * can't be preempted.
> + *
> + * On RT kernels local_bh_disable() is not sufficient because it only
> + * serializes soft interrupt related sections via a local lock, but stays
> + * preemptible. Disabling preemption is the right choice here as bottom
> + * half processing is always in thread context on RT kernels so it
> + * implicitly prevents bottom half processing as well.
>   */
>  static void get_cpu_fpsimd_context(void)
>  {
> -	local_bh_disable();
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> +		local_bh_disable();
> +	else
> +		preempt_disable();

Is this wrongly abstracted for RT?

The requirement here is that the code should temporarily be
nonpreemptible by anything except hardirq context.

Having to do this conditional everywhere that is required feels fragile.
Is a similar thing needed anywhere else?

If bh (as a preempting context) doesn't exist on RT, then can't
local_bh_disable() just suppress all preemption up to but excluding
hardirq?  Would anything break?

[...]

Cheers
---Dave

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

  reply	other threads:[~2021-07-29 13:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 10:52 arm64/sve: Two PREEMPT_RT related arm64 fixes Sebastian Andrzej Siewior
2021-07-29 10:52 ` [PATCH] arm64/sve: Delay freeing memory in fpsimd_flush_thread() Sebastian Andrzej Siewior
2021-07-29 13:58   ` Dave Martin
2021-07-29 14:26   ` Mark Brown
2021-07-29 14:39     ` Sebastian Andrzej Siewior
2021-07-29 15:37       ` Dave Martin
2021-07-29 10:52 ` [PATCH] arm64/sve: Make kernel FPU protection RT friendly Sebastian Andrzej Siewior
2021-07-29 13:54   ` Dave Martin [this message]
2021-07-29 14:17     ` Sebastian Andrzej Siewior
2021-07-29 15:34       ` Dave Martin
2021-07-29 16:00         ` Sebastian Andrzej Siewior
2021-07-29 16:07           ` Sebastian Andrzej Siewior
2021-07-29 16:32             ` Dave Martin
2021-07-29 17:11               ` Sebastian Andrzej Siewior
2021-07-29 14:22   ` Mark Brown
2021-07-29 14:41     ` Sebastian Andrzej Siewior
2021-07-29 16:23       ` Mark Brown

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=20210729135459.GL1724@arm.com \
    --to=dave.martin@arm.com \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).