Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1411210 > unrolled thread

[PATCH 0/6] x86: 32-bit compatible C/R on x86_64

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/6] x86: 32-bit compatible C/R on x86_64 Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-06-01 15:20 +0200
    [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-06-01 15:20 +0200
      Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Cyrill Gorcunov <gorcunov@gmail.com> - 2016-06-03 12:00 +0200
        Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Cyrill Gorcunov <gorcunov@gmail.com> - 2016-06-03 12:50 +0200
      Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Oleg Nesterov <oleg@redhat.com> - 2016-06-07 00:30 +0200
        Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-06-07 13:40 +0200
        Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Andy Lutomirski <luto@amacapital.net> - 2016-06-09 19:30 +0200
          Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Oleg Nesterov <oleg@redhat.com> - 2016-06-10 22:10 +0200
            Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Andy Lutomirski <luto@amacapital.net> - 2016-06-10 22:20 +0200
              Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Oleg Nesterov <oleg@redhat.com> - 2016-06-13 16:00 +0200
                Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Andy Lutomirski <luto@amacapital.net> - 2016-06-13 22:50 +0200
                  Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32) Oleg Nesterov <oleg@redhat.com> - 2016-06-14 16:40 +0200
    [PATCH 1/6] x86/vdso: unmap vdso blob on vvar mapping failure Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-06-01 15:20 +0200
    [PATCH 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_* Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-06-01 15:20 +0200

#1411210 — [PATCH 0/6] x86: 32-bit compatible C/R on x86_64

This patches set is an attempt to add checkpoint/restore
for 32-bit tasks in compatibility mode on x86_64 hosts.

Restore in CRIU starts from one root restoring process, which
reads info for all threads being restored from images files.
This information is used further to to find out which processes
share some resources. Later shared resources are restored only
by one process and all other inherit them.
After that it calls clone() and new threads restore their
properties in parallel. Those threads inherit all parent's
mappings and fetch properties from those mappings
(and do clone themself, if they have children/subthreads). [1]
Then starts restorer blob's play, it's PIE binary, which
unmaps all unneeded for restoring VMAs, maps new VMAs and
finalize restoring with sigreturn syscall. [2]

To restore of 32-bit task we need three things to do in running
x86_64 restorer blob:
a) set code selector to __USER32_CS (to run 32-bit code);
b) remap vdso blob from 64-bit to 32-bit
   This is primary needed because restore may happen on a different
   kernel, which has different vDSO image than we had on dump.
c) if 32-bit vDSO differ to dumped image, move it on free place
   and add jump trampolines to that place.
d) switch TIF_IA32 flag, so kernel would know that it deals with
   compatible 32-bit application.

From all this:
a) setting CS may be done from userspace, no patches needed;
b) patches 1-3 add ability to map different vDSO blobs on x86 kernel;
c) for remapping/moving 32-bit vDSO blob patches have been send earlier
   and seems to be accepted [3]
d) and for swapping TIF_IA32 flag discussion with Andy ended in conclusion
   that it's better to remove this flag completely.
   Patches 4-6 deletes usage of TIF_IA32 from ptrace, signal and coredump
   code. This is rework/resend of RFC [4]

[1] https://criu.org/Checkpoint/Restore#Restore
[2] https://criu.org/Restorer_context
[3] https://lkml.org/lkml/2016/5/17/243
[4] https://lkml.org/lkml/2016/4/25/650

Dmitry Safonov (6):
  x86/vdso: unmap vdso blob on vvar mapping failure
  x86/vdso: introduce do_map_vdso() and vdso_type enum
  x86/arch_prctl/vdso: add ARCH_MAP_VDSO_*
  x86/coredump: use core regs, rather that TIF_IA32 flag
  x86/ptrace: down with test_thread_flag(TIF_IA32)
  x86/signal: add SA_{X32,IA32}_ABI sa_flags

 arch/x86/entry/vdso/vma.c          | 72 +++++++++++++++++++++-----------------
 arch/x86/ia32/ia32_signal.c        |  2 +-
 arch/x86/include/asm/compat.h      |  8 ++---
 arch/x86/include/asm/fpu/signal.h  |  6 ++++
 arch/x86/include/asm/vdso.h        |  4 +++
 arch/x86/include/uapi/asm/prctl.h  |  6 ++++
 arch/x86/include/uapi/asm/signal.h |  6 +++-
 arch/x86/kernel/process_64.c       | 10 ++++++
 arch/x86/kernel/ptrace.c           |  2 +-
 arch/x86/kernel/signal.c           | 19 +++++-----
 arch/x86/kernel/signal_compat.c    | 30 ++++++++++++++--
 fs/binfmt_elf.c                    | 18 +++++-----
 kernel/signal.c                    |  5 +++
 13 files changed, 129 insertions(+), 59 deletions(-)

-- 
2.8.2

[toc] | [next] | [standalone]

#1411211 — [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

As the task isn't executing at the moment of {GET,SET}REGS,
return regset that corresponds to code selector, rather than
value of TIF_IA32 flag.
I.e. if we ptrace i386 elf binary that has just changed it's
code selector to __USER_CS, than GET_REGS will return
full x86_64 register set.

Note, that this will work only if application has changed it's CS.
If the application does 32-bit syscall with __USER_CS, ptrace
will still return 64-bit register set. Which might be still confusing
for tools that expect TS_COMPACT to be exposed [1, 2].

So this this change should make PTRACE_GETREGSET more reliable and
this will be another step to drop TIF_{IA32,X32} flags.

[1]: https://sourceforge.net/p/strace/mailman/message/30471411/
[2]: https://lkml.org/lkml/2012/1/18/320

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
---
 arch/x86/kernel/ptrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 600edd225e81..a2612d06cf4b 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
 const struct user_regset_view *task_user_regset_view(struct task_struct *task)
 {
 #ifdef CONFIG_IA32_EMULATION
-	if (test_tsk_thread_flag(task, TIF_IA32))
+	if (!user_64bit_mode(task_pt_regs(task)))
 #endif
 #if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
 		return &user_x86_32_view;
-- 
2.8.2

[toc] | [prev] | [next] | [standalone]

#1413003 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Wed, Jun 01, 2016 at 04:11:36PM +0300, Dmitry Safonov wrote:
> As the task isn't executing at the moment of {GET,SET}REGS,
> return regset that corresponds to code selector, rather than
> value of TIF_IA32 flag.
> I.e. if we ptrace i386 elf binary that has just changed it's
> code selector to __USER_CS, than GET_REGS will return
> full x86_64 register set.
> 
> Note, that this will work only if application has changed it's CS.
> If the application does 32-bit syscall with __USER_CS, ptrace
> will still return 64-bit register set. Which might be still confusing
> for tools that expect TS_COMPACT to be exposed [1, 2].
> 
> So this this change should make PTRACE_GETREGSET more reliable and
> this will be another step to drop TIF_{IA32,X32} flags.
> 
> [1]: https://sourceforge.net/p/strace/mailman/message/30471411/
> [2]: https://lkml.org/lkml/2012/1/18/320
> 
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>

Looks reasonable! Still if cs has been changed to non-compat
selector and we now return 64bit registers set, won't it
cause problems for old tools? I suspect it should not but
still.

[toc] | [prev] | [next] | [standalone]

#1413045 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Fri, Jun 03, 2016 at 01:27:33PM +0300, Dmitry Safonov wrote:
> > 
> > Looks reasonable! Still if cs has been changed to non-compat
> > selector and we now return 64bit registers set, won't it
> > cause problems for old tools? I suspect it should not but
> > still.
> > 
> 
> Thanks! Hmm, strace works fine - I'll check gdb to be sure.
> What else could be bothered by this?

None I know of at the moment.

[toc] | [prev] | [next] | [standalone]

#1415519 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 06/01, Dmitry Safonov wrote:
>
> Note, that this will work only if application has changed it's CS.

So, suppose it changes it's CS and crashes,

> If the application does 32-bit syscall with __USER_CS, ptrace
> @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
>  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
>  {
>  #ifdef CONFIG_IA32_EMULATION
> -	if (test_tsk_thread_flag(task, TIF_IA32))
> +	if (!user_64bit_mode(task_pt_regs(task)))
>  #endif

then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
instead of EM_386, or vice versa...

I simply can't understand is this better or worse, I guess gdb or any
other tool which looks at this coredump will be confused anyway.

Oleg.

[toc] | [prev] | [next] | [standalone]

#1416053 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 06/07/2016 12:19 AM, Oleg Nesterov wrote:
> On 06/01, Dmitry Safonov wrote:
>>
>> Note, that this will work only if application has changed it's CS.
>
> So, suppose it changes it's CS and crashes,
>
>> If the application does 32-bit syscall with __USER_CS, ptrace
>> @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
>>  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
>>  {
>>  #ifdef CONFIG_IA32_EMULATION
>> -	if (test_tsk_thread_flag(task, TIF_IA32))
>> +	if (!user_64bit_mode(task_pt_regs(task)))
>>  #endif
>
> then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
> instead of EM_386, or vice versa...
>
> I simply can't understand is this better or worse, I guess gdb or any
> other tool which looks at this coredump will be confused anyway.

Oleg, thanks for your reply!

At least, gdb will have all registers at that moment.
Firstly, I did it for returning with GET_REGSET corresponding
register set. So ptrace-attaching to a task with 64-bit code
selector would return 64-bit register set and contrariwise.
(as task may use all 64-bit registers, that seems logical
for me even if it has been loaded as 32-bit ELF)

And for coredump -- I guess it will show full register set
on the crash moment and show proper disasm around that place.
And for my purpose -- that's really what I need, to generate
32-bit ELF core file on crash after changing CS.

I did it for C/R of 32-bit application with changing code
selector from 64-bit. So last thing restorer does - unmap
itself (it's pie blob) and sigreturn to application.
So if the application crashes after it - it will be good
to have 32-bit coredump as for the original application.

Thanks,
Dmitry Safonov

[toc] | [prev] | [next] | [standalone]

#1418521 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Jun 6, 2016 3:21 PM, "Oleg Nesterov" <oleg@redhat.com> wrote:
>
> On 06/01, Dmitry Safonov wrote:
> >
> > Note, that this will work only if application has changed it's CS.
>
> So, suppose it changes it's CS and crashes,
>
> > If the application does 32-bit syscall with __USER_CS, ptrace
> > @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
> >  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
> >  {
> >  #ifdef CONFIG_IA32_EMULATION
> > -     if (test_tsk_thread_flag(task, TIF_IA32))
> > +     if (!user_64bit_mode(task_pt_regs(task)))
> >  #endif
>
> then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
> instead of EM_386, or vice versa...
>
> I simply can't understand is this better or worse, I guess gdb or any
> other tool which looks at this coredump will be confused anyway.
>

I think it's better. CRIU will change CS and someone will make the
restored process crash afterwards.

> Oleg.
>

[toc] | [prev] | [next] | [standalone]

#1419702 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 06/09, Andy Lutomirski wrote:
>
> On Jun 6, 2016 3:21 PM, "Oleg Nesterov" <oleg@redhat.com> wrote:
> >
> > On 06/01, Dmitry Safonov wrote:
> > >
> > > Note, that this will work only if application has changed it's CS.
> >
> > So, suppose it changes it's CS and crashes,
> >
> > > If the application does 32-bit syscall with __USER_CS, ptrace
> > > @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
> > >  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
> > >  {
> > >  #ifdef CONFIG_IA32_EMULATION
> > > -     if (test_tsk_thread_flag(task, TIF_IA32))
> > > +     if (!user_64bit_mode(task_pt_regs(task)))
> > >  #endif
> >
> > then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
> > instead of EM_386, or vice versa...
> >
> > I simply can't understand is this better or worse, I guess gdb or any
> > other tool which looks at this coredump will be confused anyway.
> >
>
> I think it's better.

and I tend to agree, I didn't try to argue with this change, but

> CRIU will change CS and someone will make the
> restored process crash afterwards.

I don't understand what do you mean... could you explain?

IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true?

Oleg.

[toc] | [prev] | [next] | [standalone]

#1419705 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Fri, Jun 10, 2016 at 1:07 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 06/09, Andy Lutomirski wrote:
>>
>> On Jun 6, 2016 3:21 PM, "Oleg Nesterov" <oleg@redhat.com> wrote:
>> >
>> > On 06/01, Dmitry Safonov wrote:
>> > >
>> > > Note, that this will work only if application has changed it's CS.
>> >
>> > So, suppose it changes it's CS and crashes,
>> >
>> > > If the application does 32-bit syscall with __USER_CS, ptrace
>> > > @@ -1355,7 +1355,7 @@ void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
>> > >  const struct user_regset_view *task_user_regset_view(struct task_struct *task)
>> > >  {
>> > >  #ifdef CONFIG_IA32_EMULATION
>> > > -     if (test_tsk_thread_flag(task, TIF_IA32))
>> > > +     if (!user_64bit_mode(task_pt_regs(task)))
>> > >  #endif
>> >
>> > then coredump will do fill_elf_header(view->e_machine) and use EM_X86_64
>> > instead of EM_386, or vice versa...
>> >
>> > I simply can't understand is this better or worse, I guess gdb or any
>> > other tool which looks at this coredump will be confused anyway.
>> >
>>
>> I think it's better.
>
> and I tend to agree, I didn't try to argue with this change, but
>
>> CRIU will change CS and someone will make the
>> restored process crash afterwards.
>
> I don't understand what do you mean... could you explain?
>
> IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true?
>

CRIU has a horrible, nasty, brilliant idea: it will start restoring
32-bit processes by treating them mostly like 64-bit processes.  The
restorer will start out 64-bit, set everything up, and long
jump/return/sigreturn/whatever back to 32-bit mode.  My proposal was
that, rather than coming up with nasty hacks to switch the kernel's
idea of the task bitness, we instead teach the kernel to respect that
actual bitness as indicated by CS and the syscalls used to the extent
possible.

So, yes, a restored 32-bit process that crashes should dump core as
though it's 32-bit even though it was 64-bit when execve was last
called :)

--Andy

[toc] | [prev] | [next] | [standalone]

#1420871 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

To avoid the confusion, let me first say that I am not going to argue
with these changes, I simply do not understand the problem space enough.

On 06/10, Andy Lutomirski wrote:
>
> On Fri, Jun 10, 2016 at 1:07 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true?
> >
>
> CRIU has a horrible, nasty, brilliant idea: it will start restoring
> 32-bit processes by treating them mostly like 64-bit processes.  The
> restorer will start out 64-bit, set everything up, and long
> jump/return/sigreturn/whatever back to 32-bit mode.

OK, I see,

> My proposal was
> that, rather than coming up with nasty hacks to switch the kernel's
> idea of the task bitness,

Well, I can't resist but to me SA_IA32_ABI/SA_X32_ABI looks like a hack
too.  We actually shift TIF_*32 into k_sigaction->flags, and the fact
that we do this per-signal looks, well, interesting ;)

And at first glance it would be very simple to change the task bitness,
CRIU can simply exec a dummy 32-bit application before anything else.
In this case (I think) we also do not need do_map_vdso/ARCH_MAP_VDSO_*
at least right now.

Yes, I guess this will complicate CRIU significantly.

> we instead teach the kernel to respect that
> actual bitness as indicated by CS and the syscalls used to the extent
> possible.

I am still not sure the idea to remove TIF_IA32/TIF_X32 is really good.
But again, I won't argue, I do not feel I understand pro/cons enough.

> So, yes, a restored 32-bit process that crashes should dump core as
> though it's 32-bit even though it was 64-bit when execve was last
> called :)

OK, thanks for you explanation Andy.

Oleg.

[toc] | [prev] | [next] | [standalone]

#1421298 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On Mon, Jun 13, 2016 at 6:50 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> To avoid the confusion, let me first say that I am not going to argue
> with these changes, I simply do not understand the problem space enough.
>
> On 06/10, Andy Lutomirski wrote:
>>
>> On Fri, Jun 10, 2016 at 1:07 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>> >
>> > IIRC, CRIU can't c/r the 32-bit applications, or this is no longer true?
>> >
>>
>> CRIU has a horrible, nasty, brilliant idea: it will start restoring
>> 32-bit processes by treating them mostly like 64-bit processes.  The
>> restorer will start out 64-bit, set everything up, and long
>> jump/return/sigreturn/whatever back to 32-bit mode.
>
> OK, I see,
>
>> My proposal was
>> that, rather than coming up with nasty hacks to switch the kernel's
>> idea of the task bitness,
>
> Well, I can't resist but to me SA_IA32_ABI/SA_X32_ABI looks like a hack
> too.  We actually shift TIF_*32 into k_sigaction->flags, and the fact
> that we do this per-signal looks, well, interesting ;)

Is anything actually wrong with this, though?

[toc] | [prev] | [next] | [standalone]

#1421960 — Re: [PATCH 5/6] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 06/13, Andy Lutomirski wrote:
>
> On Mon, Jun 13, 2016 at 6:50 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > Well, I can't resist but to me SA_IA32_ABI/SA_X32_ABI looks like a hack
> > too.  We actually shift TIF_*32 into k_sigaction->flags, and the fact
> > that we do this per-signal looks, well, interesting ;)
>
> Is anything actually wrong with this, though?

No, I think the patch is correct... It adds the user-visible change, but
I do not think it can break something.

Well, perhaps we should also remove SA_IA32_ABI|SA_X32_ABI from
oact->sa.sa_flags in do_sigaction() to ensure that these non-uapi flags won't
leak to user-space, but probably we do not really care.

Oleg.

[toc] | [prev] | [next] | [standalone]

#1411212 — [PATCH 1/6] x86/vdso: unmap vdso blob on vvar mapping failure

If remapping of vDSO blob failed on vvar mapping,
we need to unmap previously mapped vDSO blob.

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
---
 arch/x86/entry/vdso/vma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 3329844e3c43..387028e6755d 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -238,7 +238,7 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr)
 
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
-		goto up_fail;
+		do_munmap(mm, text_start, image->size);
 	}
 
 up_fail:
-- 
2.8.2

[toc] | [prev] | [next] | [standalone]

#1411214 — [PATCH 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_*

Add API to change vdso blob type with arch_prctl.
As this is useful yet only by needs of CRIU, expose
this interface under CONFIG_CHECKPOINT_RESTORE.

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
---
 arch/x86/include/uapi/asm/prctl.h |  6 ++++++
 arch/x86/kernel/process_64.c      | 10 ++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/x86/include/uapi/asm/prctl.h b/arch/x86/include/uapi/asm/prctl.h
index 3ac5032fae09..ae135de547f5 100644
--- a/arch/x86/include/uapi/asm/prctl.h
+++ b/arch/x86/include/uapi/asm/prctl.h
@@ -6,4 +6,10 @@
 #define ARCH_GET_FS 0x1003
 #define ARCH_GET_GS 0x1004
 
+#ifdef CONFIG_CHECKPOINT_RESTORE
+# define ARCH_MAP_VDSO_X32	0x2001
+# define ARCH_MAP_VDSO_32	0x2002
+# define ARCH_MAP_VDSO_64	0x2003
+#endif
+
 #endif /* _ASM_X86_PRCTL_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 6e789ca1f841..64459c88b3d9 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -49,6 +49,7 @@
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
 #include <asm/xen/hypervisor.h>
+#include <asm/vdso.h>
 
 asmlinkage extern void ret_from_fork(void);
 
@@ -577,6 +578,15 @@ long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
 		break;
 	}
 
+#ifdef CONFIG_CHECKPOINT_RESTORE
+	case ARCH_MAP_VDSO_X32:
+		return do_map_vdso(VDSO_X32, addr, false);
+	case ARCH_MAP_VDSO_32:
+		return do_map_vdso(VDSO_32, addr, false);
+	case ARCH_MAP_VDSO_64:
+		return do_map_vdso(VDSO_64, addr, false);
+#endif
+
 	default:
 		ret = -EINVAL;
 		break;
-- 
2.8.2

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web