[ktap] Re: [PATCH] FFI support for ktap
- From: Jovi Zhangwei <jovi.zhangwei@xxxxxxxxx>
- To: ktap@xxxxxxxxxxxxx
- Date: Mon, 4 Nov 2013 17:21:50 +0800
On Mon, Nov 4, 2013 at 4:44 PM, Masami Hiramatsu
<masami.hiramatsu@xxxxxxxxx> wrote:
> Hi,
>
> At first, this looks great debugging feature! :)
>
> I just concern about safety, because many kernel functions are not
> safely called from ktapvm context. For example, what happens if
> I call sched() from ktap?
>
> IMHO, this kind of intrusive feature support should be enabled
> by a debug kconfig, like CONFIG_KTAP_FFI which depends on
> CONFIG_KTAP_INTRUSIVE_MODE.
> And also, it looks better to have a knob to enable such kind of intrusive
> mode on sysctl, like /proc/sys/debug/ktap-intrusive-mode which default
> value is 0 (disabled).
> This will allow admins to choose stability or maximum debug-ability on
> their production/developing systems.
>
Thanks, Masami.
FFI is powerful, but with damage sword. :)
I planed to use a command option like "guru mode"(similar with Systemtap)
in ktap, but I also doubt whether the command option really is enough to make
ktap safe, user still can crash the kernel easily on ktap installed system, like
the example you posted, just call the schedule in atomic context.
Maintaining blacklist/whilelist functions for FFI also seems not practicable.
So I agree with you since I have no other idea now, seems we have to disable
it in build stage if user want ktap to be completely safe (like the
safety in Dtrace).
How about Systemtap handle this? just only "guru mode"? allow to call
sleep-able function in atomic context by some trick?
Jovi
Other related posts:
