[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bc472a86-5a5d-9551-5680-8519b8682169@huawei.com>
Date: Thu, 11 Apr 2024 10:18:58 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
<brauner@...nel.org>, <oleg@...hat.com>, <tandersen@...flix.com>,
<mjguzik@...il.com>, <willy@...radead.org>, <kent.overstreet@...ux.dev>,
<zhangpeng.00@...edance.com>, <hca@...ux.ibm.com>, <mike.kravetz@...cle.com>,
<muchun.song@...ux.dev>, <thorvald@...gle.com>, <Liam.Howlett@...cle.com>,
<jane.chu@...cle.com>
Subject: Re: [PATCH] fork: defer linking file vma until vma is fully
initialized
On 2024/4/11 4:21, Andrew Morton wrote:
> On Wed, 10 Apr 2024 17:14:41 +0800 Miaohe Lin <linmiaohe@...wei.com> 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.
.
> .
>
Powered by blists - more mailing lists