From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 0/3] [GIT PULL] tracing: some more fixes before my 4.2 pull request
Date: Fri, 26 Jun 2015 11:00:24 -0400 [thread overview]
Message-ID: <20150626150024.270253464@goodmis.org> (raw)
Linus,
This isn't my 4.2 pull request (yet). I found a few more bugs that
I would have sent to fix 4.1, but since 4.1 is already out, I'm
sending this before sending my 4.2 request (which is ready to go).
After fixing the previous filter issue reported by Vince Weaver,
I could not come up with a situation where the operand counter (cnt)
could go below zero, so I added a WARN_ON_ONCE(cnt < 0). Vince was
able to trigger that warn on with his fuzzer test, but didn't have
a filter input that caused it.
Later, Sasha Levin was able to trigger that same warning, and was
able to give me the filter string that triggered it. It was simply
a single operation ">".
I wrapped the filtering code in a userspace program such that I could
single step through the logic. With a single operator the operand
counter can legitimately go below zero, and should be reported to the
user as an error, but should not produce a kernel warning. The
WARN_ON_ONCE(cnt < 0) should be just a "if (cnt < 0) break;" and the
code following it will produce the error message for the user.
While debugging this, I found that there was another bug that let
the pointer to the filter string go beyond the filter string.
This too was fixed.
Finally, there was a typo in a stub function that only gets compiled
if trace events is disabled but tracing is enabled (I'm not even sure
that's possible).
Please pull the latest trace-fixes-4.1 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-4.1
Tag SHA1: 518521eb203ca82fce34c3e496c2d31af30e1ef4
Head SHA1: cc9e4bde03f2b4cfba52406c021364cbd2a4a0f3
Steven Rostedt (Red Hat) (3):
tracing/filter: Do not WARN on operand count going below zero
tracing/filter: Do not allow infix to exceed end of string
tracing: Fix typo from "static inlin" to "static inline"
----
kernel/trace/trace.h | 2 +-
kernel/trace/trace_events_filter.c | 10 +++++++++-
2 files changed, 10 insertions(+), 2 deletions(-)
next reply other threads:[~2015-06-26 15:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 15:00 Steven Rostedt [this message]
2015-06-26 15:00 ` [PATCH 1/3] tracing/filter: Do not WARN on operand count going below zero Steven Rostedt
2015-06-26 15:00 ` [PATCH 2/3] tracing/filter: Do not allow infix to exceed end of string Steven Rostedt
2015-06-26 15:00 ` [PATCH 3/3] tracing: Fix typo from "static inlin" to "static inline" Steven Rostedt
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=20150626150024.270253464@goodmis.org \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox