From: Michael Neuling <mikey@neuling.org>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: avagin@openvz.org, roland@redhat.com, oleg@redhat.com,
Linux PPC dev <linuxppc-dev@ozlabs.org>,
linux-kernel@vger.kernel.org
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
WARNING: multiple messages have this Message-ID (diff)
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: 28+ 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 ` 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 ` Anshuman Khandual
2014-04-02 7:02 ` [PATCH 2/3] powerpc, ptrace: Add new ptrace request macros for transactional memory Anshuman Khandual
2014-04-02 7:02 ` Anshuman Khandual
2014-04-25 23:42 ` Pedro Alves
2014-04-25 23:42 ` Pedro Alves
2014-04-28 10:30 ` Anshuman Khandual
2014-04-28 10:30 ` Anshuman Khandual
2014-05-01 13:41 ` Pedro Alves
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 7:02 ` Anshuman Khandual
2014-04-02 9:32 ` [PATCH 0/3] Add new ptrace request macros on PowerPC Anshuman Khandual
2014-04-02 9:32 ` Anshuman Khandual
2014-04-29 7:00 ` 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 7:59 ` Anshuman Khandual
2014-04-29 8:22 ` Michael Neuling
2014-04-29 12:22 ` Anshuman Khandual
2014-04-29 12:22 ` Anshuman Khandual
2014-04-30 0:29 ` Michael Neuling [this message]
2014-04-30 0:29 ` Michael Neuling
2014-04-30 8:16 ` Anshuman Khandual
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 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.