Skip to content
  • Jiri Bohac's avatar
    x86/gart: Exclude GART aperture from vmcore · 99790140
    Jiri Bohac authored
    
    [ Upstream commit 2a3e83c6 ]
    
    On machines where the GART aperture is mapped over physical RAM
    /proc/vmcore contains the remapped range and reading it may cause hangs or
    reboots.
    
    In the past, the GART region was added into the resource map, implemented
    by commit 56dd669a ("[PATCH] Insert GART region into resource map")
    
    However, inserting the iomem_resource from the early GART code caused
    resource conflicts with some AGP drivers (bko#72201), which got avoided by
    reverting the patch in commit 707d4eef ("Revert [PATCH] Insert GART
    region into resource map"). This revert introduced the /proc/vmcore bug.
    
    The vmcore ELF header is either prepared by the kernel (when using the
    kexec_file_load syscall) or by the kexec userspace (when using the kexec_load
    syscall). Since we no longer have the GART iomem resource, the userspace
    kexec has no way of knowing which region to exclude from the ELF header.
    
    Changes from v1 of this patch:
    Instead of excluding the aperture from the ELF header, this patch
    makes /proc/vmcore return zeroes in the second kernel when attempting to
    read the aperture region. This is done by reusing the
    gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN
    balooned memory. This works for both, the kexec_file_load and kexec_load
    syscalls.
    
    [Note that the GART region is the same in the first and second kernels:
    regardless whether the first kernel fixed up the northbridge/bios setting
    and mapped the aperture over physical memory, the second kernel finds the
    northbridge properly configured by the first kernel and the aperture
    never overlaps with e820 memory because the second kernel has a fake e820
    map created from the crashkernel memory regions. Thus, the second kernel
    keeps the aperture address/size as configured by the first kernel.]
    
    register_oldmem_pfn_is_ram can only register one callback and returns an error
    if the callback has been registered already. Since XEN used to be the only user
    of this function, it never checks the return value. Now that we have more than
    one user, I added a WARN_ON just in case agp, XEN, or any other future user of
    register_oldmem_pfn_is_ram were to step on each other's toes.
    
    Fixes: 707d4eef
    
     ("Revert [PATCH] Insert GART region into resource map")
    Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Cc: Baoquan He <bhe@redhat.com>
    Cc: Toshi Kani <toshi.kani@hpe.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: yinghai@kernel.org
    Cc: joro@8bytes.org
    Cc: kexec@lists.infradead.org
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox7g6@dwarf.suse.cz
    
    
    Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    99790140