From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752128AbbCAMSd (ORCPT ); Sun, 1 Mar 2015 07:18:33 -0500 Received: from mail9.hitachi.co.jp ([133.145.228.44]:52700 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751034AbbCAMSc (ORCPT ); Sun, 1 Mar 2015 07:18:32 -0500 Message-ID: <54F30392.1040001@hitachi.com> Date: Sun, 01 Mar 2015 21:18:26 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: zhaoxiaoqiang007 Cc: rostedt , linux-kernel , "yrl.pp-manager.tt@hitachi.com" Subject: Re: preempt in kprobe References: <813D1B5D-3D06-4EEF-AA2A-B0B9F8A81154@gmail.com> <566FD7EB-2F00-402D-94F0-123E35F81706@gmail.com> In-Reply-To: <566FD7EB-2F00-402D-94F0-123E35F81706@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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] [] (unwind_backtrace+0x0/0x158) from [] > (dump_stack+0x20/0x24) > <4>[ 369.000609] [] (dump_stack+0x20/0x24) from [] > (__schedule_bug+0x58/0x64) > <4>[ 369.000654] [] (__schedule_bug+0x58/0x64) from [] > (__schedule+0x764/0x8e0) > <4>[ 369.000730] [] (__schedule+0x764/0x8e0) from [] > (schedule+0x40/0x80) > <4>[ 369.000806] [] (schedule+0x40/0x80) from [] > (schedule_timeout+0x230/0x3dc) > <4>[ 369.000884] [] (schedule_timeout+0x230/0x3dc) from [] > (wait_for_common+0x100/0x184) > <4>[ 369.000929] [] (wait_for_common+0x100/0x184) from [] > (wait_for_completion+0x24/0x28) > <4>[ 369.001007] [] (wait_for_completion+0x24/0x28) from [] > (call_usermodehelper_exec+0x150/0x168) > <4>[ 369.001083] [] (call_usermodehelper_exec+0x150/0x168) from > [] (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