From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Prevent process migration during vfp_init()
Date: Wed, 9 May 2012 10:26:50 +0100 [thread overview]
Message-ID: <20120509092650.GR26481@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20120508180430.GL2263@mudshark.cambridge.arm.com>
On Tue, May 08, 2012 at 07:04:30PM +0100, Will Deacon wrote:
> 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?
It's pointless doing FP tests for this level of change - the code you're
modifying is only run at startup to enable access to VFP. If you can
execute a single VFP instruction in userspace on each CPU, then your test
has passed. Further VFP instructions do not gain you any additional test
coverage.
The only comment I have is whether that BUG_ON(preemptible()) - preferably
WARN_ON() - should be inside get_copro_access() itself, in a similar way
to smp_processor_id().
next prev parent reply other threads:[~2012-05-09 9:26 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
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 [this message]
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=20120509092650.GR26481@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--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.