[PATCH -next 0/3] replace open coded VA->PA calculation

[Ard Biesheuvel]

On Mon, 20 Dec 2021 at 19:06, Andrew Lunn <andrew at lunn.ch> wrote:
>
> On Mon, Dec 20, 2021 at 04:39:43PM +0100, Arnd Bergmann wrote:
> > On Sat, Dec 18, 2021 at 9:58 AM Gaosheng Cui <cuigaosheng1 at huawei.com> wrote:
> > >
> > > These patches replace an open coded calculation to obtain the physical
> > > address of a far symbol with a call to the new ldr_l etc macro, and they
> > > belong to the kaslr patch set of arm32.
> > >
> > > Reference: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest
> > >
> > > Ard Biesheuvel (3):
> > >   arm-soc: exynos: replace open coded VA->PA conversions
> > >   arm-soc: mvebu: replace open coded VA->PA conversion
> > >   arm-soc: various: replace open coded VA->PA calculation
> >
> > Usually these patches should go through the respective platform
> > maintainer trees,
> > and from there into the soc tree, but time is a little short here.
> >
> > I could apply them directly with the maintainer Acks
>
> Sorry, but this is too low level for me to understand what is going
> on, and so feel confident actually giving an ACK for the mvebu change.
>
> Should the resulting assembly be exactly the same? Has the submitter
> disassembled the object code and shown there is no actual difference
> in the assembler output?
>

The assembly does not stay the same, that is really the point of these
patches: to replace hard to understand pointer arithmetic with simple
position independent macro invocations.

However, I don't think it really makes sense at this point to merge
these: the KASLR patches are ancient and never constituted more than a
proof of concept, so grabbing bits and pieces of it arbitrarily seems
rather pointless. Note that there is an effort underway to implement a
4/4 VM split for ARM, which has a huge impact on KASLR, and so those
changes need a lot of work and discussion before we can proceed with
them.

So in summary, NACK for this series.