From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: zhaoxiaoqiang007 <zhaoxiaoqiang007@gmail.com>
Cc: rostedt <rostedt@goodmis.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>
Subject: Re: preempt in kprobe
Date: Sun, 01 Mar 2015 21:18:26 +0900 [thread overview]
Message-ID: <54F30392.1040001@hitachi.com> (raw)
In-Reply-To: <566FD7EB-2F00-402D-94F0-123E35F81706@gmail.com>
Hi,
(2015/03/01 20:27), zhaoxiaoqiang007 wrote:
>
> Hi, masami:
> I have read your post at https://lkml.org/lkml/2011/7/1/185 which remove the
> preempt disable code in kprobe.
Right, but it is only for x86 since the kprobe int3 handler runs in irq-disabled
context, which completely disables preemption. So, in this case it just redundant.
(BTW, it seems that the above patch was finally dropped (just not applied yet)...)
> Does it safe on arm(32) ? In my scenario I (have to) write some sleep code which
> may cause reschedule in the probe handler.
No, as I've said, sleep or yield to other process in the kprobe handler doesn't
allowed.
> Then I got schedule bug report like
> below:
> <4>[ 369.000535] [<c0110e54>] (unwind_backtrace+0x0/0x158) from [<c0ad9724>]
> (dump_stack+0x20/0x24)
> <4>[ 369.000609] [<c0ad9724>] (dump_stack+0x20/0x24) from [<c0ada664>]
> (__schedule_bug+0x58/0x64)
> <4>[ 369.000654] [<c0ada664>] (__schedule_bug+0x58/0x64) from [<c0aec4e0>]
> (__schedule+0x764/0x8e0)
> <4>[ 369.000730] [<c0aec4e0>] (__schedule+0x764/0x8e0) from [<c0aec7ac>]
> (schedule+0x40/0x80)
> <4>[ 369.000806] [<c0aec7ac>] (schedule+0x40/0x80) from [<c0ae9bac>]
> (schedule_timeout+0x230/0x3dc)
> <4>[ 369.000884] [<c0ae9bac>] (schedule_timeout+0x230/0x3dc) from [<c0aebbdc>]
> (wait_for_common+0x100/0x184)
> <4>[ 369.000929] [<c0aebbdc>] (wait_for_common+0x100/0x184) from [<c0aebc84>]
> (wait_for_completion+0x24/0x28)
> <4>[ 369.001007] [<c0aebc84>] (wait_for_completion+0x24/0x28) from [<c01c1a14>]
> (call_usermodehelper_exec+0x150/0x168)
> <4>[ 369.001083] [<c01c1a14>] (call_usermodehelper_exec+0x150/0x168) from
> [<bf0005b4>] (log_to_user.constprop.1+0x11c/0x16
>
> The bug was triggered by call_usermodehelper with UMH_WAIT_PROC argument , then
> the schedule function will read the preempt_count. It should be 1, but here it
> is 2.
> Is it legal to sleep in kprobe handler? Is there is way to walkaroud this problem?
No, please read Documentation/kprobes.txt. If you want to call some usermode
process, perhaps, using a workqueue can be a workaround. However, if you call
workqueue from workqueue-related function, that can cause unexpected result.
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next parent reply other threads:[~2015-03-01 12:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <813D1B5D-3D06-4EEF-AA2A-B0B9F8A81154@gmail.com>
[not found] ` <566FD7EB-2F00-402D-94F0-123E35F81706@gmail.com>
2015-03-01 12:18 ` Masami Hiramatsu [this message]
[not found] ` <13900FF3-780D-4AAF-BF92-3637F7FB8934@gmail.com>
[not found] ` <4EC4716B-53DA-4D32-8D64-F08C4CE536AA@gmail.com>
2015-03-02 1:44 ` preempt in kprobe gmail
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=54F30392.1040001@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=yrl.pp-manager.tt@hitachi.com \
--cc=zhaoxiaoqiang007@gmail.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