[PATCH] Prevent process migration during vfp_init()
Russell King - ARM Linux
linux at arm.linux.org.uk
Wed May 9 05:26:50 EDT 2012
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().
More information about the linux-arm-kernel
mailing list