From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73AEDEB64DC for ; Tue, 27 Jun 2023 17:56:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D5D88D0003; Tue, 27 Jun 2023 13:56:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 085B08D0001; Tue, 27 Jun 2023 13:56:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8F718D0003; Tue, 27 Jun 2023 13:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D96E48D0001 for ; Tue, 27 Jun 2023 13:56:44 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A82B81C877E for ; Tue, 27 Jun 2023 17:56:44 +0000 (UTC) X-FDA: 80949283128.12.12CB0CE Received: from port70.net (port70.net [81.7.13.123]) by imf01.hostedemail.com (Postfix) with ESMTP id 774EC4001F for ; Tue, 27 Jun 2023 17:56:42 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of nsz@port70.net designates 81.7.13.123 as permitted sender) smtp.mailfrom=nsz@port70.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687888602; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=lYZF6RrCM9atbxDY1SKx0hOfA7+Ztx5vGgKSOu3B6wY=; b=oBdl8U3VzuH5xOHvQKTvRMelRcEdURC6/TFoGOjNI0QjDKnzgPnWkJ4tW64O0EabF//YT6 GSwNwp48RLcfniHpxInRJrDWxs5i+v7bQ7772mgYhg6q+Nw0QLDiHNLyff56SqnreQB1F5 0LAwYn5r+3SPqc1kj1hPfRySCt1DH4c= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of nsz@port70.net designates 81.7.13.123 as permitted sender) smtp.mailfrom=nsz@port70.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687888602; a=rsa-sha256; cv=none; b=Vzem1ghMdHi7ugRnbXaFa3DNC1YkjE6Y4lv9n/E4Q9JjNFLRa4j0N/v3q1WRbaMTuHiwvd y9pPEQba7kqNMhg52D/dD662PkL3G9Q5POBQfSFPD2PKa3GOV7l8RxJDYYRmmm9rFZfo3k J9Lb82xR5cOTubly4MNcpbTwTHGZitQ= Received: by port70.net (Postfix, from userid 1002) id D1130ABEC0C7; Tue, 27 Jun 2023 19:56:38 +0200 (CEST) Date: Tue, 27 Jun 2023 19:56:38 +0200 From: Szabolcs Nagy To: Stafford Horne Cc: LKML , Linux OpenRISC , Jonas Bonn , Stefan Kristiansson , Eric Biederman , Kees Cook , "Jason A. Donenfeld" , Dominik Brodowski , linux-mm@kvack.org, Rich Felker Subject: Re: [PATCH 3/4] openrisc: Support floating point user api Message-ID: <20230627175638.GD3630668@port70.net> References: <20230418165813.1900991-1-shorne@gmail.com> <20230418165813.1900991-4-shorne@gmail.com> <20230626213840.GA1236108@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 774EC4001F X-Stat-Signature: 1f3wkh5bdsr6fkzayejy7foxtw8xoc39 X-Rspam-User: X-HE-Tag: 1687888602-603485 X-HE-Meta: U2FsdGVkX1/TQUFUfXxGBT3S3vmA0qaBQRWWIWjiYdZHrpeZKgYMwjEIfNJ60BUsVKy75ggZk/Rpc89pEcMoJgHLAyiVZJ4XvbqhmuT4UO6AiQ0uhVFSHL8mDnzdWW6d9msG5Cw0WXS1/CIXuzCue6C5qeR3XRFz1oojtXUBkHe9/taqaAeFjU8MLWHq/CrvT+052/LUbGJTpY+FoHRXEZZI2MCW4p3UEWJkszkCVIfYySEP8uj/4zVMBNhJo7V8cGfWL1Q44FSv7IsOSPUNIDXt18Tj77Sthu7Up4zG/JgCmTQgXqNnopfdyBggjrUJMHhF63xLkJEDdtu/91+gM33/6NnIRQzwf/SeSPbU5Vhpr+MnNMPSU/4r/CSLCavp2ngYuX/uIb8/tqxq4Z1SV0rk+Dt3kLNB68nMUQTxJXOr2V3xdl/fo4d7SKgo7+ZIu8ES4tQYz9RPonoGS6o1TOheS5T0cptlp6nWjR9I1S+7GzRjtAJcEcm5kdFeQn0OmABFRrkUgql94HaIyXcFKZ/MytLw8Tur186GsFBfi8S8raD4ZCif7voz5Cr2o9MDwHdFcWbb3lupQjpCVTtS6UmSr+P/rL+V3BLqqy+4AfF5mA2EDpZeI6f/TJ3vJh7lUT3S9+PW79xV6x2SgdLVSCA18PLQQYa7g+yIQtHO1rq037b87Xa3xUXEa9PrCH+zOWY8CWiSRMh5lKC3YL2+zNiPWvuzLnS1IadB7k1MzwNdfqgAg0d9uhEXZ91V3OV9Ju93m1y2lNZgUfRaGUk/1sw4ct70evuewPdgLMbUfghO+i/Yp2Iu4xD3F7HGL5cPgySYCaRz3PFsMQLaN3Ng9Vfj2bNokJ6T2WOkGQgPwB1sP8reLdDimfj5t6l0InRS06ZYKsBzl44N4e0lYLF8p5K6WQilT7axPn0jI6/wVyHR6X6Orclt6Dn8d+lqkXv/g+x/InkWICr5zjT725E Pd2On4sx ZHvsDQ8fi/V+XKBSpD4vMb7Jb9yMAbASXXrIcfXIo+0gYZ7AwnDhLxYJwuTAj6UiZPhef X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: * Stafford Horne [2023-06-27 17:41:03 +0100]: > On Mon, Jun 26, 2023 at 11:38:40PM +0200, Szabolcs Nagy wrote: > > * Stafford Horne [2023-04-18 17:58:12 +0100]: > > > Add support for handling floating point exceptions and forwarding the > > > SIGFPE signal to processes. Also, add fpu state to sigcontext. > > > > > > Signed-off-by: Stafford Horne > > > --- > > ... > > > --- a/arch/openrisc/include/uapi/asm/sigcontext.h > > > +++ b/arch/openrisc/include/uapi/asm/sigcontext.h > > > @@ -28,6 +28,7 @@ > > > > > > struct sigcontext { > > > struct user_regs_struct regs; /* needs to be first */ > > > + struct __or1k_fpu_state fpu; > > > unsigned long oldmask; > > > }; > > > > this seems to break userspace abi. > > glibc and musl have or1k abi without this field. > > > > either this is a new abi where binaries opt-in with some marking > > and then the base sigcontext should be unmodified, > > > > or the fp state needs to be added to the signal frame in a way that > > does not break existing abi (e.g. end of the struct ?) and also > > advertise the new thing via a hwcap, otherwise userspace cannot > > make use of it. > > > > unless i'm missing something. > > I think you are right, I meant to look into this but it must have slipped > though. Is this something causing you issues or did you just notice it? i noticed it while trying to update musl headers to linux 6.4 uapi. > I didn't run into issues when running the glibc test suite, but I may have > missed it. i would only expect issues when accessing ucontext entries after uc_mcontext.regs in a signal handler registered with SA_SIGINFO. in particular uc_sigmask is after uc_mcontext on or1k and e.g. musl thread cancellation uses this entry to affect the mask on signal return which will not work on a 6.4 kernel (not tested). i don't think glibc has tests for the ucontext signal abi. > Just moving this to the end of the sigcontext may be all that is needed. that won't help since uc_sigmask comes after sigcontext in ucontext. it has to go to the end of ucontext or outside of ucontext then. one way to have fpu in sigcontext is struct sigcontext { struct user_regs_struct regs; unsigned long oldmask; char padding[sizeof(__userspace_sigset_t)]; struct __or1k_fpu_state fpu; }; but the kernel still has to interpret the padding in a bwcompat way. (and if libc wants to expose fpu in its ucontext then it needs a flag day abi break as the ucontext size is abi.) (part of the userspace uc_sigmask is unused because sigset_t is larger than necessary so may be that can be reused but this is a hack as that's libc owned.) not sure how important this fpu field is, arm does not seem to have fpu state in ucontext and armhf works. there may be other ways, i'm adding Rich (musl maintainer) on cc in case he has an opinion.