Anshuman Khandual <khand...@linux.vnet.ibm.com> wrote: > On 04/29/2014 01:52 PM, Michael Neuling wrote: > > 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. The PPR is the same, except that the kernel can change it over a syscall. > > 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. > > 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. Mikey _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev