lkml.org 
[lkml]   [2022]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] hugetlb: fix memory leak associated with vma_lock structure
From
Date
On 2022/10/20 4:19, Mike Kravetz wrote:
> The hugetlb vma_lock structure hangs off the vm_private_data pointer
> of sharable hugetlb vmas. The structure is vma specific and can not
> be shared between vmas. At fork and various other times, vmas are
> duplicated via vm_area_dup(). When this happens, the pointer in the
> newly created vma must be cleared and the structure reallocated. Two
> hugetlb specific routines deal with this hugetlb_dup_vma_private and
> hugetlb_vm_op_open. Both routines are called for newly created vmas.
> hugetlb_dup_vma_private would always clear the pointer and
> hugetlb_vm_op_open would allocate the new vms_lock structure. This did
> not work in the case of this calling sequence pointed out in [1].
> move_vma
> copy_vma
> new_vma = vm_area_dup(vma);
> new_vma->vm_ops->open(new_vma); --> new_vma has its own vma lock.
> is_vm_hugetlb_page(vma)
> clear_vma_resv_huge_pages
> hugetlb_dup_vma_private --> vma->vm_private_data is set to NULL
> When clearing hugetlb_dup_vma_private we actually leak the associated
> vma_lock structure.
>
> The vma_lock structure contains a pointer to the associated vma. This
> information can be used in hugetlb_dup_vma_private and hugetlb_vm_op_open
> to ensure we only clear the vm_private_data of newly created (copied)
> vmas. In such cases, the vma->vma_lock->vma field will not point to the
> vma.
>
> Update hugetlb_dup_vma_private and hugetlb_vm_op_open to not clear
> vm_private_data if vma->vma_lock->vma == vma. Also, log a warning if
> hugetlb_vm_op_open ever encounters the case where vma_lock has already
> been correctly allocated for the vma.
>
> [1] https://lore.kernel.org/linux-mm/5154292a-4c55-28cd-0935-82441e512fc3@huawei.com/
>
> Fixes: 131a79b474e9 ("hugetlb: fix vma lock handling during split vma and range unmapping")
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>

Thanks for update. This patch looks good to me.

Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>

Thanks,
Miaohe Lin


> ---
> v2 - Allocate vma_lock in hugetlb_vm_op_open if !vma->vm_private_data
> on entry. Thanks Miaohe Lin!
>
> mm/hugetlb.c | 35 +++++++++++++++++++++++++++--------
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 02f781624fce..ccdffc2fa1ca 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1014,15 +1014,23 @@ void hugetlb_dup_vma_private(struct vm_area_struct *vma)
> VM_BUG_ON_VMA(!is_vm_hugetlb_page(vma), vma);
> /*
> * Clear vm_private_data
> + * - For shared mappings this is a per-vma semaphore that may be
> + * allocated in a subsequent call to hugetlb_vm_op_open.
> + * Before clearing, make sure pointer is not associated with vma
> + * as this will leak the structure. This is the case when called
> + * via clear_vma_resv_huge_pages() and hugetlb_vm_op_open has already
> + * been called to allocate a new structure.
> * - For MAP_PRIVATE mappings, this is the reserve map which does
> * not apply to children. Faults generated by the children are
> * not guaranteed to succeed, even if read-only.
> - * - For shared mappings this is a per-vma semaphore that may be
> - * allocated in a subsequent call to hugetlb_vm_op_open.
> */
> - vma->vm_private_data = (void *)0;
> - if (!(vma->vm_flags & VM_MAYSHARE))
> - return;
> + if (vma->vm_flags & VM_MAYSHARE) {
> + struct hugetlb_vma_lock *vma_lock = vma->vm_private_data;
> +
> + if (vma_lock && vma_lock->vma != vma)
> + vma->vm_private_data = NULL;
> + } else
> + vma->vm_private_data = NULL;
> }
>
> /*
> @@ -4601,6 +4609,7 @@ static void hugetlb_vm_op_open(struct vm_area_struct *vma)
> struct resv_map *resv = vma_resv_map(vma);
>
> /*
> + * HPAGE_RESV_OWNER indicates a private mapping.
> * This new VMA should share its siblings reservation map if present.
> * The VMA will only ever have a valid reservation map pointer where
> * it is being copied for another still existing VMA. As that VMA
> @@ -4615,11 +4624,21 @@ static void hugetlb_vm_op_open(struct vm_area_struct *vma)
>
> /*
> * vma_lock structure for sharable mappings is vma specific.
> - * Clear old pointer (if copied via vm_area_dup) and create new.
> + * Clear old pointer (if copied via vm_area_dup) and allocate
> + * new structure. Before clearing, make sure vma_lock is not
> + * for this vma.
> */
> if (vma->vm_flags & VM_MAYSHARE) {
> - vma->vm_private_data = NULL;
> - hugetlb_vma_lock_alloc(vma);
> + struct hugetlb_vma_lock *vma_lock = vma->vm_private_data;
> +
> + if (vma_lock) {
> + if (vma_lock->vma != vma) {
> + vma->vm_private_data = NULL;
> + hugetlb_vma_lock_alloc(vma);
> + } else
> + pr_warn("HugeTLB: vma_lock already exists in %s.\n", __func__);
> + } else
> + hugetlb_vma_lock_alloc(vma);
> }
> }
>
>

\
 
 \ /
  Last update: 2022-10-20 04:04    [W:0.040 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site