From: Will Deacon <will@kernel.org>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Joey Gouly <joey.gouly@arm.com>, Mark Brown <broonie@kernel.org>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 1/4] arm64: signal: Preserve POR_EL0 if poe_context is missing
Date: Thu, 23 Apr 2026 13:41:03 +0100 [thread overview]
Message-ID: <aeoTX_6nK6oHw5OE@willie-the-truck> (raw)
In-Reply-To: <693f4d7c-46f4-409b-8944-a8c9e4b5e073@arm.com>
On Wed, Apr 22, 2026 at 04:55:05PM +0200, Kevin Brodsky wrote:
> On 22/04/2026 14:19, Will Deacon wrote:
> >> @@ -74,8 +76,12 @@ struct rt_sigframe_user_layout {
> >> * This state needs to be carefully managed to ensure that it doesn't cause
> >> * uaccess to fail when setting up the signal frame, and the signal handler
> >> * itself also expects a well-defined state when entered.
> >> + *
> >> + * The valid_fields member is a bitfield (see UA_STATE_HAS_*), specifying which
> >> + * of the remaining fields is valid (has been set to a value).
> >> */
> >> struct user_access_state {
> >> + unsigned int valid_fields;
> >> u64 por_el0;
> >> };
> > Do you think it would be worth adding some accessors to make it easier
> > to keep the flags in sync? For example:
> >
> > /* Stores por_el0 into uas->por_el0 and sets UA_STATE_HAS_POR_EL0 */
> > void set_ua_state_por_el0(struct user_access_state *uas, u64 por_el0);
> >
> > /*
> > * If UA_STATE_HAS_POR_EL0, *por_el0 = uas->por_el0 and return 0.
> > * Otherwise, return -ENOENT.
> > */
> > int get_ua_state_por_el0(struct user_access_state *uas, u64 *por_el0);
> >
> > WDYT?
>
> I did get a feeling having helpers would be a good idea. I wonder if
> getters/setters aren't a bit overkill though, as they make accesses to
> the struct more cumbersome and we'd need a pair for every member (unless
> we use some macro magic).
We only have one struct member, so it's probably fine for now, and we
could group related members together in sub-structures to help in future.
But it's up to you -- I don't feel strongly about it, but requiring the
caller to update the flag manually is going to be a bug magnet.
> Maybe it would be sufficient to have say
> ua_state_has_field(POR_EL0) to check if the bit is set, and
> ua_state_set_field_valid(POR_EL0) to set the bit?
I don't think that really helps with my concern. I'd like to avoid callers
having to remember to deal with the flags when they update the data.
Will
next prev parent reply other threads:[~2026-04-23 12:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 14:42 [PATCH 0/4] POE sigreturn fix and extra tests Kevin Brodsky
2026-04-21 14:42 ` [PATCH 1/4] arm64: signal: Preserve POR_EL0 if poe_context is missing Kevin Brodsky
2026-04-22 12:19 ` Will Deacon
2026-04-22 14:55 ` Kevin Brodsky
2026-04-23 12:41 ` Will Deacon [this message]
2026-04-24 9:24 ` Kevin Brodsky
2026-04-21 14:42 ` [PATCH 2/4] kselftest/arm64: Add POE as a feature in the signal tests Kevin Brodsky
2026-04-21 14:58 ` Mark Brown
2026-04-21 14:42 ` [PATCH 3/4] kselftest/arm64: Add POE helpers to test_signals_utils.h Kevin Brodsky
2026-04-21 15:00 ` Mark Brown
2026-04-21 14:42 ` [PATCH 4/4] kselftest/arm64: Add tests for POR_EL0 save/reset/restore Kevin Brodsky
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=aeoTX_6nK6oHw5OE@willie-the-truck \
--to=will@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox