[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANOLnOObzMk7YQACtWz8rEKgP0DYVgvk0g9JViK1v7sP9n0Xeg@mail.gmail.com>
Date: Tue, 16 Feb 2016 00:08:34 +0200
From: Grazvydas Ignotas <notasas@...il.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: remap_file_pages regression
On Mon, Feb 15, 2016 at 12:26 PM, Kirill A. Shutemov
<kirill.shutemov@...ux.intel.com> wrote:
> On Mon, Feb 15, 2016 at 03:32:55AM +0200, Grazvydas Ignotas wrote:
>> Hi,
>>
>> since remap_file_pages() rework the following simple program fails.
>> I haven't actually bisected this, only know it worked on 3.19 at least
>> (I bought a new system now and need 4.2+ for hardware support).
>
> The patch below should fix the issue. Please test.
It works, thanks.
Tested-by: Grazvydas Ignotas <notasas@...il.com>
>
>> If you are curious, the program is an emulator and is using
>> remap_file_pages() to implement memory mirroring efficiently (and to
>> remap things during run time).
>
> Could you elaborate on this?
>
> Why creating file on tmpfs/shmem (using memfd_create() for example) plus
> plain mmap()s wouldn't work for you?
It works, but remap_file_pages() is just more convenient, you don't
need many mmap()/munmap() calls (less syscalls), and as the emulator
needs to reconfigure the mappings during runtime (it's not a one time
init thing), remap_file_pages() makes more sense. The reduced number
of VMAs of the past was also a benefit I guess.
Actually I'm not the author of the emulator in question, so I've asked
the author to comment:
--- quote ---
One of the things we do with remap_file_pages is a mapping for the
emulated system's VRAM. The system allows many different
configurations of several differently sized VRAM banks to a 16MB area
of address space. The banks are multiples of 16KB in size and their
allocations are also 16KB aligned. With remap_file_pages we can map
that entire space to an (in-memory) file and then arbitrarily map
chunks of it as desired. We have an mmap-based fallback, but it
requires us to manage a separate mmap for each 16KB region."
--- end of quote ---
Apparently the mentioned fallback was a compile time option, so I was
hit with the issue after upgrading my machine.
> <snip>
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
Cc: stable?
Fixes: c8d78c182 (I guess?)
> Reported-by: Grazvydas Ignotas <notasas@...il.com>
> ---
> mm/mmap.c | 34 +++++++++++++++++++++++++++++-----
> 1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2f2415a7a688..76d1ec29149b 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2664,12 +2664,29 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start, unsigned long, size,
> if (!vma || !(vma->vm_flags & VM_SHARED))
> goto out;
>
> - if (start < vma->vm_start || start + size > vma->vm_end)
> + if (start < vma->vm_start)
> goto out;
>
> - if (pgoff == linear_page_index(vma, start)) {
> - ret = 0;
> - goto out;
> + if (start + size > vma->vm_end) {
> + struct vm_area_struct *next;
> +
> + for (next = vma->vm_next; next; next = next->vm_next) {
> + /* hole between vmas ? */
> + if (next->vm_start != next->vm_prev->vm_end)
> + goto out;
> +
> + if (next->vm_file != vma->vm_file)
> + goto out;
> +
> + if (next->vm_flags != vma->vm_flags)
> + goto out;
> +
> + if (start + size <= next->vm_end)
> + break;
> + }
> +
> + if (!next)
> + goto out;
> }
>
> prot |= vma->vm_flags & VM_READ ? PROT_READ : 0;
> @@ -2679,9 +2696,16 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start, unsigned long, size,
> flags &= MAP_NONBLOCK;
> flags |= MAP_SHARED | MAP_FIXED | MAP_POPULATE;
> if (vma->vm_flags & VM_LOCKED) {
> + struct vm_area_struct *tmp;
> flags |= MAP_LOCKED;
> +
> /* drop PG_Mlocked flag for over-mapped range */
> - munlock_vma_pages_range(vma, start, start + size);
> + for (tmp = vma; tmp->vm_start >= start + size;
> + tmp = tmp->vm_next) {
> + munlock_vma_pages_range(tmp,
> + max(tmp->vm_start, start),
> + min(tmp->vm_end, start + size));
> + }
> }
>
> file = get_file(vma->vm_file);
> --
> Kirill A. Shutemov
GraÅžvydas
Powered by blists - more mailing lists