linux-kernel - Re: preempt in kprobe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <54F30392.1040001@hitachi.com>
Date:	Sun, 01 Mar 2015 21:18:26 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	zhaoxiaoqiang007 <zhaoxiaoqiang007@...il.com>
Cc:	rostedt <rostedt@...dmis.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: preempt in kprobe

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@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/