From: Dave Martin <Dave.Martin@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Joey Gouly <joey.gouly@arm.com>
Subject: Re: [PATCH] arm64: signal: Update sigcontext reservations table
Date: Wed, 4 Sep 2024 12:24:24 +0100 [thread overview]
Message-ID: <ZthDaHYOfp1sFvIj@e133380.arm.com> (raw)
In-Reply-To: <f49a13d7-8efb-4f4a-a9d7-a84db4ded075@sirena.org.uk>
On Tue, Sep 03, 2024 at 07:26:04PM +0100, Mark Brown wrote:
> On Tue, Sep 03, 2024 at 03:18:25PM +0100, Dave Martin wrote:
> > On Fri, Aug 23, 2024 at 12:46:05PM +0100, Will Deacon wrote:
>
> > > I suppose we could, but I must confess that I find this comment a lot
> > > easier to digest that the fiddly maze of inconsistent macros we have
> > > for the different contexts. Then again, all that really matters, I
> > > suppose, is that we don't accidentally over-allocate the maximum size
> > > of the sigcontext. That ought to be enforceable.
>
> ...
>
> > I think my best approach for now would be to try to wire up something
> > that at least helps remind us that we need to review this table when
> > something new is added in the sigframe, unless you can think of a
> > better idea.
>
> It be good to add a selftest that flags this, that way people might
> notice when adding things and if we miss something it'll probably turn
> up in one of the CIs at some point (possibly after it's too late but at
> least we'd know). That'd give us some level of integration test with
> whatever libcs and other default software are actually doing, as opposed
> to what we think they'll do.
I suppose we could write a test that sets VL=64, SVL=32 and dirties the
SVE and SME regs before triggering a signal, then checks that
extra_context is not there. This will only work if SVE and SME are
present and big enough. If we can run this as a routine CI test on a
model, it might be useful though.
Cheers
---Dave
next prev parent reply other threads:[~2024-09-04 11:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 14:41 [PATCH] arm64: signal: Update sigcontext reservations table Dave Martin
2024-07-29 14:53 ` Mark Brown
2024-07-29 15:51 ` Dave Martin
2024-07-29 17:01 ` Mark Brown
2024-07-30 12:51 ` Dave Martin
2024-07-30 13:22 ` Mark Brown
2024-07-30 15:07 ` Dave Martin
2024-07-30 16:00 ` Mark Brown
2024-07-31 10:38 ` Dave Martin
2024-07-31 11:49 ` Mark Brown
2024-07-31 14:38 ` Dave Martin
2024-07-31 14:58 ` Mark Brown
2024-07-31 16:09 ` Dave Martin
2024-07-31 16:14 ` Mark Brown
2024-07-31 16:23 ` Dave Martin
2024-08-20 13:37 ` Will Deacon
2024-08-20 14:38 ` Dave Martin
2024-08-23 11:46 ` Will Deacon
2024-09-03 14:18 ` Dave Martin
2024-09-03 18:26 ` Mark Brown
2024-09-04 11:24 ` Dave Martin [this message]
2024-09-04 11:49 ` Mark Brown
2024-09-05 10:59 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZthDaHYOfp1sFvIj@e133380.arm.com \
--to=dave.martin@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.