(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.sam...@morphisec.com> wrote: > Hi, > Just bumping up this message in case got lost, > > Thanks, > Tomer > > > ________________________________ > From: tomer samara <tomer.sam...@morphisec.com> > Sent: Sunday, November 5, 2023 5:42 PM > To: naveen.n....@linux.ibm.com <naveen.n....@linux.ibm.com>; > anil.s.keshavamur...@intel.com <anil.s.keshavamur...@intel.com>; > da...@davemloft.net <da...@davemloft.net>; mhira...@kernel.org > <mhira...@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) <mhira...@kernel.org>
