From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: WARNING at arch/x86/kernel/alternative.c:707 text_poke+0x25d/0x270
Date: Wed, 17 May 2017 01:27:38 +0900 [thread overview]
Message-ID: <20170517012738.8627bfae95df7c64f08f6d95@kernel.org> (raw)
In-Reply-To: <20170516113019.0bfcd516@gandalf.local.home>
On Tue, 16 May 2017 11:30:19 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 17 May 2017 00:15:39 +0900
> Masami Hiramatsu <mhiramat@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 <mhiramat@kernel.org>
next prev parent reply other threads:[~2017-05-16 16:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-16 13:48 Steven Rostedt
2017-05-16 15:15 ` Masami Hiramatsu
2017-05-16 15:30 ` Steven Rostedt
2017-05-16 16:27 ` Masami Hiramatsu [this message]
2017-05-16 21:42 ` Thomas Gleixner
2017-05-17 1:38 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170517012738.8627bfae95df7c64f08f6d95@kernel.org \
--to=mhiramat@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®