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 1A455EB64D9 for ; Tue, 27 Jun 2023 20:20:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77A528E0001; Tue, 27 Jun 2023 16:20:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 729C28D0001; Tue, 27 Jun 2023 16:20:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CA778E0001; Tue, 27 Jun 2023 16:20:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4CDF38D0001 for ; Tue, 27 Jun 2023 16:20:38 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1D6A4160180 for ; Tue, 27 Jun 2023 20:20:38 +0000 (UTC) X-FDA: 80949645756.26.958B2EF Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf14.hostedemail.com (Postfix) with ESMTP id 40074100003 for ; Tue, 27 Jun 2023 20:20:35 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ZodJlmnu; spf=pass (imf14.hostedemail.com: domain of shorne@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=shorne@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687897236; 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:dkim-signature; bh=+F+0Zbk3efX4mLn8Qobc5lNIjXu3jsPFwNKngSk7DrU=; b=1R+18bVUX3IjGfLBEbSYQNET075e0Woqn9P/vDjU/+PVAxM1I69yAdM0sROmg6M7AyyWFN UOz85n0tDauUHkcbym2hTWh6dcmONXE4qpuFKfNmRmvDTU8YhT3zBtdHvCEs6w1YiP04zw 3JS0A+uU3pCUPsmbrfnbmYjALZywACY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687897236; a=rsa-sha256; cv=none; b=318ND+Vy2cnb1k2mJy2ARBrQ7/UlBmJHCtks8swL2Iut3w4FU3hjJT+VZMbHryBMzbYID/ ihnoS1vPx6VJFbdxaAMN1+mAVk0iR86xRCy2ChXjb1vkOp0I710JjiOlEQR9YtrfxQdoj+ YU2k6EIPSazJ89EuKDU1DPQwb5gg5vM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=ZodJlmnu; spf=pass (imf14.hostedemail.com: domain of shorne@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=shorne@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-312826ffedbso5487986f8f.0 for ; Tue, 27 Jun 2023 13:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687897235; x=1690489235; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+F+0Zbk3efX4mLn8Qobc5lNIjXu3jsPFwNKngSk7DrU=; b=ZodJlmnuDlfsPE6ZRGdn/jwnBd8a8Sv6S9nFI5LaSmWXkRCOoM0C/YG9EtNqjlJ6VA RV/LNPMEId8ppmVuMGm43TUo3bSoxVToJdrHVR4QljduBlKmbcfOOCvt+5rGWFQEyJMF 6bJsiTp8ztIQcF0BEfRJ9jCia9nu7Q/Lhm3ZdIp8PhjuDkrjRTFae1cshOrRv4oen2zS Qn/W7uCRXVJrCscABbuBLGgerdssSk3I4MAeaIguIaa7tZJfKevOAbtyRE/5I5tXfcsl sXIhzq43o2vLCeNpP+9/p9aIPzECX/Rx7crUytb6yE871BcaGdPHXC5AbJ7D4H2YCAgE 0neg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687897235; x=1690489235; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+F+0Zbk3efX4mLn8Qobc5lNIjXu3jsPFwNKngSk7DrU=; b=KRaaNofBbD5/hlbZP21kYpovBkvR7YQTcDCeN+TgDmnJkAJleLPZcgS5PySz9qgABo uKSWMxpZttjOWXaC6FmJ6XbuJ/bDyS/14O97OwuErWjN4YCopko9xxnBuQH/SZFHGz71 u40F+fPdK4IAbD3HGmYEEVwE8Tk/fEnV5pwuEjkJkh42ljlURtsYbMnASRi+qTrWBnw3 Ig3FdYNcQ8QxeXWkXneL2jQkHNqQUSlAdkQ5J+AXWRsKLtp7Z8FZ94zKrPaBNJuZZYnZ fN8VRSiKthRI3K1HMq6eQhrInMwVnDaSwU1vQC2xELexRmqG4+MUjh8PgtiBHrTOLj7W khqQ== X-Gm-Message-State: AC+VfDxm3VZA8vcnGvXVzSRaVxokzUtoGWwjrYf1e7ZC9gpkfLY1LyoJ Bp6aW3gLjezqYJpyCXN7IOE= X-Google-Smtp-Source: ACHHUZ6F7WJzRmHL9mdLvQRGMe1DgzoJOPiuuU5ZXKNgvDHEjkRd7iUd+k9rc4UojLUrQzYRzTpC7w== X-Received: by 2002:a05:6000:11cd:b0:313:eaac:f337 with SMTP id i13-20020a05600011cd00b00313eaacf337mr6965044wrx.53.1687897234376; Tue, 27 Jun 2023 13:20:34 -0700 (PDT) Received: from localhost (cpc1-brnt4-2-0-cust862.4-2.cable.virginm.net. [86.9.131.95]) by smtp.gmail.com with ESMTPSA id b3-20020a05600010c300b00313f9367844sm3938220wrx.88.2023.06.27.13.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jun 2023 13:20:33 -0700 (PDT) Date: Tue, 27 Jun 2023 21:20:33 +0100 From: Stafford Horne To: Rich Felker Cc: Szabolcs Nagy , LKML , Linux OpenRISC , Jonas Bonn , Stefan Kristiansson , Eric Biederman , Kees Cook , "Jason A. Donenfeld" , Dominik Brodowski , linux-mm@kvack.org Subject: Re: [PATCH 3/4] openrisc: Support floating point user api Message-ID: References: <20230418165813.1900991-1-shorne@gmail.com> <20230418165813.1900991-4-shorne@gmail.com> <20230626213840.GA1236108@port70.net> <20230627175638.GD3630668@port70.net> <20230627192719.GR20050@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230627192719.GR20050@brightrain.aerifal.cx> X-Rspamd-Queue-Id: 40074100003 X-Rspam-User: X-Stat-Signature: dfijpc9jzt9hthw4k3zq8ci545m7iipu X-Rspamd-Server: rspam03 X-HE-Tag: 1687897235-719906 X-HE-Meta: U2FsdGVkX18XcmhOHPai2UklQjLSSdLqLMt/yZ6dbyFkleY4ivtnVyNhKVBXlc9U+mtuzenkIpxsVULZWYVJgRNlnN55PlrGKOvsIBK0POgzPbAS6zMDdc8EzjpAbvzbtSuh28X+S3XNpN2ve5TN5iPvh470XvpbBuWAHBtcPoz4bLCfUvIv6k4EHFNsdUTjCGSiibpmrUUNJbiVbIDIaMXU8TV0Vans86ZLrzJpsba5mG/K0sm1Rwob4EpCTujhtuiscFLviiu8w2Fwa1FCQ1DUvpLz+BkENgVSnyKxt6mjwl310FD4Rub+NBOZwZ7I3wr22p6HRygil4vbKJj+uuFdRhhMIGfR+xmY8B9J76/8s8vMKbNB19IentvR+G7YbTwJ5tdN5FqqPFcb8dM8uN6PzkzKCHwPYmaKD79JvNkfAuiLyxQaA9cmNYUsYKgqAMUS3St8gZu6uSyDeaObMpqZ/KasbLyJkHrOnIl1B61UIM/XhnLKN44vBUatgv/WizysrTWpzCDKHXUnsIrIAEpIRMThZl8ySTGMuLS+meVqP2wat83r19kXx9+7P/fWUsJGdscOvq9cfs0VptNyBfsolvBkUCCe9Sr2AZrlFIR2SMtBwbREztUS88J1osuD8eifOk61CPGnaAKZaLgWcb+SVprx3qiylbHuwbrPRVQ5nSgOhKZyKQoP/a3mu7R27l/5RMoY61Y+w1WvDlwVfj8tPz0Qze4yy03vUH7Jf34NlDRYrnICCB9I47TUVqGMiG5qfYytg5G4smK1LUMzG7zB0dQBL+2uj1GZO0nt4voVEFtpRI/7djPd9Cxqa6xU7KdzWLajZSbmj0vxIn6HxgEdj3ou2CN0qZKc5jhISWQgguSTwIMfNH9j3HoKu12+hwRO3EUK9atuWiix72+cXunK75d3/MN4/yVDaAT1UNicg4CnDF8Tey4WMBSdbNApaZKw2s3JjhFQNcesc4M 7t7/0JnD 1cEzcrEm22a/ASBINTHDhwGhay/VC9hLMmwomOkx4nLDsF9STfMErpgj1NnlQoohQO+/bAHxsPi5RvfHNixiD7tSK3REKEPV3e+E7Tux6gPppVy+eoGTot84ZM+Uze3TRa17x8HCbl3S+u33PgHhbaX9aDvbrDXZIxn/9TGzYUF1UfEsrJCLQKeSsX2i1Yg5NM85p3SXHiBgf3sGJ+IWQJDg9DfAQm2WAklcU8sPAOspVokoTNmLBA3GcNCasn5bKAw6Q3hVkDiubztaOXuS3hokfVDYCeF9SEpskL+VKQC+sHqsb5zQlLoWbqUn2nfcjZwQbX9cvIWQaileLle5vLUUtV3r6LLLAuRGvczLhNaESaPPdsZIILq11iFdzQVUCVA9j2QEpVOgBh+PKd/eqLnc+VafGfKP1gQ22uc4vxgrSIhodKHfEVtGSvudtfQD1Hfpyxk6Z5Yj4MK8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 27, 2023 at 03:27:19PM -0400, Rich Felker wrote: > On Tue, Jun 27, 2023 at 07:56:38PM +0200, Szabolcs Nagy wrote: > > * 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. > > Indeed, mcontext_t cannot be modified because uc_sigmask follows it in > ucontext_t. The only clean solution here is probably to store the > additional data at offsets past > > sizeof(struct sigcontext) + sizeof(sigset_t) > > and not expose this at all in the uapi types. Some hwcap flag can > inform userspace that this additional space is present and accessible > if that's needed. > > Optionally you could consider exposing this in the uapi headers' > ucontext_t structure; whether it's an API breakage depends on whether > userspace is relying on being able to allocate its own ucontext_t etc. > This would leave the actual userspace headers (provided by libc) free > to decide whether to modify their type or not according to an > assessment of whether it's a breaking change to application linkage. > > What's not workable though is the ABI break that shipped in 6.4. It's > a serious violation of "don't break userspace" and makes existing > application binaries just *not work* (cancellation breaks and possibly > corrupts program state). This needs to be reverted. Hi Szabolcs, Rich, Let me work on reverting the bits that try to expose fpcsr in sigcontext. I am very aware of rules about not breaking userspace, but for some reason this was completely missed. I don't think we do have any need to expose this to userspace at the moment so I prefer to just leave the fpu state out of sigcontext if that is usable. The fix will take me about a day or two to get tested and sent. -Stafford