On 2024/4/11 4:21, Andrew Morton wrote: > On Wed, 10 Apr 2024 17:14:41 +0800 Miaohe Lin <linmiaohe@xxxxxxxxxx> wrote: > >> Thorvald reported a WARNING [1]. And the root cause is below race: >> >> CPU 1 CPU 2 >> fork hugetlbfs_fallocate >> dup_mmap hugetlbfs_punch_hole >> i_mmap_lock_write(mapping); >> vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. >> i_mmap_unlock_write(mapping); >> hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! >> i_mmap_lock_write(mapping); >> hugetlb_vmdelete_list >> vma_interval_tree_foreach >> hugetlb_vma_trylock_write -- Vma_lock is cleared. >> tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! >> hugetlb_vma_unlock_write -- Vma_lock is assigned!!! >> i_mmap_unlock_write(mapping); >> >> hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside >> i_mmap_rwsem lock while vma lock can be used in the same time. Fix this >> by deferring linking file vma until vma is fully initialized. Those vmas >> should be initialized first before they can be used. > > Cool. I queued this in mm-hotfixes (for 6.8-rcX) and I added a cc:stable. Thanks for doing this. And any comment or thought would be really welcome and appreciated. . > . >
