[PATCH v6sub1 00/11] arm64: split linear and kernel mappings

[Catalin Marinas]

On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
> On 18 February 2016 at 20:38, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> >> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
> >>>> Ard Biesheuvel (11):
> >>>>   of/fdt: make memblock minimum physical address arch configurable
> >>>>   of/fdt: factor out assignment of initrd_start/initrd_end
> >>>>   arm64: prevent potential circular header dependencies in asm/bug.h
> >>>>   arm64: add support for ioremap() block mappings
> >>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
> >>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
> >>>>   arm64: decouple early fixmap init from linear mapping
> >>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
> >>>>   arm64: move kernel image to base of vmalloc area
> >>>>   arm64: defer __va translation of initrd_start and initrd_end
> >>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
> >>>
> >>> I queued this patches (again) for 4.6. I'll wait a few days with the
> >>> rest of KASLR until these get a bit more coverage in -next.
> >>>
> >
> > I rebased the remaining patches onto for-next/core, and pushed it here:
> > https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
> >
> > I need to check if everything still works, and if it does, I will send
> > them out as v6sub2
> > Note that I have included the arm64 extable patch plus its generic
> > dependency, and the kallsyms patches as well. We can decide later how
> > to proceed with those, but for now, I included them for completeness.
> 
> OK, as it turns out, my arm64/extable patch conflicts with the UAO
> patches that are now in for-next/core, not textually, but those
> patches add additional absolute extable entries that need to be
> updated to relative as well.

I noticed this as well while testing KASLR.

> So it appears that akpm will need to drop that patch anyway, as he
> won't be able to carry an updated version since he does not have the
> UAO patches. That means it probably makes even more sense to take
> those through the arm64 tree as well (minus the x86 one, which has a
> conflict now as well). In fact, perhaps it makes sense to only take
> the base patch and the arm64 patch, and I can send the remaining ones
> to the various maintainers (or akpm) for v4.7

Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
sort out the extable patches.

-- 
Catalin