From: Zhaolei <zhaolei@cn.fujitsu.com>
To: "Steven Rostedt ;" <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] ftrace: Using FTRACE_WARN_ON() to check "freed record" in ftrace_release()
Date: Wed, 25 Mar 2009 12:06:05 +0800 [thread overview]
Message-ID: <49C9ADAD.7070303@cn.fujitsu.com> (raw)
* From Steven Rostedt <rostedt@goodmis.org>
> > Hmm, could you explain this more. I'm thinking that this scenario should
> > not happen, and if it does, it should probably be a bug.
> >
> > Because when we call ftrace_free_rec we change the rec->ip to point to the
> > next record in the chain. Something is very wrong if rec->ip >= s &&
> > rec->ip < e and the record is already free.
> Hello, Steven
>
> Thanks for your comment.
> I got your meaning, and I agree that if rec->ip >= s && rec->ip < e,
> this record is not freed.
> But IMHO, "if rec->ip >= s && rec->ip < e" is used to select records in the
> module,
> and function of ignore "freed record" is only its side-effect.
> So, add a special judgement to avoid "freed record" is not a bad idea.
> And I also agree your suggestion of add a WARN_ON, because this should not
> happened.
Hi Zhaolei,
Great! Feel free to send another patch ;-)
Note, use FTRACE_WARN_ON() macro. This way it shuts down ftrace if it is hit and
helps to avoid further damage later.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
---
kernel/trace/ftrace.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 7b8722b..1752a63 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -358,9 +358,14 @@ void ftrace_release(void *start, unsigned long size)
mutex_lock(&ftrace_lock);
do_for_each_ftrace_rec(pg, rec) {
- if ((rec->ip >= s) && (rec->ip < e) &&
- !(rec->flags & FTRACE_FL_FREE))
+ if ((rec->ip >= s) && (rec->ip < e)) {
+ /*
+ * rec->ip is changed in ftrace_free_rec()
+ * It should not between s and e if record was freed.
+ */
+ FTRACE_WARN_ON(rec->flags & FTRACE_FL_FREE);
ftrace_free_rec(rec);
+ }
} while_for_each_ftrace_rec();
mutex_unlock(&ftrace_lock);
}
--
1.5.5.3
reply other threads:[~2009-03-25 4:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=49C9ADAD.7070303@cn.fujitsu.com \
--to=zhaolei@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.