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

[Konstantin Belousov]

On Thu, Apr 22, 2021 at 02:22:27PM +0300, Greg V wrote:
> 
> 
> 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?
Existing code uses global unsynchronized flag increment to conclude that
there is no need to enter FPU.  In other words, even ignoring races for
updating the counter, if one thread entered FPU, another thread would not
enter it and corrupt e.g. usermode context.