> On Sep 26, 2018, at 10:03 AM, Jason A. Donenfeld <[email protected]> wrote:
>
>> On Wed, Sep 26, 2018 at 6:21 PM Andy Lutomirski <[email protected]> wrote:
>> Are, is what you’re saying that the Zinc chacha20 functions should call
>> simd_relax() every n bytes automatically for some reasonable value of n? If
>> so, seems sensible, except that some care might be needed to make sure they
>> interact with preemption correctly.
>>
>> What I mean is: the public Zinc entry points should either be callable in an
>> atomic context or they should not be. I think this should be checked at
>> runtime in an appropriate place with an __might_sleep or similar. Or
>> simd_relax should learn to *not* schedule if the result of preempt_enable()
>> leaves it atomic. (And the latter needs to be done in a way that works even
>> on non-preempt kernels, and I don’t remember whether that’s possible.). And
>> this should happen regardless of how many bytes are processed. IOW, calling
>> into Zinc should be equally not atomic-safe for 100 bytes and for 10 MB.
>
> I'm not sure this is actually a problem. Namely:
>
> preempt_disable();
> kernel_fpu_begin();
> kernel_fpu_end();
> schedule(); <--- bug!
>
> Calling kernel_fpu_end() disables preemption, but AFAIK, preemption
> enabling/disabling is recursive, so kernel_fpu_end's use of
> preempt_disable won't actually do anything until the outer preempt
> enable is called:
>
> preempt_disable();
> kernel_fpu_begin();
> kernel_fpu_end();
> preempt_enable();
> schedule(); <--- works!
>
> Or am I missing some more subtle point?
>
No, I think you’re right. I was mid-remembering precisely how simd_relax()
worked.
