All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyungwoo Yang <hwoo.yang@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] Prevent process migration during vfp_init()
Date: Thu, 3 May 2012 17:25:46 -0700	[thread overview]
Message-ID: <CAOsG7tqPgAJcLBx4hTE9-0bnCPymzCU4dhOHMjAPd+w9fqijVg@mail.gmail.com> (raw)

Hello,

I think I've found a bug but actually I'm not sure whether it only
happens to me due to our changes in kernel.

I really need your opinion.

In vfp_init() in "arch/arm/vfp/vfpmodule.c", if there is process
migration between vfp_enable() and smp_call_function() then kernel
crashes.

===== original code =====

       if (cpu_arch >= CPU_ARCH_ARMv6)
               vfp_enable(NULL); <== if migration happens just after
vfp_enable(NULL), kernel crashes.
                 :
                 :
       vfpsid = fmrx(FPSID); <== if migration happens, read tries to
access disbled VFP unit.
                 :
                 :
      if (VFP_arch)
               printk("not present\n");
       else if (vfpsid & FPSID_NODOUBLE) {
               printk("no double precision support\n");
       } else {
               hotcpu_notifier(vfp_hotplug, 0);

               smp_call_function(vfp_enable, NULL, 1); <== if migration happens,
smp_call_function will not work as it is expected.
=======================

Do you have any opinion?


There're a few ways of preventing migration (like set affinity or
disable premption) but the following is one of the way.
=======================

>From 6d48d0aaac03e845646b445ad02ef3c228dcfdb9 Mon Sep 17 00:00:00 2001
From: Hyungwoo Yang <hyungwooy@nvidia.com>
Date: Thu, 3 May 2012 16:49:13 -0700
Subject: [PATCH] ARM: vfp: Prevent process migration during vfp_init()

System crashes if there is process migration during vfp_init() call.

During vfp_init(), if a process which called vfp_enable() is migrated just
after the call, then the process executing the rest of code will access
a VFP unit which is not ENABLED and also smp_call_function() will not work
as it is expected.

This patch prevents accessing VFP unit disabled by preventing migration
and also replaces smp_call_function() with on_each_cpu() to make sure that
no VFP remains disabled.

Signed-off-by: Hyungwoo Yang <hyungwooy@nvidia.com>
---
 arch/arm/vfp/vfpmodule.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index bc683b8..fefa4cb 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -655,7 +655,9 @@ static int __init vfp_init(void)
 {
 	unsigned int vfpsid;
 	unsigned int cpu_arch = cpu_architecture();
-
+#ifdef CONFIG_SMP
+	preempt_disable();
+#endif
 	if (cpu_arch >= CPU_ARCH_ARMv6)
 		vfp_enable(NULL);

@@ -669,6 +671,9 @@ static int __init vfp_init(void)
 	vfpsid = fmrx(FPSID);
 	barrier();
 	vfp_vector = vfp_null_entry;
+#ifdef CONFIG_SMP
+	preempt_enable();
+#endif

 	printk(KERN_INFO "VFP support v0.3: ");
 	if (VFP_arch)
@@ -678,7 +683,7 @@ static int __init vfp_init(void)
 	} else {
 		hotcpu_notifier(vfp_hotplug, 0);

-		smp_call_function(vfp_enable, NULL, 1);
+		on_each_cpu(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",
-- 
1.7.0.4

             reply	other threads:[~2012-05-04  0:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04  0:25 Hyungwoo Yang [this message]
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
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

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=CAOsG7tqPgAJcLBx4hTE9-0bnCPymzCU4dhOHMjAPd+w9fqijVg@mail.gmail.com \
    --to=hwoo.yang@gmail.com \
    --cc=linux-kernel@vger.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.