From: Michael Neuling <mikey@neuling.org>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Linux PPC dev <linuxppc-dev@ozlabs.org>,
linux-kernel@vger.kernel.org, avagin@openvz.org,
roland@redhat.com, oleg@redhat.com
Subject: Re: [PATCH 0/3] Add new ptrace request macros on PowerPC
Date: Wed, 30 Apr 2014 10:29:05 +1000 [thread overview]
Message-ID: <20730.1398817745@ale.ozlabs.ibm.com> (raw)
In-Reply-To: <535F997B.3000500@linux.vnet.ibm.com>
Anshuman Khandual <khandual@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
next prev parent reply other threads:[~2014-04-30 0:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 7:02 [PATCH 0/3] Add new ptrace request macros on PowerPC Anshuman Khandual
2014-04-02 7:02 ` [PATCH 1/3] elf: Add some new PowerPC specifc note sections Anshuman Khandual
2014-04-02 7:02 ` [PATCH 2/3] powerpc, ptrace: Add new ptrace request macros for transactional memory Anshuman Khandual
2014-04-25 23:42 ` Pedro Alves
2014-04-28 10:30 ` Anshuman Khandual
2014-05-01 13:41 ` Pedro Alves
2014-04-02 7:02 ` [PATCH 3/3] powerpc, ptrace: Add new ptrace request macro for miscellaneous registers Anshuman Khandual
2014-04-02 9:32 ` [PATCH 0/3] Add new ptrace request macros on PowerPC Anshuman Khandual
2014-04-29 7:00 ` Anshuman Khandual
2014-04-29 7:06 ` Michael Neuling
2014-04-29 7:59 ` Anshuman Khandual
2014-04-29 8:22 ` Michael Neuling
2014-04-29 12:22 ` Anshuman Khandual
2014-04-30 0:29 ` Michael Neuling [this message]
2014-04-30 8:16 ` Anshuman Khandual
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=20730.1398817745@ale.ozlabs.ibm.com \
--to=mikey@neuling.org \
--cc=avagin@openvz.org \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=oleg@redhat.com \
--cc=roland@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).