[PATCH 5/9] arm64: alternatives: make alt_region const

[Mark Rutland]

On Mon, Sep 12, 2022 at 11:13:12AM +0100, Ard Biesheuvel wrote:
> On Mon, 12 Sept 2022 at 10:32, Mark Rutland <mark.rutland at arm.com> wrote:
> >
> > On Tue, Sep 06, 2022 at 05:18:54PM +0200, Ard Biesheuvel wrote:
> > > Hi Mark,
> > >
> > > On Thu, 1 Sept 2022 at 17:14, Mark Rutland <mark.rutland at arm.com> wrote:
> > > >
> > > > We never alter a struct alt_region after creation, and we open-code the
> > > > bounds of the kernel alternatives region in two functions.
> > > >
> > > > This patch adds a shared struct alt_region, and marks the alt regions as
> > > > const to prevent unintentional modification.
> > > >
> > >
> > > What is the point of struct alt_region? Can we just get rid of it
> > > entirely? It seems its only purpose is to carry a <start, end> tuple
> > > that could easily be converted into start and end arguments to
> > > __apply_alternatives().
> >
> > We could right now, but I'm intending to fix some noinstr issues (and make
> > debugging easier) by splitting the alternatives sanity-checking & patching into
> > distinct initcalls (alnog with some extra debug), and having the structure for
> > the common definition is quite nice to avoid open-coding the start and end
> > value in a bunch of places.
> >
> > So I'd prefer to keep it for now, but I can follow up and delete it if the
> > above doesn't turn out to need it, if that's ok?
> >
> 
> Yeah, that's fine. The above wasn't really clear to me from the
> context you provided.

True; I'll add a note to the commit message.

Thanks,
Mark.