linux-kernel - Re: [PATCH v2] ring-buffer: Race when writing and swapping cpu buffer in parallel

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] [day] [month] [year] [list]

Message-ID: <20140715094030.4b3c6314@gandalf.local.home>
Date:	Tue, 15 Jul 2014 09:40:30 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Petr Mládek <pmladek@...e.cz>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ring-buffer: Race when writing and swapping cpu
 buffer in parallel

On Tue, 15 Jul 2014 11:07:35 +0200
Petr Mládek <pmladek@...e.cz> wrote:

 
> Just to be sure. Should I remove RING_BUFFER_ALLOW_SWAP config
> option completely?

No. Just that one #if block. The per cpu swap is still a bit icky in my
humble opinion, and should stay a config for now.

> 
> > Although your above comment is wrong. We can most
> > definitely be in the middle of a swap operation. You forget that
> > tracing is NMI safe.
> > 
> > But the swap does disable tracing, then if a NMI were to preempt the
> > swap, it will either be outside the critical part where it is still safe
> > to perform the trace or it will be where the swap is happening and the
> > tracing will be disabled.
> 
> I probably did not use precise enough sentence. I wanted to explain
> why we do not check for "cpu_buffer->record_disabled" here. I added
> this test in the 1st version of the patch but then I realized that it
> was not needed.
> 
> As you say, there are two possibilities when swap is interrupted by
> NMI. Either it is outside of the critical section and then the write is
> completed before we continue with swapping. Or the interrupt is inside
> the critical section and then the nested write fails early in
> ring_buffer_write() or ring_buffer_lock_reserve() before this
> code is called.
> 
> A better comment might be:
> 
> 	* Note that we will never be in the middle of a swap critical
> 	* section here. If the swapping is interrupted when recording
> 	* is disabled, the nested write will fail earlier in
> 	* ring_buffer_write() or ring_buffer_lock_reserve().
> 	*/
> 
> 
> Note that I am still learning about the preferred practice with comments inside
> the kernel code. I have spent a lot of time trying to understand the
> ring buffer. I think that more comments like this would have
> helped me to get the picture faster. Another possibility would be to
> create Documentation/trace/ring-buffer.txt.

Well there is a Documentation/trace/ring-buffer-design.txt doc ;-)

> 
> I have more notes here. Let me know if I should cook up some patches
> that would extend the ring buffer documentation according to my
> experience.

I have no problems with adding documentation to the code.

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