On 6/26/26 16:45, Alexander Krabler wrote:
> On 6/24/26 13:08, Wandun wrote:
>> On 6/22/26 17:55, Vlastimil Babka (SUSE) wrote:
>>> On 6/18/26 13:43, Wandun wrote:
>>>> Yes, I wrote a test case that can reproduce it in a few second.
>>>>
>>>> The test case contains 3 steps:
>>>> 1. mlockall
>>>> 2. mmap file(2GB) + trigger file write page fault;
>>>> 3. during step 1, trigger compact via /proc/sys/vm/compact_memory
>>>>
>>>>
>>>> My reproduction environment is qemu with 4GB ram, 8 core, aarch64,
>>>> preempt_rt and includes the tracepoint in patch 02.
>>>> After running the reproduction program for a few seconds, the
>>>> following output appears.
>>>>
>>>> repro-403 [004] ....1 101.270505: mm_compaction_isolate_folio:
>>>> pfn=0x71e3a mode=0x0
>> flags=referenced|uptodate|mlocked
>>>> repro-403 [004] ....1 101.270507: mm_compaction_isolate_folio:
>>>> pfn=0x71e3b mode=0x0
>> flags=referenced|uptodate|mlocked
>>>> repro-403 [004] ....1 101.270513: mm_compaction_isolate_folio:
>>>> pfn=0x71e3c mode=0x0
>> flags=referenced|uptodate|mlocked
>>>> repro-403 [004] ....1 101.270515: mm_compaction_isolate_folio:
>>>> pfn=0x71e3d mode=0x0
>> flags=uptodate|mlocked
>>>> repro-403 [004] ....1 101.270517: mm_compaction_isolate_folio:
>>>> pfn=0x71e3e mode=0x0
>> flags=uptodate|mlocked
>>>> repro-403 [004] ....1 101.270520: mm_compaction_isolate_folio:
>>>> pfn=0x71e3f mode=0x0
>> flags=uptodate|mlocked
>
> I applied your PATCH 2/3 to our kernel and checked with your reproducer,
> I get similar output, e.g.
> t_compact-2148 [005] ....1 515.320221: mm_compaction_isolate_folio:
> pfn=0xe66c2 mode=0x0
>
> flags=referenced|uptodate|active|swapbacked|mlocked
>
> With your first patch applied, the amount of these messages decrease.
Parts of mlocked but not unevictable pages has been filter out, so
messages decrease, but racy is still there.
> I was not able to apply your third patch to our (older) kernel.
Patch 3 is meaningless to you. The problem in your report is caused by
kcompactd,
not cma alloc, so it is of no use to you.
>
> However, we were not able to reproduce the actual race
> (mlockall() process waiting on a migration PTE),
> not in the past, not now. Might be hard to trigger that race.
Not hard to trigger that case, I added a debug message, such as below,
lots of messages occur in a few second.
diff --cc mm/memory.c
index ff338c2abe92,ff338c2abe92..6552b3b14f78
--- a/mm/memory.c
+++ b/mm/memory.c
@@@ -4768,6 -4768,6 +4768,8 @@@ vm_fault_t do_swap_page(struct vm_faul
if (softleaf_is_migration(entry)) {
migration_entry_wait(vma->vm_mm, vmf->pmd,
vmf->address);
+ if (!strcmp(current->comm, "repro"))
+ pr_err("============== hit ================\n");
} else if (softleaf_is_device_exclusive(entry)) {
vmf->page = softleaf_to_page(entry);
ret = remove_device_exclusive_entry(vmf);
Best regard,
Wandun
>
>> IIUC, more accurately, the migration entry in the page talbe is real a bad
>> for
>> RT process, because isolate page doesn't modify the page table, so memory
>> access continues as usual, therefore a new idea occur.
>>
>> S1. In the mlock[all] syscall, if mlock_vma_pages_range hit a migration
>> entry,
>> then, it should wait for the migration to complete.
>>
>> S2. During the unmap phase of memory migration, prevent a page from being
>> unmapped
>> if the page's associated vma is markd with VM_LOCKED, similar to how
>> reclaim is
>> disabled for pages in a VM_LOCKED vma(try_to_unmap_one).
>>
>>
>> For a page handled during the mlock[all] syscall:
>> - if migration has been already finished, there is noting to do;
>> - if migration is in progress and the migration etnry is already filled, we
>> wait (S1)
>> - if the page is in-fight, going to be isolated/migrated, S2 prevents the
>> unmap.
>>
>> For a page handled during a page fault: VM_LOCKED is already set on the vma,
>> so S2 guarantees it will not be unmapped, hence no migration entry.
>
> I do not understand all details of this, but it looks good,
> especially the S1 case makes a lot of sense for me.
>
> Nitpick: I suggest to switch order of PATCH 1 and 2 for the next iteration,
> introducing the tracepoint first and then improve the situation.
>
> Thanks a lot for looking into this issue!
>
> Best regards,
> Alexander
>
> --
>
> KUKA Deutschland GmbH Board of Directors: Michael Jürgens (Chairman), Johan
> Naten, Hui Zhang Registered Office: Augsburg HRB 14914
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of contents of this e-mail is strictly
> forbidden.
>
> Please consider the environment before printing this e-mail.
