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  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:	Mon, 06 Oct 2014 12:08:19 +0300
From:	Alexander Shishkin <>
To:	Peter Zijlstra <>
Cc:	Ingo Molnar <>,,
	Robert Richter <>,
	Frederic Weisbecker <>,
	Mike Galbraith <>,
	Paul Mackerras <>,
	Stephane Eranian <>,
	Andi Kleen <>,
Subject: Re: [PATCH v4 02/22] perf: Add AUX area to ring buffer for raw data streams

Peter Zijlstra <> writes:

> On Mon, Sep 08, 2014 at 03:55:11PM +0300, Alexander Shishkin wrote:
>> Fair enough. Then I'd like to disable the ACTIVE ones before freeing AUX
>> stuff and then re-enabling them since perf_event_{en,dis}able() already
>> provide the convenient cross-cpu calls, which would also avoid
>> concurrency between pmu::{add,del} callbacks and this unmap path. Makes
>> sense?
> But why? The buffer stuff is RCU freed, so if the hardware observes
> pages and does get_page_unless_zero() on them its good. The memory will
> not be freed from underneath the hardware writer because of the
> get_page().
> Then when the buffer is full and we 'swap', we'll find there is no next
> buffer. At that point we can not provide a new buffer, effectively
> stopping the hardware writes and release the old buffer, freeing the
> memory.

There are several problems with this. Firstly, aux buffers can be quite
large, which means that we have to do get_page() on thousands of pages
on every pmu::add, which is a hot path and free_page() again in

Secondly, all the sg bookkeeping that the driver keeps in aux_priv needs
to be refcounted. Right now, in the mmap_close path we just free
everything. But if we want to free the aux_pages in pmu::del, we need to
keep a list of these pages still around after mmap_close() and same goes
for the actual sg tables. I can see a way of doing that on the ring
buffer side (as opposed to the driver side), but are you quite sure we
should go down this road?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists