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 B342DC41513 for ; Sun, 23 Jul 2023 21:04:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AC5C6B0071; Sun, 23 Jul 2023 17:04:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15D466B0074; Sun, 23 Jul 2023 17:04:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0240A6B0075; Sun, 23 Jul 2023 17:04:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E493D6B0071 for ; Sun, 23 Jul 2023 17:04:52 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BA5AFC07F8 for ; Sun, 23 Jul 2023 21:04:52 +0000 (UTC) X-FDA: 81044106024.01.366ED0B Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf25.hostedemail.com (Postfix) with ESMTP id C8994A0002 for ; Sun, 23 Jul 2023 21:04:50 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Rpu8vTC5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of shorne@gmail.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=shorne@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690146290; 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=JJ7/4DXG7QClXNpcfbVGF9Xk1htkcz3DMZ3n7khqPCM=; b=T54IDHG2EYNv8zd7+ZI+mLGlQrzNvFl2ahaGytd3f0eEwAowDEBBaeckGL0ui+hc2mMFfJ 3OmDpgWsVLmtfrI0Ox1Ph66JT2rWP11xSoWGmbe20xXSDREbJBiHdJZ6Fksi2Jvo5Qi/mf z9pgG12oIHUBBEStcS6Z7bHlxEWpzQ8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Rpu8vTC5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of shorne@gmail.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=shorne@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690146290; a=rsa-sha256; cv=none; b=u9omp5onxlSdb9+8guFUryNbqreUeH6Hg7LrP5ulbkhEPk39AItHAuez7eBMfWqHJX3KDY EjRFE0kuDv5/PMm5zFB3GlleHC1iLFpUYnCEbuuRGfDZ+JEjs9A8vliycs6fXCuClda2uJ wHZyBTuDScwJoEP5AizbPpErnN+0kiY= Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3fbc77e76abso27963075e9.1 for ; Sun, 23 Jul 2023 14:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690146289; x=1690751089; 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=JJ7/4DXG7QClXNpcfbVGF9Xk1htkcz3DMZ3n7khqPCM=; b=Rpu8vTC5wyZqz8eFNzFy5r2Fj/z33FaVXv8YIftoq1Zf1eJzBvIBgl0xmvbPjrG9zQ nmE99EJK/pLxdRiVfWXM3husN6I/FPkB1ZlKEcHvmJ8C6UVeQHXCQs2Hz/LBTKML5wAd HGMVRKUYwxxDJuqc0c5y1ggD7Lr5TBKl0f4DWs+dCJzzrpY4LzQB6K85AvcSuYC82oJT Y3U/5cMsMrdPKJVZuArFgrOneSFRBp2uMz/0VwdYofOWYFOXFAVS3OjP2gYPG9aB0X5M 0hiwQPCMRs2wy2wAHtHbA/38bY9O2Ocf8FQ3uqK5jAqoXLL2QYrOd//4NroXFSDQM742 zY+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690146289; x=1690751089; 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=JJ7/4DXG7QClXNpcfbVGF9Xk1htkcz3DMZ3n7khqPCM=; b=YtpbX5ZRH0xYAdVK+rVWdUmRDrt2LFZ6ol8AFZQIKbRCy//HXj3oNgseP3P1KRCKbu B7LaywNl9idsrHZVl9JD964+WpmDsna8YmCounloD9zaJkkyviitWu3tX2OOMG9lLHgq tH4wWSx+brbeO9rh07TBRS6wc7YEWHxWtcrx6KzXTSyifEfahTbB0JCTiSFZYEfzELKd tY9eN7Y9jR7OkNZGrEC4e4IMvbs7BuduuoofzzDm8n+U5TCuMPzC1BYRSWOLSwdC1Mkv F7G72b3H2wIXki/DJfL59hG2dgvkLpy7t2Di1p3Bc0rJlp30QQmS+xyeud4kJblCWiV5 /kJw== X-Gm-Message-State: ABy/qLaHOtzlNhrB1as/i+yRHE2eG+cWr0ihWT9RoEFRdz6CGp0DU63J NX+of+YxCCiOoSBNEtmyU/M= X-Google-Smtp-Source: APBJJlEMh5zqNvgl5FMCHp6O5xJGXJCMhbW6fHdy/aTOSH8HhF9kax7W7lNYIgSrigW6BJVTCnKfsg== X-Received: by 2002:a7b:cd91:0:b0:3f7:f584:579b with SMTP id y17-20020a7bcd91000000b003f7f584579bmr5246805wmj.9.1690146288972; Sun, 23 Jul 2023 14:04:48 -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 n11-20020a7bcbcb000000b003fba92fad35sm11120257wmi.26.2023.07.23.14.04.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 14:04:48 -0700 (PDT) Date: Sun, 23 Jul 2023 22:04:47 +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: C8994A0002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sx5u341mzkno3tuuaa3ad43se6u3bwz5 X-HE-Tag: 1690146290-602838 X-HE-Meta: U2FsdGVkX18WMXMVT7X7DOiykSkJcOkPWPnKdbyne5/OYR7zMhY0KAf3W6tuZrgoQvKT5sxbN+RFb47WAmp6b7QaCK/bVwWMLW+VoHblX+Q4KEhBvdxe4wUPDs8B67B9N+KdlOe9smCa4ycd9Q4mGg0I+gl5hjuu3heGbL77GP3P2q/sNPmoHdGH6Qq5FfOyS/xvcVeyuBzsPKjB1OLOq8b1MZ6s96etgEUh8PKaZpJQ7G3ZR/T3oOxriRzD/K6SG7hdSW9FlEvli+514/QzGYw+nnqM3EmprjuGrBe9mZ6GUmiYp2H2/IOIgaCcJZyTnYzCTS/qy8AE/nidWlaqrbgvMCmGwKdkU/vDfpoeTivWntqxCmC871/YU2ucO6oNGXFDqfP3YFJrvoURoDGRcwOH8piBjQIRtHwnwAL8dMrukORZBSAXayzXyP2OoOHnAOfMtW1YtXOQUjn147Ppw+yh6eEJEJJlR3I6lklBQOXCry1E8wZwhw1+64YtrGTeBDxARoUQCuJ9Y7XkzE0ZvQ71W30YDpFINDOc2ZU4ItmopcYVV0MwGsO4If2NRmgXINL0nU32dJOQqqE2Zvu5GW1/BTxu8vxY0WRGAEZshwkugi1YcBsOAQh/HCHB5ur1YWeDyW4V5J4NrJywNHcYcl38REySY8wz9ehH1qQj4UqdHV6AMWb61WFCG0I8k+xKLriJGFAro4mX6/EioXf0l2f4qQCj9km3wJh0ZF/uQwwibL+BhYVgewpPRmCZHPaQjAL/c6/LzWYWkNHjyWmYzamkeqTbzz7vM+wR5dBZ1ffBCsT+eOkUsbYSvCsvp/P0gmBhKW/k9FrR1n2aDXJuf8o6y5lAJj484dZqdDc8w1fawNMS6kjfvXhb/GGlhtjkWs1bUyftyVgrkrxIN2XlnJoNzS0HyDYo67vJ1IQMlaWebX7eA0Jp71z5dVrRpLyhnqluXTpTJFRCsTSsunf rLdhI3aW VAhFl5UKyBtSxmhn49RTHDvbwVR5+GvCdcMlAEV9Q4e8FExjcMCXGTgCnOpR0PoAeZEZxrXqJr8h/dQw29a5GjT0U5XoRLX5050F2B9PuEcMlzF7hWxaIplGbuGXH9WN3UkFVxBahqPICszGB/JzWJSXcbwJhJQtbQMAToxCGh3h8SSIbk/B7b2uXtmZosUkyHWq+9UbHAwEbT23FYNZGKQlMEAwNZN9bChqNG9EBcHxt6zqRQyFzEfeZaR42BqzdlQSLwvoxutzPQK+n3JrbTOD5o2hDWaqn0R4V97FnVK2vXjSXDSvhPXFhHhh4LAHKsO4qdfSIZoFjYPf80gsX5WF/AVlaU40T75SkOAIiK4scGy8Dv5U+2bLCJqToj+iv7N68th428H+cxjw9a5ikZsbLZ/otnzaQFAqSwT8rItssB3rsg2hSOYzAreYk6H4x0xtR6qEk9BlD8ec= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003063, 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, My fix for this has now made it into 6.4.5 stable release. You should be able to use this release to update musl. The fix was to use some unused space in sigcontext, for the fpu state. -Stafford