All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Petr Mladek <pmladek@suse.cz>, "H. Peter Anvin" <hpa@zytor.com>,
	<stable@vger.kernel.org>
Subject: [RFA][PATCH 1/5] ftrace/x86: Run a sync after fixup on failure
Date: Thu, 27 Feb 2014 10:46:17 -0500	[thread overview]
Message-ID: <20140227154922.957070805@goodmis.org> (raw)
In-Reply-To: 20140227154616.703252665@goodmis.org

[-- Attachment #1: 0001-ftrace-x86-Run-a-sync-after-fixup-on-failure.patch --]
[-- Type: text/plain, Size: 2124 bytes --]

[Request for Ack]

From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>

If a failure occurs while enabling a trace, it bails out and will remove
the tracepoints to be back to what the code originally was. But the fix
up had some bugs in it. By injecting a failure in the code, the fix up
ran to completion, but shortly afterward the system rebooted.

There was two bugs here.

The first was that there was no final sync run across the CPUs after the
fix up was done, and before the ftrace int3 handler flag was reset. That
means that other CPUs could still see the breakpoint and trigger on it
long after the flag was cleared, and the int3 handler would think it was
a spurious interrupt. Worse yet, the int3 handler could hit other breakpoints
because the ftrace int3 handler flag would have prevented the int3 handler
from going further.

The second bug was that the removal of the breakpoints required the
"within()" logic updates instead of accessing the ip address directly.

Link: http://lkml.kernel.org/r/1392650573-3390-1-git-send-email-pmladek@suse.cz

Reported-by: Petr Mladek <pmladek@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: stable@vger.kernel.org # 3.5+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 arch/x86/kernel/ftrace.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index e625319..6b566c8 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -455,7 +455,7 @@ static int remove_breakpoint(struct dyn_ftrace *rec)
 	}
 
  update:
-	return probe_kernel_write((void *)ip, &nop[0], 1);
+	return ftrace_write(ip, nop, 1);
 }
 
 static int add_update_code(unsigned long ip, unsigned const char *new)
@@ -634,6 +634,7 @@ void ftrace_replace_code(int enable)
 		rec = ftrace_rec_iter_record(iter);
 		remove_breakpoint(rec);
 	}
+	run_sync();
 }
 
 static int
@@ -664,7 +665,7 @@ ftrace_modify_code(unsigned long ip, unsigned const char *old_code,
 	return ret;
 
  fail_update:
-	probe_kernel_write((void *)ip, &old_code[0], 1);
+	ftrace_write(ip, old_code, 1);
 	goto out;
 }
 
-- 
1.8.5.3



  reply	other threads:[~2014-02-27 15:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 15:46 [RFA][PATCH 0/5] tracing: Ftrace error sync fix and tracepoint warn on failure Steven Rostedt
2014-02-27 15:46 ` Steven Rostedt [this message]
2014-02-27 15:58   ` [RFA][PATCH 1/5] ftrace/x86: Run a sync after fixup " Petr Mládek
2014-02-27 16:02     ` Steven Rostedt
2014-03-03 22:12   ` H. Peter Anvin
2014-03-03 22:18     ` Steven Rostedt
2014-03-03 22:27       ` H. Peter Anvin
2014-03-03 22:31         ` Steven Rostedt
2014-02-27 15:46 ` [RFA][PATCH 2/5] ftrace/x86: One more missing sync after fixup of function modification failure Steven Rostedt
2014-02-27 16:05   ` Steven Rostedt
2014-02-27 16:37   ` Frederic Weisbecker
2014-02-27 17:00     ` Steven Rostedt
2014-02-27 17:19       ` Frederic Weisbecker
2014-02-27 17:35         ` Steven Rostedt
2014-02-27 17:52           ` Frederic Weisbecker
2014-02-27 15:46 ` [RFA][PATCH 3/5] tracing: Do not add event files for modules that fail tracepoints Steven Rostedt
2014-02-27 16:31   ` Mathieu Desnoyers
2014-02-27 15:46 ` [RFA][PATCH 4/5] tracepoint: Do not waste memory on mods with no tracepoints Steven Rostedt
2014-02-27 15:46 ` [RFA][PATCH 5/5] tracepoint: Warn and notify if tracepoints are not loaded due to module taint Steven Rostedt
2014-02-27 16:33   ` Mathieu Desnoyers
2014-02-27 17:06     ` Steven Rostedt
2014-02-27 17:09     ` Steven Rostedt
2014-02-27 17:16       ` Mathieu Desnoyers

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=20140227154922.957070805@goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.cz \
    --cc=stable@vger.kernel.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.