[PATCH v2 3/5] ARM: add support for kernel mode NEON

[Ard Biesheuvel]

On 26 June 2013 13:14, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Jun 26, 2013 at 11:55:33AM +0100, Ard Biesheuvel wrote:
>> Replying to self:
>>
>> On 25 June 2013 22:24, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > +void kernel_neon_end(void)
>> > +{
>> > +       /* Disable the NEON/VFP unit. */
>> > +       fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
>> > +       barrier();
>> > +       dec_preempt_count();
>> > +}
>> > +EXPORT_SYMBOL(kernel_neon_end);
>>
>> Meh. This is not going to please the RT crowd, as preempt_schedule()
>> will not be called on PREEMPT builds in this case.
>>
>> Propose to replace it with
>>
>>     preempt_enable();
>> #ifndef CONFIG_PREEMPT_COUNT
>>     /* in this case, the preempt_enable() right above is just a barrier() */
>>     dec_preempt_count();
>> #endif
>>
>> (and the converse in kernel_neon_begin())
>
> Yuck, that's ugly as sin! How does x86 deal with this? Looking at
> kernel_fpu_{begin,end}, they just disable preemption so I guess that they
> assume the caller is non-blocking? There's an aside about the use of
> preempt-notifiers for KVM, so it does sound like the onus is on the caller
> not to shoot themselves in the face.
>

Even if x86 doesn't care about this, do you really think we should
take the risk of silently clobbering the NEON registers if the caller
does something that may end up sleeping? Anyway, I don't remember
exactly who suggested using inc_preempt_count() directly, but doing so
brings about the responsibility of calling preempt_schedule() when
leaving the critical section, and just using both (without the #ifdef)
is also not an option.

So can you suggest a better way of making sure schedule_debug() shoots
us down if calling schedule() between kernel_neon_begin and
kernel_neon_end, even on non-preempt builds?

-- 
Ard.