linux-kernel - Re: 6.10/bisected/regression - commit 8430557fc584 cause warning at mm/page_table_check.c:198 __page_table_check_ptes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 21 May 2024 18:36:01 -0400
From: Peter Xu <peterx@...hat.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
Cc: Pavel Tatashin <pasha.tatashin@...een.com>, axelrasmussen@...gle.com,
	David Hildenbrand <david@...hat.com>, nadav.amit@...il.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux List Kernel Mailing <linux-kernel@...r.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

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@...hat.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