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

[Ard Biesheuvel]

On 26 June 2013 15:13, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 26 June 2013 14:52, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> On 26 June 2013 14:40, Will Deacon <will.deacon at arm.com> wrote:
>>> With what we currently have in the kernel, no, I can't think of a better
>>> way. However, I also don't think that smuggling in a back-end hack is a good
>>> idea either. How about we follow x86's lead on this and rely on the caller
>>> not to sleep for the timebeing? Then, separately to this patch series, you
>>> could look at augmenting the scheduler so that schedule_debug can complain
>>> if it encounters a task that is not expected to sleep? That seems like the
>>> right place to fix this problem, and will benefit other architectures too.
>>>
>>
>> Good point. As preempt_enable/disable already have this side effect on
>> PREEMPT builds, perhaps it wouldn't be such a bad idea to modify them
>> in the non-PREEMPT case to at least complain if schedule() is invoked
>> during such a section.
>>
>
> It appears we have this already, but in the non-PREEMPT case, it needs
> CONFIG_DEBUG_ATOMIC_SLEEP to be defined.
> Let's just rely on preempt_disable() to do the right thing...
>

OK, just one more question before I respin the next (hopefully final) version:
if a caller does sleep after calling kernel_neon_begin() (and thus
receives no warning if he runs a non-PREEMPT build with
CONFIG_DEBUG_ATOMIC_SLEEP disabled), he will most likely find the
NEON/VFP unit disabled after waking up (as we disable it on a context
switch), so any subsequent NEON instructions will trigger the undef
handler.

Should I perhaps expand the vfp_kmode_exception() function which gets
invoked in this case to be more helpful in identifying this condition?
Currently it just BUG()s on conditions that indicate dependence on
support code, and reports an undefined instruction otherwise.

-- 
Ard.