linux-kernel - Re: [RFC] ftrace / perf 'recursion'

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:	Wed, 17 Aug 2016 10:25:59 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] ftrace / perf 'recursion'

On Wed, 17 Aug 2016 16:06:12 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> > Also, it will prevent any tracing of NMIs that occur in there.  
> 
> It should not, see how I only mark the IRQ bit, not the NMI bit.

Ah, I didn't look deep at what you set there. Maybe that would work.
Still pretty hacky.

> 
> Could be I misunderstand your recursion bits though....

No, I think you are correct.

> 
> > I would really like to keep this fix within perf if possible. If
> > anything, the flag should just tell the perf function handler not to
> > trace, this shouldn't stop all function handlers.  
> 
> Well, my thinking was that there's a reason most of irq_work is already
> notrace. kernel/irq_work.c has CC_FLAGS_FTRACE removed. That seems to
> suggest that tracing irq_work is a problem.

Well, you were the one that added that ;-)

> 
> tracing also seems to use irq_work..

Yep, but it only calls irq_work if there's a reader waiting, and once
it calls it, it wont call it again until the reader wakes up. I have no
issues in tracing that, as it will trace the wake up as well.

Are you calling a signal to userspace via the irq work? Maybe we should
have a kernel thread that does that instead. That way, the irq works
can be suspended until the kernel thread gets to run. Then even though
the waking of the thread will cause more events, it will be spaced out
enough not to cause an irq work storm.

-- Steve