From owner-dev-commits-src-main@freebsd.org Thu Apr 22 10:19:24 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 1CC395E9528; Thu, 22 Apr 2021 10:19:24 +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 4FQtgv0806z3R4h; Thu, 22 Apr 2021 10:19:22 +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 13MAJ8qb005242 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 22 Apr 2021 13:19:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 13MAJ8qb005242 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 13MAJ7Gr005241; Thu, 22 Apr 2021 13:19:07 +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 13:19:07 +0300 From: Konstantin Belousov To: myfreeweb 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: 4FQtgv0806z3R4h X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.70 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.880]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_FIVE(0.00)[6]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.19)[0.185]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[dev-commits-src-all,dev-commits-src-main]; RCVD_COUNT_TWO(0.00)[2] 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 10:19:24 -0000 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.