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@xxxxxxxxxx> 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+0x1c04debug_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