All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Safonov <dsafonov@virtuozzo.com>
To: <linux-kernel@vger.kernel.org>, <mingo@redhat.com>
Cc: <luto@amacapital.net>, <tglx@linutronix.de>, <hpa@zytor.com>,
	<x86@kernel.org>, <akpm@linux-foundation.org>,
	<linux-mm@kvack.org>, <0x7f454c46@gmail.com>,
	Dmitry Safonov <dsafonov@virtuozzo.com>
Subject: [PATCHv9 0/2] mremap vDSO for 32-bit
Date: Tue, 17 May 2016 15:13:50 +0300	[thread overview]
Message-ID: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> (raw)

The first patch adds support of mremapping 32-bit vDSO.
One could move vDSO vma before this patch, but fast syscalls
on moved vDSO hasn't been working. It's because of code that
relies on mm->context.vdso pointer.
So all this code is just fixup for that pointer on moving.
(Also adds preventing for splitting vDSO vma).
As Andy notted, 64-bit vDSO mremap also has worked only by a chance
before this patches.
The second patch adds a test for the new functionality.

I need possibility to move vDSO in CRIU - on restore we need
to choose vma's position:
- if vDSO blob of restoring application is the same as the kernel has,
  we need to move it on the same place;
- if it differs, we need to choose place that wasn't tooken by other
  vma of restoring application and than add jump trampolines to it
  from the place of vDSO in restoring application.

CRIU code now relies on possibility on x86_64 to mremap vDSO.
Without this patch that may be broken in future.
And as I work on C/R of compatible 32-bit applications on x86_64,
I need mremap to work also for 32-bit vDSO. Which does not work,
because of context.vdso pointer mentioned above. 

Changes:
v9: Added cover-letter with changelog and reasons for patches
v8: Add WARN_ON_ONCE on current->mm != new_vma->vm_mm;
    run test for x86_64 too;
    removed fixed VDSO_SIZE - check EINVAL mremap return for partial remapping
v7: Build fix
v6: Moved vdso_image_32 check and fixup code into vdso_fix_landing function
    with ifdefs around
v5: As Andy suggested, add a check that new_vma->vm_mm and current->mm are
    the same, also check not only in_ia32_syscall() but image == &vdso_image_32;
    added test for mremapping vDSO
v4: Drop __maybe_unused & use image from mm->context instead vdso_image_32
v3: As Andy suggested, return EINVAL in case of splitting vdso blob on mremap;
    used is_ia32_task instead of ifdefs 
v2: Added __maybe_unused for pt_regs in vdso_mremap

Dmitry Safonov (2):
  x86/vdso: add mremap hook to vm_special_mapping
  selftest/x86: add mremap vdso test

 arch/x86/entry/vdso/vma.c                      | 47 ++++++++++--
 include/linux/mm_types.h                       |  3 +
 mm/mmap.c                                      | 10 +++
 tools/testing/selftests/x86/Makefile           |  2 +-
 tools/testing/selftests/x86/test_mremap_vdso.c | 99 ++++++++++++++++++++++++++
 5 files changed, 155 insertions(+), 6 deletions(-)
 create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c

-- 
2.8.0

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Safonov <dsafonov@virtuozzo.com>
To: linux-kernel@vger.kernel.org, mingo@redhat.com
Cc: luto@amacapital.net, tglx@linutronix.de, hpa@zytor.com,
	x86@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org,
	0x7f454c46@gmail.com, Dmitry Safonov <dsafonov@virtuozzo.com>
Subject: [PATCHv9 0/2] mremap vDSO for 32-bit
Date: Tue, 17 May 2016 15:13:50 +0300	[thread overview]
Message-ID: <1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com> (raw)

The first patch adds support of mremapping 32-bit vDSO.
One could move vDSO vma before this patch, but fast syscalls
on moved vDSO hasn't been working. It's because of code that
relies on mm->context.vdso pointer.
So all this code is just fixup for that pointer on moving.
(Also adds preventing for splitting vDSO vma).
As Andy notted, 64-bit vDSO mremap also has worked only by a chance
before this patches.
The second patch adds a test for the new functionality.

I need possibility to move vDSO in CRIU - on restore we need
to choose vma's position:
- if vDSO blob of restoring application is the same as the kernel has,
  we need to move it on the same place;
- if it differs, we need to choose place that wasn't tooken by other
  vma of restoring application and than add jump trampolines to it
  from the place of vDSO in restoring application.

CRIU code now relies on possibility on x86_64 to mremap vDSO.
Without this patch that may be broken in future.
And as I work on C/R of compatible 32-bit applications on x86_64,
I need mremap to work also for 32-bit vDSO. Which does not work,
because of context.vdso pointer mentioned above. 

Changes:
v9: Added cover-letter with changelog and reasons for patches
v8: Add WARN_ON_ONCE on current->mm != new_vma->vm_mm;
    run test for x86_64 too;
    removed fixed VDSO_SIZE - check EINVAL mremap return for partial remapping
v7: Build fix
v6: Moved vdso_image_32 check and fixup code into vdso_fix_landing function
    with ifdefs around
v5: As Andy suggested, add a check that new_vma->vm_mm and current->mm are
    the same, also check not only in_ia32_syscall() but image == &vdso_image_32;
    added test for mremapping vDSO
v4: Drop __maybe_unused & use image from mm->context instead vdso_image_32
v3: As Andy suggested, return EINVAL in case of splitting vdso blob on mremap;
    used is_ia32_task instead of ifdefs 
v2: Added __maybe_unused for pt_regs in vdso_mremap

Dmitry Safonov (2):
  x86/vdso: add mremap hook to vm_special_mapping
  selftest/x86: add mremap vdso test

 arch/x86/entry/vdso/vma.c                      | 47 ++++++++++--
 include/linux/mm_types.h                       |  3 +
 mm/mmap.c                                      | 10 +++
 tools/testing/selftests/x86/Makefile           |  2 +-
 tools/testing/selftests/x86/test_mremap_vdso.c | 99 ++++++++++++++++++++++++++
 5 files changed, 155 insertions(+), 6 deletions(-)
 create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c

-- 
2.8.0

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2016-05-17 12:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 12:13 Dmitry Safonov [this message]
2016-05-17 12:13 ` [PATCHv9 0/2] mremap vDSO for 32-bit Dmitry Safonov
2016-05-17 12:13 ` [PATCHv9 1/2] x86/vdso: add mremap hook to vm_special_mapping Dmitry Safonov
2016-05-17 12:13   ` Dmitry Safonov
2016-05-17 12:13 ` [PATCHv9 2/2] selftest/x86: add mremap vdso test Dmitry Safonov
2016-05-17 12:13   ` Dmitry Safonov
2016-05-20  6:48   ` Ingo Molnar
2016-05-20  6:48     ` Ingo Molnar
2016-05-20 15:33     ` Andy Lutomirski
2016-05-20 15:33       ` Andy Lutomirski
2016-05-21 20:27       ` Ingo Molnar
2016-05-21 20:27         ` Ingo Molnar
2016-05-22  5:43         ` Dmitry Safonov
2016-05-22  5:43           ` Dmitry Safonov
2016-06-08 11:41         ` Dmitry Safonov
2016-06-08 11:41           ` Dmitry Safonov
2016-06-17  8:03   ` Ingo Molnar
2016-06-17  8:03     ` Ingo Molnar
2016-06-17  9:24     ` Dmitry Safonov
2016-06-17  9:24       ` Dmitry Safonov
2016-05-19  9:50 ` [PATCHv9 0/2] mremap vDSO for 32-bit Dmitry Safonov
2016-05-19  9:50   ` Dmitry Safonov

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=1463487232-4377-1-git-send-email-dsafonov@virtuozzo.com \
    --to=dsafonov@virtuozzo.com \
    --cc=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.