[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01ad01d1c085$b61fdd60$225f9820$@alibaba-inc.com>
Date: Tue, 07 Jun 2016 14:27:48 +0800
From: "Hillf Danton" <hillf.zj@...baba-inc.com>
To: "'Mike Kravetz'" <mike.kravetz@...cle.com>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>
Cc: "'Andrea Arcangeli'" <aarcange@...hat.com>,
"'Hugh Dickins'" <hughd@...gle.com>,
"'Dave Hansen'" <dave.hansen@...ux.intel.com>,
"'Kirill A. Shutemov'" <kirill.shutemov@...ux.intel.com>,
"'Naoya Horiguchi'" <n-horiguchi@...jp.nec.com>,
"'Michal Hocko'" <mhocko@...e.com>,
"'Andrew Morton'" <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 3/6] mm/userfaultfd: add __mcopy_atomic_hugetlb for huge page UFFDIO_COPY
> @@ -182,6 +354,13 @@ retry:
> goto out_unlock;
>
> /*
> + * If this is a HUGETLB vma, pass off to appropriate routine
> + */
> + if (dst_vma->vm_flags & VM_HUGETLB)
Use is_vm_hugetlb_page()?
And in cases in subsequent patches?
Hillf
> + return __mcopy_atomic_hugetlb(dst_mm, dst_vma, dst_start,
> + src_start, len, false);
> +
> + /*
> * Be strict and only allow __mcopy_atomic on userfaultfd
> * registered ranges to prevent userland errors going
> * unnoticed. As far as the VM consistency is concerned, it
> --
> 2.4.11
Powered by blists - more mailing lists