Re: Sleepable kprobes

Re: Sleepable kprobes

[Masami Hiramatsu]

(Cc: linux-trace-kernel@vger.kernel.org)
Hello Tomer,

Sorry, last weeks I was busy for LPC23.

As far as I can see (and IIUC), this hacks the ftrace's fentry to just
call the probe? (BTW, that is very x86 specific feature.)

In that case, unlike the kprobe, it does not probe the function body
thus it is not kprobes, and it can not work with ftrace and fgraph.

Moreover, since the probe is not called from fixed point, the probed
function can be called under non-preemptive section. Thus it is not
generically able to sleep.

If you need to do I/O inside the kernel, you need to do it carefully.
I recommend you to use deferred work (workqueu or different threads)
to do I/O asynchronously. That will be safer and generic way.
And also, new feature needs to co-exist with the feature already
exists in maintenanceable way. I meant using ftrace fentry directly
is not recommended because it breaks ftrace.

Anyway, what you need to do is starting discussion on the mailing list
instead of pushing your change. 'Why' I/O in the probe is needed inside
probe callback, and propose your solution. (My suggestion is above, but
maybe other people have other opinions.)

Thank you,


On Thu, 16 Nov 2023 05:38:57 +0000
tomer samara <tomer.samara@morphisec.com> wrote:

> Hi,
> Just bumping up this message in case got lost,
> 
> Thanks,
> Tomer
> 
> 
> ________________________________
> From: tomer samara <tomer.samara@morphisec.com>
> Sent: Sunday, November 5, 2023 5:42 PM
> To: naveen.n.rao@linux.ibm.com <naveen.n.rao@linux.ibm.com>; anil.s.keshavamurthy@intel.com <anil.s.keshavamurthy@intel.com>; davem@davemloft.net <davem@davemloft.net>; mhiramat@kernel.org <mhiramat@kernel.org>
> Subject: Sleepable kprobes
> 
> Hi,
> 
> My name is Tomer and in the last few weeks I worked on a side project that will create a sleepable kprobes.
> As you know kprobes is using PERCPU variables and can’t schedule or sleep.
> The motivation behind this is to allow the user to preform operation like I/O operations, put the task in sleep so it will be inspected in user-mode with easier tools or just call kmalloc without GFP_NOWAIT.
> 
> The code is very similar to parts kprobe itself since the idea is the same.
> You can see the full code here: https://github.com/Tsn0w/frogprobe
> The core logic is under src/frogprobe.c while other are just helpers.
> If you think this can be a good change to the current kprobe or as a different subsystem, what can I push this? (beside support more archs, support LKM symbols, blacklist symbols, …).
> 
> Thanks for your time and looking forward to your reply,
> Tomer Samara,


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>