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: Thu, 16 Jul 2020 07:33:05 +0000 [thread overview]
Message-ID: <3da69bbf7f0d485ca1c8e4a44d5010c6@huawei.com> (raw)
linmiaohe <linmiaohe@huawei.com> wrote:
>Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe <linmiaohe@huawei.com> wrote:
>>
>>> 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.
>>
>>Which drivers do this?
>
>> I searched the code and I see many drivers change the vm_flags, such as aio_ring_mmap set VM_DONTEXPAND and amdgpu_mmap , binder_mmap also change the vm_flags , and so on...
>>
>>Thanks.
>>
I'am sorry. I offered the VM_DONTEXPAND case to you which belongs to VM_SPECIAL. I found some other cases:
i810_mmap_buffers:
set VM_DONTCOPY
dax_mmap:
ext4_file_mmap:
xfs_file_mmap:
set VM_HUGEPAGE
These vm_flags don't belong to VM_SPECIAL and should be vma mergeable case.
In fact, this problem is found on my own product env. We set VM_DONTCOPY in driver mmap ops, and we got this:
400000000000-400000001000 rw-s 105cee000 00:06 64086 /dev/...
400000001000-400000002000 rw-s 105cef000 00:06 64086 /dev/...
400000002000-400000003000 rw-s 105cf0000 00:06 64086 /dev/...
400000003000-400000004000 rw-s 105cf1000 00:06 64086 /dev/...
400000004000-400000005000 rw-s 105cf2000 00:06 64086 /dev/...
400000005000-400000006000 rw-s 105cf3000 00:06 64086 /dev/...
400000006000-400000007000 rw-s 105cf4000 00:06 64086 /dev/...
400000007000-400000008000 rw-s 105cf5000 00:06 64086 /dev/...
400000008000-400000009000 rw-s 105cf6000 00:06 64086 /dev/...
400000009000-40000000a000 rw-s 105cf7000 00:06 64086 /dev/...
40000000a000-40000000b000 rw-s 105cf8000 00:06 64086 /dev/...
40000000b000-40000000c000 rw-s 105cf9000 00:06 64086 /dev/...
40000000c000-40000000d000 rw-s 105cfa000 00:06 64086 /dev/...
40000000d000-40000000e000 rw-s 105cfb000 00:06 64086 /dev/...
40000000e000-40000000f000 rw-s 105cfc000 00:06 64086 /dev/...
40000000f000-400000010000 rw-s 105cfd000 00:06 64086 /dev/...
400000010000-400000011000 rw-s 105cfe000 00:06 64086 /dev/...
400000011000-400000012000 rw-s 105cff000 00:06 64086 /dev/...
400000012000-400000013000 rw-s 105d00000 00:06 64086 /dev/...
400000013000-400000014000 rw-s 105d01000 00:06 64086 /dev/...
400000014000-400000015000 rw-s 105d02000 00:06 64086 /dev/...
400000015000-400000016000 rw-s 105d03000 00:06 64086 /dev/...
400000016000-400000017000 rw-s 105d04000 00:06 64086 /dev/...
400000017000-400000018000 rw-s 105d05000 00:06 64086 /dev/...
400000018000-400000019000 rw-s 105d06000 00:06 64086 /dev/...
400000019000-40000001a000 rw-s 105d07000 00:06 64086 /dev/...
40000001a000-40000001b000 rw-s 105d08000 00:06 64086 /dev/...
40000001b000-40000001c000 rw-s 105d09000 00:06 64086 /dev/...
40000001c000-40000001d000 rw-s 105d0a000 00:06 64086 /dev/...
40000001d000-40000001e000 rw-s 105d0b000 00:06 64086 /dev/...
40000001e000-40000001f000 rw-s 105d0c000 00:06 64086 /dev/...
The vma flags are same, vma address are adjacent, belong to same file and so on...
I believe this expose the old uncommon bug. I hope I explain it clearly this time.
Many thanks.
next reply other threads:[~2020-07-16 7:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 7:33 linmiaohe [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-07-17 1:04 [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=3da69bbf7f0d485ca1c8e4a44d5010c6@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.