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 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.