[PATCH 3/5] arm64: signal: Improve POR_EL0 handling to avoid uaccess failures

[Kevin Brodsky]

On 21/10/2024 15:43, Dave Martin wrote:
> On Mon, Oct 21, 2024 at 12:06:07PM +0200, Kevin Brodsky wrote:
>> On 17/10/2024 17:53, Dave Martin wrote:
>>> [...]
>>>> +/*
>>>> + * Save the unpriv access state into ua_state and reset it to disable any
>>>> + * restrictions.
>>>> + */
>>>> +static void save_reset_unpriv_access_state(struct unpriv_access_state *ua_state)
>>> Would _user_ be more consistent naming than _unpriv_ ?
>> I did ponder on the naming. I considered user_access/uaccess instead of
>> unpriv_access, but my concern is that it might imply that only uaccess
>> is concerned, while in reality loads/stores that userspace itself
>> executes are impacted too. I thought using the "unpriv" terminology from
>> the Arm ARM (used for stage 1 permissions) might avoid such
>> misunderstanding. I'm interested to hear opinions on this, maybe
>> accuracy sacrifices readability.
> "user_access" seemed natural to me: it parses equally as "[user
> access]" (i.e., uaccess) and "[user] access" (i.e., access by, to, or
> on behalf of user(space)).
>
> Introducing an architectural term when there is already a generic OS
> and Linux kernel term that means the right thing seemed not to improve
> readability, but I guess it's a matter of opinion.

Both good points. "user_access" seems to strike the right balance, plus
it's slightly shorter. Will switch to that naming in v2.

Kevin