From owner-dev-commits-src-main@freebsd.org Thu Apr 22 11:38:48 2021 Return-Path: Delivered-To: dev-commits-src-main@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4E26C5EE974; Thu, 22 Apr 2021 11:38:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FQwRW6sg2z3p02; Thu, 22 Apr 2021 11:38:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 13MBcd2A025112 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 22 Apr 2021 14:38:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 13MBcd2A025112 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 13MBcdQW025111; Thu, 22 Apr 2021 14:38:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Apr 2021 14:38:39 +0300 From: Konstantin Belousov To: Greg V Cc: John Baldwin , Emmanuel Vadot , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 11d62b6f31ab - main - linuxkpi: add?? kernel_fpu_begin/kernel_fpu_end Message-ID: References: <202101121143.10CBh02x095972@gitrepo.freebsd.org> <20210113110826.46fbc900b3c375e7215a8195@bidouilliste.com> <171B7072-9BAE-46BB-82BA-4792AEBAD0EB@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4FQwRW6sg2z3p02 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for the main branch of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 11:38:48 -0000 On Thu, Apr 22, 2021 at 02:22:27PM +0300, Greg V wrote: > > > On Thu, Apr 22, 2021 at 13:19, Konstantin Belousov > 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 > > > 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.