linux-kernel - Re: [PATCH RT 2/2] ftrace: fix elevated preempt

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: <alpine.DEB.1.10.0808190942070.23667@gandalf.stny.rr.com>
Date:	Tue, 19 Aug 2008 09:45:16 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Gregory Haskins <ghaskins@...ell.com>
cc:	Peter Zijlstra <peterz@...radead.org>, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org
Subject: Re: [PATCH RT 2/2] ftrace: fix elevated preempt_count in
 wakeup-tracer


On Tue, 19 Aug 2008, Gregory Haskins wrote:
> > 
> > Is preempt_count > 1 at all times here?
> > 
> > If not, it might drop to 0 and any interrupt might cause preemption -
> > and its not obvious to me that that is actually correct.
> >   
> According to Steve, we are already in an interrupt-disabled section here, but
> I will defer to him.  He suggested I try this over an IRC conversation when I
> noticed a strange wakeup trace, and it seems to have solved the problem.

Exactly.

Peter,

We disable preemption, do a per_cpu check, if we are not nested we grab 
disable interrupts and grab the spin lock.

The issue that Gregory brought up, was that the tracer would always show 
that preemption was disabled, when it really wasn't. It was recording the
preempt disabled that the trace function itself made. The answer was 
simply to do as Greg did, and enable preemption (but interrupts are 
still disabled), call the function tracer, then disable preemption again 
(to match the outside preemption enabling.


> 
> Im really sending this patch more of a reminder to Steve that he was going to
> fix this, rather than to accept my patch as is.  Of course I don't mind if it
> is accepted as is, and I can make the prologue/comments more descriptive if
> necessary.  But if Steve wants to do something like fold this into his ftrace
> series, that is fine too.  I just didn't want it to be forgotten ;)

Greg thanks, otherwise I would have probably forgotten it ;-)

-- Steve


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