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

[Ard Biesheuvel]

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.

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