On Tue, 16 May 2017 11:30:19 -0400 Steven Rostedt <rost...@goodmis.org> wrote:
> On Wed, 17 May 2017 00:15:39 +0900 > Masami Hiramatsu <mhira...@kernel.org> wrote: > > > > > It appears that the kprobe_optimizer work thread call happened after > > > the init pages were freed, causing alternative.c to give the above > > > warning because the text that is being unoptimized happens to no longer > > > exist. > > > > Ah, I see. I need to check that case. Actually for the module > > init text area, kill_kprobe() correctly kicks kill_optimized_kprobe() > > so it should safe. But above case is on the init-text in kernel > > itself. I guess module_notifier may not be called for that area... > > Hmm, what happens if you add a kprobe to a module, remove it, and then > remove the module. In that case the kprobe will be removed before unloading the module. If the kprobe is optimized, the optimized probe itself is queued to unoptimize. > If the module is still loaded when it is removed, > wouldn't that cause the optimized probe to be delayed? Yes, it is queued, but before unloading module, it should be dequeued forcibly by kill_optimized_kprobe() from module-notifier. > Wouldn't that > open a race where the optimizer work queue can be called when no module > exists? Since both kprobe_mutex and module_mutex are held in optimizer, I couldn't think there is such race. I guess when the kernel's init-text (not module's one) is freed, it doesn't kick the module notifier and kprobes missed that. Thank you, -- Masami Hiramatsu <mhira...@kernel.org>
