From: Wei Yang <richardw.yang@linux.intel.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Wei Yang <richardw.yang@linux.intel.com>,
akpm@linux-foundation.org, aarcange@redhat.com, hughd@google.com,
linux-mm@kvack.org
Subject: Re: [PATCH 1/2] userfaultfd: remove one unnecessary warn_on in __mcopy_atomic_hugetlb
Date: Thu, 26 Sep 2019 10:56:38 +0800 [thread overview]
Message-ID: <20190926025638.GA7636@richard> (raw)
In-Reply-To: <89ab9534-33c6-523c-bef0-282826af1be5@oracle.com>
On Wed, Sep 25, 2019 at 07:10:46PM -0700, Mike Kravetz wrote:
>On 9/25/19 5:35 PM, Wei Yang wrote:
>> On Wed, Sep 25, 2019 at 10:44:58AM -0700, Mike Kravetz wrote:
>>> On 9/25/19 5:18 AM, Wei Yang wrote:
>>>> The warning here is to make sure address(dst_addr) and length(len -
>>>> copied) are huge page size aligned.
>>>>
>>>> While this is ensured by:
>>>>
>>>> dst_start and len is huge page size aligned
>>>> dst_addr equals to dst_start and increase huge page size each time
>>>> copied increase huge page size each time
>>>
>>> Can we also remove the following for the same reasons?
>>>
>>> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
>>> index 640ff2bd9a69..f82d5ec698d8 100644
>>> --- a/mm/userfaultfd.c
>>> +++ b/mm/userfaultfd.c
>>> @@ -262,7 +262,6 @@ static __always_inline ssize_t __mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
>>> pte_t dst_pteval;
>>>
>>> BUG_ON(dst_addr >= dst_start + len);
>>> - VM_BUG_ON(dst_addr & ~huge_page_mask(h));
>>>
>>
>> Thanks for your comment.
>>
>> It looks good, while I lack some knowledge between vma_hpagesize and
>> huge_page_mask().
>
>vma_hpagesize is just a local variable used so that repeated calls to
>vma_kernel_pagesize() or huge_page_size() are not necessary.
>
Thanks for your confirmation. If this is the case, we can remove this BUG_ON
safely.
>> If they are the same, why not use the same interface for all those checks in
>> this function?
>
>If we remove the VM_BUG_ON, that is the only use of huge_page_mask() in
>the function.
>
>We can can also eliminate a call to huge_page_size() by making this change.
>
>@@ -273,7 +272,7 @@ static __always_inline ssize_t __mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
> mutex_lock(&hugetlb_fault_mutex_table[hash]);
>
> err = -ENOMEM;
>- dst_pte = huge_pte_alloc(dst_mm, dst_addr, huge_page_size(h));
>+ dst_pte = huge_pte_alloc(dst_mm, dst_addr, vma_hpagesize);
> if (!dst_pte) {
> mutex_unlock(&hugetlb_fault_mutex_table[hash]);
> goto out_unlock;
Agree, and also with this I think
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index c153344774c7..74363f0a0dd0 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -315,7 +315,7 @@ static __always_inline ssize_t __mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
err = copy_huge_page_from_user(page,
(const void __user *)src_addr,
- pages_per_huge_page(h), true);
+ vma_hpagesize / PAGE_SIZE, true);
if (unlikely(err)) {
err = -EFAULT;
goto out;
After these cleanup, we use vma_pagesize to deal with all page size related
calculation in this function, which looks more consistent to me.
Does it looks good to you?
>--
>Mike Kravetz
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2019-09-26 2:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 12:18 [PATCH 1/2] userfaultfd: remove one unnecessary warn_on in __mcopy_atomic_hugetlb Wei Yang
2019-09-25 12:18 ` [PATCH 2/2] userfaultfd: wrap the common dst_vma check into an inlined function Wei Yang
2019-09-25 17:44 ` [PATCH 1/2] userfaultfd: remove one unnecessary warn_on in __mcopy_atomic_hugetlb Mike Kravetz
2019-09-26 0:35 ` Wei Yang
2019-09-26 2:10 ` Mike Kravetz
2019-09-26 2:56 ` Wei Yang [this message]
2019-09-26 17:20 ` Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190926025638.GA7636@richard \
--to=richardw.yang@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.