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: [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
