All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Laurent Dufour <ldufour@linux.vnet.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Simon Guo <wei.guo.simon@gmail.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Paul Mackerras <paulus@samba.org>,
	Kees Cook <keescook@chromium.org>,
	Rashmica Gupta <rashmicy@gmail.com>
Subject: Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space
Date: Thu, 07 Jul 2016 23:21:18 +1000	[thread overview]
Message-ID: <1467897678.27157.45.camel@kernel.crashing.org> (raw)
In-Reply-To: <577E5534.70300@linux.vnet.ibm.com>

On Thu, 2016-07-07 at 15:12 +0200, Laurent Dufour wrote:
> 
> Basically, CRIU checkpoints the process register's state through the
> ptrace API, and it restores it through a signal frame at restart time.
> This is quite odd but that the way it works on all the CRIU's supported
> architectures.
> 
> Obviously everything is done from/in user space, so the sigframe
> building too.
> Since we can't know from user space if the thread has used or not the
> Altivec/VSX registers, since we can't rely on the MSR bits, we always
> dump these registers.

Right, however is that an issue ? These days with glibc using V{M,S}X
for things like memcpy I would think there is little to gain in trying
to avoid dumping them.

> > Alternately, when restoring, can you setup the sigframe with the Altivec/VSX
> > fields populated, and the kernel will then load them, regardless of whether
> > they were actually used or not prior to the checkpoint?
> 
> In the case of Altivec/VSX fields, we currently force the kernel to
> retrieve them from the signal frame by setting MSR_VEC/MSR_VSX so
> restore_sigcontext() will copy them to the kernel thread's state.

Yup, that's the way to go.

> However this doesn't touch to used_vsr and used_vr which may remain at 0.

That would be a kernel bug.

> Most of the time this is fine, but in the case a thread which has really
> used those registers is catching a signal just after the restore and
> before it has touched to these registers again (and so set used_vsr/vr),
> these registers will not be pushed in the newly built signal frame since
> setup_sigcontext() check for used_vsr/vr before pushing the registers on
> the stack.
> This may be an issue in the case the thread wants to changed those
> registers (don't ask me why :)) in the stacked signal frame from the
> signal handler since they will not be there...
> 
> Being able to get and set the used_vr and used_vsr thread's variables,
> fixes this issue.

I think the right fix is that if a restore_sigcontext() has the MSR bits set,
it should set the corresponding used_* flag.

Or is there a reason why that won't work ?

Cheers,
Ben.

> Cheers,
> Laurent.
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

  reply	other threads:[~2016-07-07 13:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07  7:49 [PATCH v4] powerpc: Export thread_struct.used_vr/used_vsr to user space wei.guo.simon
2016-07-07 11:15 ` [v4] " Michael Ellerman
2016-07-07 13:12   ` Laurent Dufour
2016-07-07 13:21     ` Benjamin Herrenschmidt [this message]
2016-07-07 13:29       ` Benjamin Herrenschmidt
2016-07-08 10:02         ` Michael Ellerman
     [not found]         ` <577f7a45.568f6b0a.bd0eb.4aa8SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-11 17:39           ` Simon Guo
2016-07-15  7:15           ` Simon Guo
2016-07-21 10:57             ` Michael Ellerman
     [not found]             ` <5790aa9c.05296b0a.adf58.5901SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-25  8:52               ` Simon Guo
2016-07-07 13:40       ` Laurent Dufour
2016-07-08  8:26         ` Michael Ellerman
2016-07-08  5:39       ` Simon Guo

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=1467897678.27157.45.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=keescook@chromium.org \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=rashmicy@gmail.com \
    --cc=wei.guo.simon@gmail.com \
    /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.