Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Thomas Hellstrom <thellstrom@vmware.com>
To:     Steven Price <steven.price@arm.com>,
        David Hildenbrand <david@redhat.com>
CC:     Qian Cai <cai@lca.pw>, Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Mark Rutland <Mark.Rutland@arm.com>,
        the arch/x86 maintainers <x86@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Catalin Marinas <Catalin.Marinas@arm.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        =?iso-8859-1?Q?J=E9r=F4me_Glisse?= <jglisse@redhat.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Andy Lutomirski <luto@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        James Morse <James.Morse@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Will Deacon <will@kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "Liang, Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v15 00/23] Generic page walk and ptdump
Thread-Topic: [PATCH v15 00/23] Generic page walk and ptdump
Thread-Index: AQHVqsB6USxvVndKC0O+X8JyjIw6Ng==
Date:   Wed, 4 Dec 2019 17:51:06 +0000
Message-ID: <MN2PR05MB61416E0CF8A99C91CD69FC43A15D0@MN2PR05MB6141.namprd05.prod.outlook.com>
References: <20191101140942.51554-1-steven.price@arm.com>
 <1572896147.5937.116.camel@lca.pw>
 <7B040741-EC8A-4CC0-964B-4046AE2E617A@lca.pw>
 <16da6118-ac4d-a165-6202-0731a776ac72@arm.com>
 <911fac4a-2204-f994-a101-16a60fba12e8@redhat.com>
 <0FA196FD-3FCD-431A-AA3E-21BF00EA07DC@lca.pw>
 <9d5f1689-db82-a6da-d51d-08070aa4bad5@redhat.com>
 <20191204163235.GA1597@arm.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19d7ffd5-9909-4955-959f-08d778e289b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 17:51:06.2246
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 777infu+mfbHdoYbtVmWIen0OrDr1SrCuKCYq9XkVJogJMTS+a3y30aoVSkccATQUyXI1p5ZxHTnUAAU+DPn/w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6111
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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