All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Prevent process migration during vfp_init()
Date: Tue, 8 May 2012 19:04:30 +0100	[thread overview]
Message-ID: <20120508180430.GL2263@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <CAOsG7tqr__yWp1zmMfy3myRGFmY690f8i8emuXq5d7E=o3E7Vw@mail.gmail.com>

On Tue, May 08, 2012 at 06:24:27PM +0100, Hyungwoo Yang wrote:
> I think we don't need preempt_disable()/preempt_enable() call in your proposal.
> I mean, since we have enabled on every VFPs in cores online(
> on_each_cpu() ), we don't need to worry about accessing a VFP which is
> disabled. So we don't need to worry about migration after
> "on_each_cpu()", right?

Yes, that sounds reasonable to me since any thread migration will imply the
barriers we need for the VFP exception vector to be correct. In which case the
patch can be further reduced to what I've got below.

It seems happy enough on my quad A9 running a bunch of paranoia FP tests --
do you have a particular testcase which was exhibiting this failure when you
reported the issue?

Cheers,

Will


diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index bc683b8..c5767b5 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -11,6 +11,7 @@
 #include <linux/types.h>
 #include <linux/cpu.h>
 #include <linux/cpu_pm.h>
+#include <linux/hardirq.h>
 #include <linux/kernel.h>
 #include <linux/notifier.h>
 #include <linux/signal.h>
@@ -432,7 +433,10 @@ void VFP_bounce(u32 trigger, u32 fpexc, struct pt_regs *regs)
 
 static void vfp_enable(void *unused)
 {
-       u32 access = get_copro_access();
+       u32 access;
+
+       BUG_ON(preemptible());
+       access = get_copro_access();
 
        /*
         * Enable full access to VFP (cp10 and cp11)
@@ -657,7 +661,7 @@ static int __init vfp_init(void)
        unsigned int cpu_arch = cpu_architecture();
 
        if (cpu_arch >= CPU_ARCH_ARMv6)
-               vfp_enable(NULL);
+               on_each_cpu(vfp_enable, NULL, 1);
 
        /*
         * First check that there is a VFP that we can use.
@@ -678,8 +682,6 @@ static int __init vfp_init(void)
        } else {
                hotcpu_notifier(vfp_hotplug, 0);
 
-               smp_call_function(vfp_enable, NULL, 1);
-
                VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;  /* Extract the architecture version */
                printk("implementor %02x architecture %d part %02x variant %x rev %x\n",
                        (vfpsid & FPSID_IMPLEMENTER_MASK) >> FPSID_IMPLEMENTER_BIT,

  reply	other threads:[~2012-05-08 18:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 20:28 [PATCH] Prevent process migration during vfp_init() Hyungwoo Yang
2012-05-08 11:13 ` Will Deacon
2012-05-08 17:24   ` Hyungwoo Yang
2012-05-08 18:04     ` Will Deacon [this message]
2012-05-08 18:28       ` Hyungwoo Yang
2012-05-08 18:45         ` Will Deacon
2012-05-09  1:54           ` Hyungwoo Yang
2012-05-09  9:26       ` Russell King - ARM Linux
2012-05-09  9:57         ` Will Deacon
  -- strict thread matches above, loose matches on Subject: below --
2012-05-04  0:25 Hyungwoo Yang

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=20120508180430.GL2263@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.