All of lore.kernel.org
 help / color / mirror / Atom feed
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/2] [GIT PULL] tracing: A couple of fixes
Date: Tue, 28 May 2013 11:15:57 -0400	[thread overview]
Message-ID: <20130528151557.743203087@goodmis.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]


Linus,

Two more fixes:

The first one was reported by Mauro Carvalho Chehab, where if a poll()
is done against a trace buffer for a CPU that has never been online,
it will crash the kernel, as buffers are only created when a CPU comes
on line, but the trace files are for all possible CPUs.

This fix is to check if the buffer was allocated and if not return -EINVAL.

That was the simple fix, the real fix is a bit more complex and not for
a -rc release. We could have the files created when the CPUs come online.
That would require some design changes.

The second one was reported by Peter Zijlstra. If the kernel command line
has ftrace=nop, it will lock up the system on boot up. This is because
the new design for 3.10 has the nop tracer bootstrap the tracing subsystem.
When ftrace=<trace> is defined, when that tracer is registered, it
starts the tracing, but uses the nop tracer to clear things out.
What happened here was that ftrace=nop caused the registering of nop
to start it and use nop before it was initialized.

The only thing nop needs to have done to initialize it is to have the
tracer point its current_tracer structure member to the nop tracer.
Doing that before registering the nop tracer makes everything work.

-- Steve

Please pull the latest trace-fixes-v3.10-rc3 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v3.10-rc3

Tag SHA1: fc1bb352c272393813d3081ba40a2921a519acdb
Head SHA1: 6721cb60022629ae76365551f05d9658b8d14c55


Steven Rostedt (Red Hat) (2):
      tracing: Fix crash when ftrace=nop on the kernel command line
      ring-buffer: Do not poll non allocated cpu buffers

----
 kernel/trace/ring_buffer.c |    3 +++
 kernel/trace/trace.c       |    9 +++++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

             reply	other threads:[~2013-05-28 15:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 15:15 Steven Rostedt [this message]
2013-05-28 15:15 ` [PATCH 1/2] tracing: Fix crash when ftrace=nop on the kernel command line Steven Rostedt
2013-05-28 15:15 ` [PATCH 2/2] ring-buffer: Do not poll non allocated cpu buffers Steven Rostedt
2014-04-17 23:42 [PATCH 0/2] [GIT PULL] tracing: A couple of fixes Steven Rostedt
2016-02-16 19:49 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=20130528151557.743203087@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 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.