Re: Fw: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section

[Peter Robinson]

I've pushed this, I can't say I'm particularly happy about it as
there's still no resolution upstream as to the best direction. This
will need to happen soon because I won't be pushing the patch to 4.9
or later.

On Mon, Oct 10, 2016 at 3:52 PM, Robert Richter
 wrote:
> Peter,
>
> please consider this fix for Fedora 25 and Rawhide. It fixes a boot
> issue I have had with ThunderX systems. Now a Fedora 25 kernel boots
> without any issues.
>
> Tested on Fedora 25 (4.8.0-1.thunderx.1.fc26.aarch64, using
> devicetree, local fedpkg build), ThunderX crb2s system (dual node),
> based on rpms/kernel.git:
>
> 9510c8110910 Add patch to fix Xorg starting with virtio (rhbz 1366842)
>
> Upstream thread:
>
> http://www.spinics.net/lists/arm-kernel/msg535191.html
>
> Though the solution for the fix is still under discussion upstream, we
> should apply it to the kernel package and remove it later once a fix
> made it upstream.
>
> Should I send a patch for rpms/kernel.git? Please let me know patch
> logistic and if there is anything else to do to integrate the fix.
>
> Thanks,
>
> -Robert
>
> ----- Forwarded message from Robert Richter  -----
>
> Subject: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
> Date: Thu, 6 Oct 2016 11:52:07 +0200
> From: Robert Richter 
> To: Catalin Marinas , Will Deacon 
> CC: Ard Biesheuvel , David Daney , Mark Rutland , Hanjun Guo , [e-mail],
>         [e-mail], Robert Richter , [e-mail]
> Message-ID: 
> X-Mailer: git-send-email 2.7.0.rc3
> Content-Type: text/plain
> Return-Path: [e-mail]
>
> There is a memory setup problem on ThunderX systems with certain
> memory configurations. The symptom is
>
> kernel BUG at mm/page_alloc.c:1848!
>
> This happens for some configs with 64k page size enabled. The bug
> triggers for page zones with some pages in the zone not assigned to
> this particular zone. In my case some pages that are marked as nomap
> were not reassigned to the new zone of node 1, so those are still
> assigned to node 0.
>
> The reason for the mis-configuration is a change in pfn_valid() which
> reports pages marked nomap as invalid:
>
> 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
>
> This causes pages marked as nomap being no long reassigned to the new
> zone in memmap_init_zone() by calling __init_single_pfn().
>
> Fixing this by restoring the old behavior of pfn_valid() to use
> memblock_is_memory(). Also changing users of pfn_valid() in arm64 code
> to use memblock_is_map_memory() where necessary. This only affects
> code in ioremap.c. The code in mmu.c still can use the new version of
> pfn_valid().
>
> Should be marked stable v4.5..
> Signed-off-by: Robert Richter
>
> arch/arm64/mm/init.c    | 2 +-
>  arch/arm64/mm/ioremap.c | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index bbb7ee76e319..25b8659c2a9f 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>  #ifdef CONFIG_HAVE_ARCH_PFN_VALID
>  int pfn_valid(unsigned long pfn)
>  {
>   return memblock_is_map_memory(pfn << PAGE_SHIFT);
>   return memblock_is_memory(pfn << PAGE_SHIFT);
>
> }
>  EXPORT_SYMBOL(pfn_valid);
>  #endif
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index 01e88c8bcab0..c17c220b0c48 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -21,6 +21,7 @@
>   */
>
> #include <linux/export.h>
> +#include <linux/memblock.h>
>  #include <linux/mm.h>
>  #include <linux/vmalloc.h>
>  #include <linux/io.h>
> @@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
>         /*
>          * Don't allow RAM to be mapped.
>          */
>   if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>   if (WARN_ON(memblock_is_map_memory(phys_addr)))
>           return NULL;
>
>   area = get_vm_area_caller(size, VM_IOREMAP, caller);
>
> @@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap);
>  void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
>  {
>         /* For normal memory we already have a cacheable mapping. */
>   if (pfn_valid(__phys_to_pfn(phys_addr)))
>   if (memblock_is_map_memory(phys_addr))
>           return (void __iomem *)__phys_to_virt(phys_addr);
>
>   return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
>
> --
> 2.7.0.rc3
>
> ----- End forwarded message -----