linux-kernel - Re: [PATCH RFC] perf kvm stat live: cache mmap()ed events

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: <20140915184538.GG11199@kernel.org>
Date:	Mon, 15 Sep 2014 15:45:38 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Alexander Yarygin <yarygin@...ux.vnet.ibm.com>
Cc:	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	Christian Borntraeger <borntraeger@...ibm.com>,
	Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
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 <dsahern@...il.com> 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:
> > https://lkml.org/lkml/2013/9/6/388

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