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

[Dave Martin <Dave.Martin@arm.com>]

Hi,

On Tue, Oct 22, 2024 at 02:34:09PM +0200, Kevin Brodsky wrote:
> 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.

Suits me (wasn't sure I was going to win that one actually!)

Cheers
---Dave