From nobody Tue Jan 02 19:17:48 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T4N0Z46tlz566gy; Tue, 2 Jan 2024 19:17:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T4N0Z3Zzfz4LSX; Tue, 2 Jan 2024 19:17:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704223070; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l6LkYQIP1rF/eqVn6XcxQaqtwgZw/dxFoZNurQA4lE4=; b=qr6l6/lBPrmQPcWbcddhNMpl8dUPtSGPTEhubMzB351LUSliMTNLvVcQuDCnn8RN9D6myP ojo3HxNXqDyKvrVreIbLg1XJDXe2iELn8BZtL93QF11BL9TSRiNiiABxkSEexQ7YjlTYnN Y7fp1uZrIvVbSsPkmvhCUDlTDDFK2sCqwKYpWc1piyUa6T+6QH+V8fj3+fHyGGVBhpaDG3 Gf99fwj6btwY+cWw2zd5nQAwXqQ1lEcTkoKkhQ5XvRhGBtqYVGconBGYD0XRSXzFOzJpW5 45AvqHinVmMmVswcL51maXS3PYRqjdwkBH4Ny/PrQtoJu/d7lDP3vOTSQhMHoA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1704223070; a=rsa-sha256; cv=none; b=pxfJZ4cdOTHJSUTI7eIE8qISMjnrUT881ip766pY47DgmZbjwl/TAput641fkg9vJcoi+j o8fMSFYMy8roxChPsgGWdM+TjntYJE2ias3uc0CWBnl1dBl1JsyEA69viVrf5PiWns/PRO ELaNjvWp3k11MOtPdruxJydGdchctzsp5nGBgMnOxGpo9AO5gXStqLupsb0r3ROFgtGH7F s8yl1EecFQxUdcNiOgpTkRNm3s4wbMNcECzrXMRDxf3LZrH4dy76ChvNLFnnuRdLxudG5B UxGB6fxHN2fdeT0kDu6B22lxnpUvjLocvrOuzqlDbc4wGI7ZJJl/IlN6SdMzIg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1704223070; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l6LkYQIP1rF/eqVn6XcxQaqtwgZw/dxFoZNurQA4lE4=; b=UJsLzuoEZfIPitn+eei934olFwcpslWGXrAXgqZdJea5Gy+jjYJfK6VZMy8i9NwvE61YRV v6gwTMI3s1rX3TFwTNbbAkhhyBR5AMqQcNPBK2HyNhn7a+JGmMbTEbov+ljpOedD0aVxCI uOMFShOIAPTafDCX8d6eaKlwPmyZCLeh5WuMKUeJNhFrMwvefg+8SzQtvj6rk7mkyLNIC3 hvfaqggJrG3Zc46F1XJGvQ8ssfBpG4ItERDhuNDGVi9cSTxYbXrFxJMxnQezYDL/7Gh77q neWadbSgsyTTHshKVfTCRiDVevg/A9RWKFa697DLmxkDxweLBe5t3Dl4hAWpwQ== Received: from [IPV6:2601:644:9381:f410:9dec:66dd:91f5:f125] (unknown [IPv6:2601:644:9381:f410:9dec:66dd:91f5:f125]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T4N0Y626NznFb; Tue, 2 Jan 2024 19:17:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <886e1a57-2e2e-4869-ae8d-0427ef771d41@FreeBSD.org> Date: Tue, 2 Jan 2024 11:17:48 -0800 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: b4efc6277634 - main - LinuxKPI: Do not use explicit context in FPU sections on powerpc64 Content-Language: en-US To: Vladimir Kondratyev , Vladimir Kondratyev , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202312241320.3BODK2DA076069@gitrepo.freebsd.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/30/23 7:14 PM, Vladimir Kondratyev wrote: > On 27.12.2023 20:05, John Baldwin wrote: >> On 12/24/23 5:20 AM, Vladimir Kondratyev wrote: >>> The branch main has been updated by wulf: >>> >>> URL: >>> https://cgit.FreeBSD.org/src/commit/?id=b4efc62776344a9aaada5a0866e453e528a0e977 >>> >>> commit b4efc62776344a9aaada5a0866e453e528a0e977 >>> Author:     Vladimir Kondratyev >>> AuthorDate: 2023-12-24 12:48:06 +0000 >>> Commit:     Vladimir Kondratyev >>> CommitDate: 2023-12-24 12:48:06 +0000 >>> >>>      LinuxKPI: Do not use explicit context in FPU sections on >>> powerpc64 >>>      It is not supported yet. >>>      Sponsored by:   Serenity Cyber Security, LLC >>>      Fixes:  5a3bd281672b ("LinuxKPI: Add explicit software context to >>> FPU sections") >>>      MFC after:      1 week >>> --- >>>   sys/compat/linuxkpi/common/include/linux/compat.h | 5 ----- >>>   sys/compat/linuxkpi/common/src/linux_current.c    | 9 ++++++--- >>>   sys/compat/linuxkpi/common/src/linux_fpu.c        | 3 ++- >>>   3 files changed, 8 insertions(+), 9 deletions(-) >> >> Do you need explicit contexts at all? > > Original version of https://reviews.freebsd.org/D42822 did not use > explicit contexts. > >   That is, can you not just >> use FPU_KERN_NOCTX all the time?  Most code in the tree now uses >> FPU_KERN_NOCTX now (all the crypto drivers for example), and I've >> been thinking about removing support for the !FPU_KERN_NOCTX case. >> Is there a reason drm-kmod can't use FPU_KERN_NOCTX?  Do you really >> need to save FPU registers in one block of code wrapped by fpu_kern_* >> and then use those register values in a future section wrapped by >> fpu_kern_*? >> > > I can revert current code end use previous version. Just give me some > time. > I will be AFK till the end of january. Hmm, well the review for that answers my question which is that there is GPU driver code that calls malloc() while in an FPU section. So the answer to my original question is, no, you can't just use FPU_KERN_NOCTX. Or if you did you would need to patch the driver code instead to narrow the FPU context usage so it wasn't enabled when malloc() is called. I don't know how feasible it would be to fix the drivers to narrow the FPU sections, but I think you would have to do that if you wanted to go back to always using FPU_KERN_NOCTX. -- John Baldwin