Anxdrew, this whole patch-series seems to be corrupt. Not only was the "incoming" cover emal missing the base to apply it to, but the patches themselves are broken too. See for example this one: On Tue, Feb 4, 2020 at 1:34 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > From: David Hildenbrand <david@xxxxxxxxxx> > Subject: mm/page_alloc: fix and rework pfn handling in memmap_init_zone() > > Let's update the pfn manually whenever we continue the loop. This makes > the code easier to read but also less error prone (and we can directly fix > one issue). > > When overlap_memmap_init() returns true, pfn is updated to > "memblock_region_memory_end_pfn(r)". So it already points at the *next* > pfn to process. Incrementing the pfn another time is wrong, we might > leave one uninitialized. I spotted this by inspecting the code, so I have > no idea if this is relevant in practise (with kernelcore=3Dmirror). Note that "=3D". That's some MIME stuff that you haven't decoded, and then sent out as an email as-is. > Link: http://lkml.kernel.org/r/20200113144035.10848-2-david@xxxxxxxxxx > Fixes: a9a9e77fbf27 ("mm: move mirrored memory specific code outside of m= > emmap_init_zone") Same here. That "=\n" shouldn't be in the email, it comes from some original MIME data that wasn't ever properly decoded. The *patch* itself seems fine, and the "=" signs are not mime: > - for (pfn = start_pfn; pfn < end_pfn; pfn++) { > + for (pfn = start_pfn; pfn < end_pfn; ) { so it seems that only the actual explanations have gotten corrupted somehow. Cut-and-paste from some MIME source in a MUA that doesn't know mime? Or directly from some mbox file without any MIME decoding? Linus
