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] [day] [month] [year] [list]
Date:	Mon, 15 Sep 2014 15:45:38 -0300
From:	Arnaldo Carvalho de Melo <>
To:	Alexander Yarygin <>
Cc:	David Ahern <>,,
	Christian Borntraeger <>,
	Ingo Molnar <>, Jiri Olsa <>,
	Paul Mackerras <>,
	Peter Zijlstra <>
Subject: Re: [PATCH RFC] perf kvm stat live: cache mmap()ed events

Em Mon, Sep 15, 2014 at 04:57:34PM +0400, Alexander Yarygin escreveu:
> 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.

> 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? :)

I don't have a problem solving this on some tool where the problem
happens and then, when some other tool hits the same problem, then one
looks at existing tools, figures out if some tool-specific solution can
be reused, moves it to common code, possibly improving it in the
process, and reuses it.

Sometimes trying to make it general from day one may lead to
overengineering :-)

With that said, David's patch looks clean and small enough, so if that
solves your problem, please let me know if I can apply it and your
Tested-by/Any-other-tags, ok?

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