From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
To: <wangxiongfeng2@huawei.com>, <huawei.libin@huawei.com>,
<james.morse@arm.com>, <catalin.marinas@arm.com>,
<will.deacon@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: [RFC PATCH 0/3] Enable kprobe to monitor sdei event handler
Date: Fri, 12 Apr 2019 20:04:56 +0800 [thread overview]
Message-ID: <1555070699-3685-1-git-send-email-wangxiongfeng2@huawei.com> (raw)
When I use kprobe to monitor a sdei event handler, the CPU will hang. It's
because when I probe the event handler, the instruction will be replaced with
brk instruction and brk exception is unmaskable. But 'vbar_el1' contains
'tramp_vectors' in '_sdei_handler' when SDEI events interrupt userspace, so
we will go to the wrong place if brk exception happens.
I notice that 'ghes_sdei_normal_callback' call several funtions that are not
marked as 'nokprobe'. So I was wondering if we can enable kprobe in '_sdei_handler'.
Xiongfeng Wang (3):
Revert "arm64: debug: remove unused local_dbg_{enable, disable}
macros"
sdei: enable dbg in '_sdei_handler'
stop_machine: mask sdei before running the callback
arch/arm64/include/asm/debug-monitors.h | 1 +
arch/arm64/include/asm/irqflags.h | 4 +++
arch/arm64/kernel/debug-monitors.c | 8 ++++++
arch/arm64/kernel/sdei.c | 43 ++++++++++++++++++++++++++-------
kernel/stop_machine.c | 9 +++++++
5 files changed, 56 insertions(+), 9 deletions(-)
--
1.7.12.4
next reply other threads:[~2019-04-12 12:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-12 12:04 Xiongfeng Wang [this message]
2019-04-12 12:04 ` [RFC PATCH 1/3] Revert "arm64: debug: remove unused local_dbg_{enable, disable} macros" Xiongfeng Wang
2019-04-12 12:04 ` [RFC PATCH 2/3] sdei: enable dbg in '_sdei_handler' Xiongfeng Wang
2019-04-24 16:21 ` James Morse
2019-04-12 12:04 ` [RFC PATCH 3/3] stop_machine: mask sdei before running the callback Xiongfeng Wang
2019-04-24 16:20 ` [RFC PATCH 0/3] Enable kprobe to monitor sdei event handler James Morse
2019-04-26 8:19 ` Xiongfeng Wang
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=1555070699-3685-1-git-send-email-wangxiongfeng2@huawei.com \
--to=wangxiongfeng2@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=huawei.libin@huawei.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will.deacon@arm.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
all inboxes | Powered by JetHome®