On 12/4/19 5:32 PM, Steven Price wrote: > On Wed, Dec 04, 2019 at 02:56:58PM +0000, David Hildenbrand wrote: >> On 04.12.19 15:54, Qian Cai wrote: >>> >>>> On Dec 3, 2019, at 6:02 AM, David Hildenbrand <david@xxxxxxxxxx> wrote: >>>> >>>> On 06.11.19 16:05, Steven Price wrote: >>>>> On 06/11/2019 13:31, Qian Cai wrote: >>>>>> >>>>>>> On Nov 4, 2019, at 2:35 PM, Qian Cai <cai@xxxxxx> wrote: >>>>>>> >>>>>>> On Fri, 2019-11-01 at 14:09 +0000, Steven Price wrote: >>>>> [...] >>>>>>>> Changes since v14: >>>>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20191028135910.33253-1-steven.price%40arm.com%2F&data=02%7C01%7Cthellstrom%40vmware.com%7C9f50ca595f81432eff5b08d778d7968a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637110739727088799&sdata=B3n6TFU7hluQyAXUOEaHBAGNC8mhscMfxSJi%2FrFr%2Flo%3D&reserved=0 >>>>>>>> * Switch walk_page_range() into two functions, the existing >>>>>>>> walk_page_range() now still requires VMAs (and treats areas without a >>>>>>>> VMA as a 'hole'). The new walk_page_range_novma() ignores VMAs and >>>>>>>> will report the actual page table layout. This fixes the previous >>>>>>>> breakage of /proc/<pid>/pagemap >>>>>>>> * New patch at the end of the series which reduces the 'level' numbers >>>>>>>> by 1 to simplify the code slightly >>>>>>>> * Added tags >>>>>>> Does this new version also take care of this boot crash seen with v14? Suppose >>>>>>> it is now breaking CONFIG_EFI_PGT_DUMP=y? The full config is, >>>>>>> >>>>>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fcailca%2Flinux-mm%2Fmaster%2Fx86.config&data=02%7C01%7Cthellstrom%40vmware.com%7C9f50ca595f81432eff5b08d778d7968a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637110739727088799&sdata=ymVh49kh7VL9yseRdkjSbTwRh%2B7yBXxhK7QMTUzwn4U%3D&reserved=0 >>>>>>> >>>>>> V15 is indeed DOA here. >>>>> Thanks for finding this, it looks like EFI causes issues here. The below fixes >>>>> this for me (booting in QEMU). >>>>> >>>>> Andrew: do you want me to send out the entire series again for this fix, or >>>>> can you squash this into mm-pagewalk-allow-walking-without-vma.patch? >>>>> >>>>> Thanks, >>>>> >>>>> Steve >>>>> >>>>> ---8<--- >>>>> diff --git a/mm/pagewalk.c b/mm/pagewalk.c >>>>> index c7529dc4f82b..70dcaa23598f 100644 >>>>> --- a/mm/pagewalk.c >>>>> +++ b/mm/pagewalk.c >>>>> @@ -90,7 +90,7 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end, >>>>> split_huge_pmd(walk->vma, pmd, addr); >>>>> if (pmd_trans_unstable(pmd)) >>>>> goto again; >>>>> - } else if (pmd_leaf(*pmd)) { >>>>> + } else if (pmd_leaf(*pmd) || !pmd_present(*pmd)) { >>>>> continue; >>>>> } >>>>> >>>>> @@ -141,7 +141,7 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end, >>>>> split_huge_pud(walk->vma, pud, addr); >>>>> if (pud_none(*pud)) >>>>> goto again; >>>>> - } else if (pud_leaf(*pud)) { >>>>> + } else if (pud_leaf(*pud) || !pud_present(*pud)) { >>>>> continue; >>>>> } >>>>> >>>>> >>>> Even with this fix, booting for me under QEMU fails. See >>>> >>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-mm%2Fb7ce62f2-9a48-6e48-6685-003431e521aa%40redhat.com%2F&data=02%7C01%7Cthellstrom%40vmware.com%7C9f50ca595f81432eff5b08d778d7968a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637110739727088799&sdata=fRuLrmrzNEkU2MFzSVdyVyXyRoyZ95yZOYuy7aMSi7A%3D&reserved=0 >>>> >>> Yes, for some reasons, this starts to crash on almost all arches here, so it might be worth >>> for Andrew to revert those in the meantime while allowing Steven to rework. >> I agree, this produces too much noise. > I've bisected this problem and it's a merge conflict with: > > ace88f1018b8 ("mm: pagewalk: Take the pagetable lock in walk_pte_range()") > > Reverting that commit "fixes" the problem. That commit adds a call to > pte_offset_map_lock(), however that isn't necessarily safe when > considering an "unusual" mapping in the kernel. Combined with my patch > set this leads to the BUG when walking the kernel's page tables. > > At this stage I think it's best if Andrew drops my series and I'll try > to rework it on top -rc1 fixing up this conflict and the other x86 > 32-bit issue that has cropped up. Hi, Unfortunately I wasn't aware of that conflict. Perhaps something similar to this https://elixir.bootlin.com/linux/v5.4/source/mm/memory.c#L2012 would fix at least this particular issue? /Thomas > > Steve >
