linux-kernel - Re: [RFA][PATCH 00/27] ftrace: Remove ftrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53B0D5C4.8000909@hitachi.com>
Date:	Mon, 30 Jun 2014 12:13:08 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-arch@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Jiri Kosina <jkosina@...e.cz>,
	Josh Poimboeuf <notifications@...hub.com>
Subject: Re: [RFA][PATCH 00/27] ftrace: Remove ftrace_start/stop() and friends

(2014/06/27 1:52), Steven Rostedt wrote:
> * Request for Acks *
> 
>>>From the time I created the use of function_trace_stop, I hated it.
> There was two reasons to create this, one was to try to lower the
> function tracing overhead when debugfs file tracing_enable was set to zero
> (note, tracing_enable no longer exists), the other was a way to stop
> function tracing when going down into suspend and resume.
> 
> Some function was causing suspend and resume to reboot the kernel. In
> debugging this I found that an empty callback from mcount would work.
> That is, instead of running the tracing code, I would just have the
> function trace callback be a nop:
> 
>  void function_trace_call(unsigned long ip, unsigned long parent_ip)
>  {
>  }
> 
> This worked. That means the code in mcount wasn't an issue. I started
> bisecting the contents of the function_trace_call and found that this
> would cause the system to reboot!
> 
>  void function_trace_call(unsigned long ip, unsigned long parent_ip)
>  {
> 	smp_processor_id();
>  }
> 
> That is, just calling smp_processor_id() was enough to trigger a triple
> fault on resume of the system.
> 
> Today, this big hammer approach of disabling the function tracer is starting
> to show its issues. It can't help out in debugging suspend and resume,
> and there's other function trace callbacks that should still work.
> 
> I also have learned ways to bisect functions that cause bugs in function
> tracing. I finally got some time to do so with a box that would reboot
> on suspend and resume. This led me down to a single function:
> 
>  restore_processor_state()
> 
> This made perfect sense, as this function is called from assembly on a
> CPU startup. One of the jobs of this function was to set up the GS register.
> That register is also the register that is used by smp_processor_id()
> to find what CPU the task is running on. With it not set up it will offset
> into some random location and fault. As the fault handlers can also be
> traced, those will fault too and finally the system will reset due to a
> triple fault.

Uh, from the same reason, I must list it in the kprobe blacklist too...

BTW, as far as I can review, x86 and generic parts of the series seems
OK to me. :)

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/