git: 11d62b6f31ab - main - linuxkpi: add kernel_fpu_begin/kernel_fpu_end

[Greg V]

On Thu, Apr 22, 2021 at 13:19, Konstantin Belousov 
<kostikbel at gmail.com> wrote:
> On Thu, Jan 14, 2021 at 04:23:31AM +0200, Konstantin Belousov wrote:
>>  On Thu, Jan 14, 2021 at 01:36:27AM +0000, myfreeweb wrote:
>>  >
>>  >
>>  > On January 13, 2021 8:58:58 PM UTC, John Baldwin 
>> <jhb at FreeBSD.org> wrote:
>>  > >It doesn't store at all because threads aren't allowed to sleep 
>> in a critical
>>  > >section, so the thread will never give up the CPU while in the 
>> FPU section.  If
>>  > >threads can voluntarily sleep (cv_wait*, *sleep(), etc.) while 
>> using
>>  > >kernel_fpu_begin(), then NOCTX won't work and we will need 
>> something else.
>>  >
>>  > Hmm but with no storage at all, how would it work from a syscall?
>>  > The manpage does mention a "usermode save area" – I was talking 
>> about that.
>>  There is a storage for the user state, always.  When NOCTX is used, 
>> FPU state
>>  is spilled into the _current_ save area, and then kernel lives to 
>> the promise
>>  that the new state after fpu_enter(NOCTX) does not ever need to be 
>> saved.
>> 
>>  >
>>  > Linux kernel_fpu_begin starts with preempt_disable, so definitely 
>> no condvars and the like. No idea about simple time sleeps. But 
>> amdgpu doesn't seem to do even that.
>> 
>>  You should get enough assertions fired if something tries to 
>> context switch
>>  while entered NOCTX region.
> 
> So this went dead in the mail, and kernel still contains that awful 
> code
> that corrupts both userspace and kernel FPU contexts.
> 
> I suggest to remove this file at all, since things are not being 
> sorted.

Okay, let's try NOCTX: https://reviews.freebsd.org/D29921

I don't understand how using a full fpu_kern_ctx can *corrupt* anything 
though?
It should only be extra overhead?