On 04/30/2014 05:59 AM, Michael Neuling wrote:

Anshuman Khandual [off-list ref] wrote:

quoted

On 04/29/2014 01:52 PM, Michael Neuling wrote:

quoted

That's not what that patch does. It shouldn't make any user visible changes
to DSCR or PPR.

It may not when it runs uninterrupted but after the tracee process has
stopped, thread.dscr reflects the default DSCR value as mentioned
before. This can be proved by changing the "dscr_default" value in
arch/powerpc/sysfs.c file.

The intention with DSCR is that if the user changes the DSCR, the kernel
should always save/restore it.  If you are seeing something else, then
that is a bug.  Anton has a test case for this here:

  http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c

If that is failing, then there is a bug that we need to fix.

Anton's above DSCR test passed.

The PPR is the same, except that the kernel can change it over a
syscall.

quoted

quoted

Over syscall PPR and DSCR may change.

Sorry, this should be only PPR.  DSCR shouldn't change over a syscall,
at least that's the intention.

quoted

quoted

Depending on your test case, that may
be your problem.

I would guess when the tracee process stops for ptrace analysis, tm_reclaim or
tm_recheckpoint path might be crossed which is causing this dscr_default value
to go into thread_struct.

That shouldn't happen.  If that's happening, it's a bug.

I would believe this is happening. Also after reverting the commit
e9bdc3d6143d1c4b8d8ce5231, thread.dscr reflects the same value as that
of thread.tm_dscr which is the check pointed DSCR register value just
before the transaction started. So even the NIP has moved passed the point
where the user changes DSCR inside the transaction, thread.dscr is unable
to capture that latest value. But thread.dscr must contain the latest user
changed value of DSCR which is definitely not happening here. So there is
a problem we need to fix.