From: Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>
To: linux-ia64@vger.kernel.org
Subject: [PATCH] Remove getting break_num by decoding instruction
Date: Tue, 22 Nov 2005 22:15:49 +0000 [thread overview]
Message-ID: <20051122141549.A16679@unix-os.sc.intel.com> (raw)
break.b always sets cr.iim to 0 and the current code tries to
get the break_num by decoding instruction. However, their
seems to be a race condition while reading the regs->cr_iip,
as on other cpu the break.b at regs->cr_iip might have been
replaced with the original instruction as a result of
unregister_kprobe() and hence decoding instruction to
obtain break_num will result in wrong value in this case.
Also includes changes to kprobes.c which now has to handle
break number zero.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
--------------------------------------------------------------------
arch/ia64/kernel/kprobes.c | 2 +-
arch/ia64/kernel/traps.c | 18 ------------------
2 files changed, 1 insertion(+), 19 deletions(-)
Index: linux-2.6.15-rc1/arch/ia64/kernel/kprobes.c
=================================--- linux-2.6.15-rc1.orig/arch/ia64/kernel/kprobes.c
+++ linux-2.6.15-rc1/arch/ia64/kernel/kprobes.c
@@ -740,7 +740,7 @@ int __kprobes kprobe_exceptions_notify(s
switch(val) {
case DIE_BREAK:
/* err is break number from ia64_bad_break() */
- if (args->err = 0x80200 || args->err = 0x80300)
+ if (args->err = 0x80200 || args->err = 0x80300 || args->err = 0)
if (pre_kprobes_handler(args))
ret = NOTIFY_STOP;
break;
Index: linux-2.6.15-rc1/arch/ia64/kernel/traps.c
=================================--- linux-2.6.15-rc1.orig/arch/ia64/kernel/traps.c
+++ linux-2.6.15-rc1/arch/ia64/kernel/traps.c
@@ -132,24 +132,6 @@ __kprobes ia64_bad_break (unsigned long
siginfo_t siginfo;
int sig, code;
- /* break.b always sets cr.iim to 0, which causes problems for
- * debuggers. Get the real break number from the original instruction,
- * but only for kernel code. User space break.b is left alone, to
- * preserve the existing behaviour. All break codings have the same
- * format, so there is no need to check the slot type.
- */
- if (break_num = 0 && !user_mode(regs)) {
- struct ia64_psr *ipsr = ia64_psr(regs);
- unsigned long *bundle = (unsigned long *)regs->cr_iip;
- unsigned long slot;
- switch (ipsr->ri) {
- case 0: slot = (bundle[0] >> 5); break;
- case 1: slot = (bundle[0] >> 46) | (bundle[1] << 18); break;
- default: slot = (bundle[1] >> 23); break;
- }
- break_num = ((slot >> 36 & 1) << 20) | (slot >> 6 & 0xfffff);
- }
-
/* SIGILL, SIGFPE, SIGSEGV, and SIGBUS want these field initialized: */
siginfo.si_addr = (void __user *) (regs->cr_iip + ia64_psr(regs)->ri);
siginfo.si_imm = break_num;
reply other threads:[~2005-11-22 22:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20051122141549.A16679@unix-os.sc.intel.com \
--to=anil.s.keshavamurthy@intel.com \
--cc=linux-ia64@vger.kernel.org \
/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