From: Paul Mackerras <paulus@samba.org>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: fweisbec@gmail.com, paulmck@linux.vnet.ibm.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/6] powerpc: Exception hooks for context tracking subsystem
Date: Fri, 5 Apr 2013 13:50:25 +1100 [thread overview]
Message-ID: <20130405025025.GB22465@drongo> (raw)
In-Reply-To: <1364551221-23177-3-git-send-email-zhong@linux.vnet.ibm.com>
On Fri, Mar 29, 2013 at 06:00:17PM +0800, Li Zhong wrote:
> This is the exception hooks for context tracking subsystem, including
> data access, program check, single step, instruction breakpoint, machine check,
> alignment, fp unavailable, altivec assist, unknown exception, whose handlers
> might use RCU.
>
> This patch corresponds to
> [PATCH] x86: Exception hooks for userspace RCU extended QS
> commit 6ba3c97a38803883c2eee489505796cb0a727122
>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Is there a reason why you didn't put the exception_exit() call in
ret_from_except_lite in entry_64.S, and the exception_entry() call in
EXCEPTION_PROLOG_COMMON? That would seem to catch all these cases in
a more centralized place.
Also, I notice that with the exception_exit calls where they are, we
can still deliver signals (thus possibly taking a page fault) or call
schedule() for preemption after the exception_exit() call. Is that
OK, or is it a potential problem?
Paul.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mackerras <paulus@samba.org>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
paulmck@linux.vnet.ibm.com, fweisbec@gmail.com,
benh@kernel.crashing.org
Subject: Re: [RFC PATCH v2 2/6] powerpc: Exception hooks for context tracking subsystem
Date: Fri, 5 Apr 2013 13:50:25 +1100 [thread overview]
Message-ID: <20130405025025.GB22465@drongo> (raw)
In-Reply-To: <1364551221-23177-3-git-send-email-zhong@linux.vnet.ibm.com>
On Fri, Mar 29, 2013 at 06:00:17PM +0800, Li Zhong wrote:
> This is the exception hooks for context tracking subsystem, including
> data access, program check, single step, instruction breakpoint, machine check,
> alignment, fp unavailable, altivec assist, unknown exception, whose handlers
> might use RCU.
>
> This patch corresponds to
> [PATCH] x86: Exception hooks for userspace RCU extended QS
> commit 6ba3c97a38803883c2eee489505796cb0a727122
>
> Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Is there a reason why you didn't put the exception_exit() call in
ret_from_except_lite in entry_64.S, and the exception_entry() call in
EXCEPTION_PROLOG_COMMON? That would seem to catch all these cases in
a more centralized place.
Also, I notice that with the exception_exit calls where they are, we
can still deliver signals (thus possibly taking a page fault) or call
schedule() for preemption after the exception_exit() call. Is that
OK, or is it a potential problem?
Paul.
next prev parent reply other threads:[~2013-04-05 2:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-29 10:00 [RFC PATCH v2 0/6] powerpc: Support context tracking for Power pSeries Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-03-29 10:00 ` [RFC PATCH v2 1/6] powerpc: Syscall hooks for context tracking subsystem Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-03-29 10:00 ` [RFC PATCH v2 2/6] powerpc: Exception " Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-04-05 2:50 ` Paul Mackerras [this message]
2013-04-05 2:50 ` Paul Mackerras
2013-04-08 9:03 ` Li Zhong
2013-04-08 9:03 ` Li Zhong
2013-03-29 10:00 ` [RFC PATCH v2 3/6] powerpc: Exit user context on notify resume Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-03-29 10:00 ` [RFC PATCH v2 4/6] powerpc: Use the new schedule_user API on userspace preemption Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-03-29 10:00 ` [RFC PATCH v2 5/6] powerpc: select HAVE_CONTEXT_TRACKING for pSeries Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-03-29 10:00 ` [RFC PATCH v2 6/6] powerpc: Use generic code for exception handling Li Zhong
2013-03-29 10:00 ` Li Zhong
2013-04-10 4:56 ` Michael Ellerman
2013-04-10 4:56 ` Michael Ellerman
2013-04-10 5:32 ` Li Zhong
2013-04-10 5:32 ` Li Zhong
2013-04-10 5:56 ` Li Zhong
2013-04-10 5:56 ` Li Zhong
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=20130405025025.GB22465@drongo \
--to=paulus@samba.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=zhong@linux.vnet.ibm.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.