linux-kernel - Re: [PATCH 2/2] x86: Make the x86-64 stacktrace code safely callable from scheduler

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]

Date:	Fri, 13 May 2011 06:48:26 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 2/2] x86: Make the x86-64 stacktrace code safely
 callable from scheduler

On Thu, 2011-05-12 at 22:32 +0200, Frederic Weisbecker wrote:
> Avoid potential scheduler recursion and deadlock from the
> stacktrace code by avoiding rescheduling when we re-enable
> preemption.

I'm curious to where you saw this deadlock? As I have the function stack
tracer using preempt_disable_notrace and enable_notrace without any
issues, and it traces all functions in the kernel[*]. I have no issue
with using raw_local_irq_save/restore() if it is to protect the per_cpu
variable from interrupt corruption, but I don't see the problem with
recursion.

There's only one function I had to worry about with preempt disable, not
the entire scheduler. That was the function preempt_schedule(). This
function is called by preempt_enable() and that will cause an infinite
loop if you have something in preempt_schedule() call preempt_enable().

Remember that ftrace_preempt_disable/enable() crap that I did to try to
avoid the scheduler deadlock? I found it was complex and unnecessary
because the scheduler itself was not an issue, it was only
preempt_schedule(). I replaced all that crappy code with a single line
that added notrace to preempt_schedule() and everything just worked.

Thus, if you disable interrupts to protect the cpu data, that's fine,
and say so in the change log. I really like to know if you really saw
this deadlock. Yes enabling preemption in the scheduler may recurse, but
it will only do so once.

I still argue that interrupt enabling is slow. I've seen a large slow
down of the code by switching stack tracer from preempt disable to irq
disable. I used perf to see why, and it told me that disabling
interrupts as fine, but enabling interrupts can cost you quite a bit.

-- Steve

[*] of course function tracing does not trace other notrace functions.

--
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/