linux-kernel - Re: [PATCH 6/9] oprofile: port to the new ring

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: <20081216172341.GK15411@erda.amd.com>
Date:	Tue, 16 Dec 2008 18:23:42 +0100
From:	Robert Richter <robert.richter@....com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	LKML <linux-kernel@...r.kernel.org>,
	oprofile-list <oprofile-list@...ts.sourceforge.net>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 6/9] oprofile: port to the new ring_buffer

On 11.12.08 14:48:56, Steven Rostedt wrote:
> > Since the new tracing ring buffer implementation uses spin locks to
> > protect the buffer during read/write access, it is difficult to use
> > the buffer in an NMI handler. In this case, writing to the buffer by
> > the NMI handler (x86) could occur also during critical sections when
> > reading the buffer. To avoid this, there are 2 buffers for independent
> > read and write access. Read access is in process context only, write
> > access only in the NMI handler. If the read buffer runs empty, both
> > buffers are swapped atomically. There is potentially a small window
> > during swapping where the buffers are disabled and samples could be
> > lost.
> 
> There is plans on removing the spinlock from the write side of the buffer.
> But this will take a bit of work and care. Lockless is better, but it also 
> makes for more complex code which translates to more prone to bugs code.

In the beginning, the use of separate locks for reading and writing
would be sufficient. Then, there would be only one atomic comparison
needed to check, if the write pointer meets the read pointer. This
should be not as difficult since read and write is always in different
pages (if a am not wrong) and thus only the pointer to the pages have
to be compared.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@....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/