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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Sep 2014 16:57:34 +0400
From:	Alexander Yarygin <>
To:	David Ahern <>
	Arnaldo Carvalho de Melo <>,
	Christian Borntraeger <>,
	Ingo Molnar <>, Jiri Olsa <>,
	Paul Mackerras <>,
	Peter Zijlstra <>,
	Alexander Yarygin <>
Subject: Re: [PATCH RFC] perf kvm stat live: cache mmap()ed events

David Ahern <> writes:

> On 9/12/14, 10:27 AM, Alexander Yarygin wrote:
>> During mmap() process 'perf kvm stat live' gets a pointer to events and
>> passes them to the session queue. Events are stored in shared memory and
>> eventually they will be overwritten by the kernel. The problem is, that
>> when events come too fast, old events can be overwritten before they
>> have been processed that can lead to perf crash.
>> To prevent that happening, we can copy upcoming events and pass a copy
>> to the session queue. There is a safe place to copy event: before
>> perf_evlist__mmap_consume() is executed. There are 3 places to free it:
>> when event is processed, when it's lost and on exit, if it's turned out
>> unprocessed.
> Did you see what I proposed a year ago:
> The intent is to keep the copy generic and not local a command since
> conceptually other live commands need the same.
> David


Yes, your patch works fine. But as far as I understand, right now only
the 'perf kvm stat live' is infected: other 'live' tools were fixed by
the patch "PERF: The tail position of the event buffer should only be modified
after actually use that event." and since they don't use ordered queue
they don't need a copying. That's why I came up with 'perf kvm stat
live' specific approach. Maybe I missed something...

Anyhow, having >30K events is a quite usual situation on s390 and the
'perf kvm stat live' command hardly works there, so it would be good to
have at least some working solution. Any ideas? :)


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