Received-SPF: pass (google.com: domain of linux-kernel+bounces-185510-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 21 May 2024 18:36:01 -0400
From: Peter Xu <peterx@redhat.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>, axelrasmussen@google.com,
	David Hildenbrand <david@redhat.com>, nadav.amit@gmail.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: 6.10/bisected/regression - commit 8430557fc584 cause warning at
 mm/page_table_check.c:198 __page_table_check_ptes_set+0x306
Message-ID: <Zk0h0V8kvZRKu6F4@x1n>
References: <CABXGCsMB9A8-X+Np_Q+fWLURYL_0t3Y-MdoNabDM-Lzk58-DGA@mail.gmail.com>
 <Zk0HxVODITGKqYCw@x1n>
 <CABXGCsNbcMn0Z0RudFrBW78rZPE+cDY+f9r+yKf_AZwJZUOrQg@mail.gmail.com>
 <Zk0UA6wABOB9X_Dx@x1n>
 <CABXGCsOZnxrSHd0y6QrFhzAiY-uTJiRSmo__C_P8Y2qjFV6bRA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABXGCsOZnxrSHd0y6QrFhzAiY-uTJiRSmo__C_P8Y2qjFV6bRA@mail.gmail.com>

On Wed, May 22, 2024 at 03:21:04AM +0500, Mikhail Gavrilov wrote:
> On Wed, May 22, 2024 at 2:37 AM Peter Xu <peterx@redhat.com> wrote:
> > Hmm I still cannot reproduce.  Weird.
> >
> > Would it be possible for you to identify which line in debug_vm_pgtable.c
> > triggered that issue?
> >
> > I think it should be some set_pte_at() but I'm not sure, as there aren't a
> > lot and all of them look benign so far.  It could be that I missed
> > something important.
> 
> I hope it's helps:

Thanks for offering this, it's just that it doesn't look coherent with what
was reported for some reason.

> 
> > sh /usr/src/kernels/(uname -r)/scripts/faddr2line /lib/debug/lib/modules/(uname -r)/vmlinux debug_vm_pgtable+0x1c04
> debug_vm_pgtable+0x1c04/0x3360:
> native_ptep_get_and_clear at arch/x86/include/asm/pgtable_64.h:94
> (inlined by) ptep_get_and_clear at arch/x86/include/asm/pgtable.h:1262
> (inlined by) ptep_clear at include/linux/pgtable.h:509

This is a pte_clear(), and pte_clear() shouldn't even do the set() checks,
and shouldn't stumble over what I added.

IOW, it doesn't match with the real stack dump previously:

[    5.581003]  ? __page_table_check_ptes_set+0x306/0x3c0
[    5.581274]  ? __pfx___page_table_check_ptes_set+0x10/0x10
[    5.581544]  ? __pfx_check_pgprot+0x10/0x10
[    5.581806]  set_ptes.constprop.0+0x66/0xd0
[    5.582072]  ? __pfx_set_ptes.constprop.0+0x10/0x10
[    5.582333]  ? __pfx_pte_val+0x10/0x10
[    5.582595]  debug_vm_pgtable+0x1c04/0x3360

Would it be possible that e.g. you recompiled the kernel so the vmlinux
didn't match?

> (inlined by) pte_clear_tests at mm/debug_vm_pgtable.c:643
> (inlined by) debug_vm_pgtable at mm/debug_vm_pgtable.c:1392
> 
> > cat -n /usr/src/debug/kernel-6.9-10323-g8f6a15f095a6/linux-6.10.0-0.rc0.20240521git8f6a15f095a6.10.fc41.x86_64/mm/debug_vm_pgtable.c | sed -n '1387,1397 p'
>   1387 * Page table modifying tests. They need to hold
>   1388 * proper page table lock.
>   1389 */
>   1390
>   1391 args.ptep = pte_offset_map_lock(args.mm, args.pmdp, args.vaddr, &ptl);
>   1392 pte_clear_tests(&args);
>   1393 pte_advanced_tests(&args);
>   1394 if (args.ptep)
>   1395 pte_unmap_unlock(args.ptep, ptl);
>   1396
>   1397 ptl = pmd_lock(args.mm, args.pmdp);
> 
> -- 
> Best Regards,
> Mike Gavrilov.
> 

-- 
Peter Xu