All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: FTRACE_WARN_ON((rec->flags & ~FTRACE_FL_MASK) == 0))
Date: Wed, 28 Aug 2013 12:23:21 -0400	[thread overview]
Message-ID: <20130828162321.GA14689@redhat.com> (raw)
In-Reply-To: <20130828103101.3f5679bc@gandalf.local.home>

On Wed, Aug 28, 2013 at 10:31:01AM -0400, Steven Rostedt wrote:
 > Dave,
 > 
 > BTW, is there a way to run trinity on a subset of syscalls. Basically,
 > I would like to run it on just the perf code, and nothing else. I have
 > a feeling that the bug you see is not caused by other operations
 > happening (although it could be), but from just out of order perf
 > calls. If I can reproduce it, I'll have a much better way of debugging
 > this.
 
indeed. -c perf_open_event for eg. (You can also specify multiple -c's
if you want to thow in some others)

There's a few other options in there for narrowing things down.
Say you think it's an interaction between perf and and unknown other syscall
for eg, you can do -c perf_open_event -r5. This will pick 5 random
syscalls, and fuzz those plus perf. See scripts/find.sh for an example of
how I've used this in the past.

 > Perhaps another thing you may think of adding to trinity (if it doesn't
 > already exist), is a log of what it is doing. That is, to log somewhere
 > the commands it writes, and that way, if something goes wrong, you have
 > a clue to how it got there. Because this is one of those bugs that
 > triggered before the code crashes, and the crash is just the symptom of
 > what went wrong and does not give you much clue to how it happened.
 
It does have logging already, though for a bug that takes hours, or days to
hit, they can grow to unmanagable sizes, and there's a problem if we have
a situation like..

syscall A
<24 hours of boring syscalls>
syscall B
oops as a result of B's interaction with A.

Quite often just rerunning that last syscall that caused the oops/warn
isn't sufficient to trigger an issue. (Though it may be for this specific
bug that may not be the case..)

Vince has a variant of trinity focussed just on perf which also has some
neat replay/bisecting capabilities to narrow down test cases.
I think I might need to add something like that at some point.

	Dave


  reply	other threads:[~2013-08-28 16:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28  3:46 FTRACE_WARN_ON((rec->flags & ~FTRACE_FL_MASK) == 0)) Dave Jones
2013-08-28 13:54 ` Steven Rostedt
2013-08-28 13:58   ` Steven Rostedt
2013-08-28 15:17     ` Steven Rostedt
2013-08-28 18:27       ` Dave Jones
2013-08-28 18:29         ` Dave Jones
2013-08-28 19:27           ` Steven Rostedt
2013-09-30 17:12             ` Dave Jones
2013-10-01  3:56               ` Steven Rostedt
2013-10-01  4:20                 ` Dave Jones
2013-10-01 12:28                   ` Steven Rostedt
2013-10-02 14:16                     ` Dave Jones
2013-10-02 16:43                       ` Steven Rostedt
2013-10-02 16:53                         ` Dave Jones
2013-08-28 14:31 ` Steven Rostedt
2013-08-28 16:23   ` Dave Jones [this message]
2013-08-28 16:50     ` Vince Weaver
2013-08-28 16:57       ` Steven Rostedt
2013-08-28 17:33         ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2014-01-30  4:16 Dave Jones
2014-01-30  4:50 ` Steven Rostedt
2014-01-30  5:32   ` Dave Jones
2014-01-30 13:55     ` 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=20130828162321.GA14689@redhat.com \
    --to=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.