From owner-dev-commits-src-all@freebsd.org Thu Apr 22 11:22:45 2021 Return-Path: Delivered-To: dev-commits-src-all@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 4442D5ED7C9; Thu, 22 Apr 2021 11:22:45 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FQw510b1fz3mvq; Thu, 22 Apr 2021 11:22:44 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Thu, 22 Apr 2021 14:22:27 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=key1; t=1619090556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dUJJ+mcjrBNRFddUc175K2rTmzP2X/JonJIYyHEZRX0=; b=CeiSz/Y0evMrwFDQpX9ms8RayWwI72OBrep4AqoOi7eBQjNRpi0oHN3IEoCl/2dDdtlbK7 YUf2Z5NRCOrdbYcWJc1quoYLXc5NGcsdu3v0QqC+2BwJr703LxxpxBsCv07Z/MdXgXODMZ ++SkWvg1f59FxVF8lTNgr193ZmFSz9OJuoxfBoa8NHGgRxwpIVZ6baj6835c3Q5Zth88If MsC5g51qkqwbj6W58tYl73eXubjECRbjTtCZqP8IMxW0zit0nQrMddNFTFP4ekjJK1JqC7 YXdg75CGNYXbdMn46Et7VUC0qJE0VXBLj7D5xltriHuVHLCzKj0mOtdvxsYl0w== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Greg V Subject: Re: git: 11d62b6f31ab - main - linuxkpi: =?UTF-8?Q?add=0D=0A?= kernel_fpu_begin/kernel_fpu_end To: Konstantin Belousov Cc: John Baldwin , Emmanuel Vadot , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Message-Id: In-Reply-To: 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=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: greg@unrelenting.technology X-Rspamd-Queue-Id: 4FQw510b1fz3mvq 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-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 11:22:45 -0000 On Thu, Apr 22, 2021 at 13:19, Konstantin Belousov=20 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=20 >> wrote: >> > >It doesn't store at all because threads aren't allowed to sleep=20 >> in a critical >> > >section, so the thread will never give up the CPU while in the=20 >> FPU section. If >> > >threads can voluntarily sleep (cv_wait*, *sleep(), etc.) while=20 >> using >> > >kernel_fpu_begin(), then NOCTX won't work and we will need=20 >> something else. >> > >> > Hmm but with no storage at all, how would it work from a syscall? >> > The manpage does mention a "usermode save area" =96 I was talking=20 >> about that. >> There is a storage for the user state, always. When NOCTX is used,=20 >> FPU state >> is spilled into the _current_ save area, and then kernel lives to=20 >> the promise >> that the new state after fpu_enter(NOCTX) does not ever need to be=20 >> saved. >>=20 >> > >> > Linux kernel_fpu_begin starts with preempt_disable, so definitely=20 >> no condvars and the like. No idea about simple time sleeps. But=20 >> amdgpu doesn't seem to do even that. >>=20 >> You should get enough assertions fired if something tries to=20 >> context switch >> while entered NOCTX region. >=20 > So this went dead in the mail, and kernel still contains that awful=20 > code > that corrupts both userspace and kernel FPU contexts. >=20 > I suggest to remove this file at all, since things are not being=20 > 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=20 though? It should only be extra overhead?