From: linmiaohe <linmiaohe@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: mmap: Merge vma after call_mmap() if possible
Date: Fri, 17 Jul 2020 01:04:56 +0000 [thread overview]
Message-ID: <6de8156c657a42e7a6acc24a5234b637@huawei.com> (raw)
Andrew Morton <akpm@linux-foundation.org> wrote:
>On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe <linmiaohe@huawei.com> wrote:
>
>> From: Miaohe Lin <linmiaohe@huawei.com>
>>
>> The vm_flags may be changed after call_mmap() because drivers may set
>> some flags for their own purpose. As a result, we failed to merge the
>> adjacent vma due to the different vm_flags as userspace can't pass in the same one.
>> Try to merge vma after call_mmap() to fix this issue.
>>
>> Signed-off-by: Hongxiang Lou <louhongxiang@huawei.com>
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
>> + /* If vm_flags changed after call_mmap(), we should try merge vma again
>> + * as we may succeed this time.
>> + */
>> + if (unlikely(vm_flags != vma->vm_flags && prev)) {
>> + merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, vma->vm_flags,
>> + NULL, vma->vm_file, vma->vm_pgoff, NULL, NULL_VM_UFFD_CTX);
>> + if (merge) {
>> + fput(file);
>> + vm_area_free(vma);
>> + vma = merge;
>> + goto unmap_writable;
>
>Shouldn't we update local variable `vm_flags' here, to pick up the change? And possibly `addr'?
Yes, we should. `vm_flags` and `addr` should be updated to continue the work. Many thanks for your
great review. I will fix it and test again. I will send a patch v2 soon.
next reply other threads:[~2020-07-17 1:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 1:04 linmiaohe [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-07-16 7:33 [PATCH] mm: mmap: Merge vma after call_mmap() if possible linmiaohe
2020-07-14 3:55 linmiaohe
2020-07-14 3:07 linmiaohe
2020-07-14 3:20 ` Andrew Morton
2020-07-16 22:24 ` Andrew Morton
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=6de8156c657a42e7a6acc24a5234b637@huawei.com \
--to=linmiaohe@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.