linux-kernel - Re: perf overlapping maps...

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: <20181023.111503.1978409398989251135.davem@davemloft.net>
Date:   Tue, 23 Oct 2018 11:15:03 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     acme@...nel.org
Cc:     jolsa@...hat.com, dzickus@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: perf overlapping maps...

From: Arnaldo Carvalho de Melo <acme@...nel.org>
Date: Tue, 23 Oct 2018 15:05:03 -0300

> IIRC this was first done for 'perf record', where we have to stash those
> events in the perf.data file, to then, later, 'perf report' to process
> those, so when working on 'perf top', it just reuses that machinery.
> 
> Sure, with some love and care 'perf top' could do better and update all
> the data structures directly :-)

Thanks for the history, it is useful information :)

> Anyway, have you guys considered tweaking using event->header.misc |=
> PERF_RECORD_MISC_USER? The kernel leaves that as zero for the
> PERF_RECORD_FORK it emits:

I really would like to steer the approach away from using UAPI
perf_event fields in an internal way.

I am really very sorry for suggesting such a scheme myself in the
first place.  It really was a bad idea upon much consideration.

The synthetic fork is not really a fork, it's more like a "create".

And this fundamental semantic difference is why we have all of these
issues wrt. handling COMM and parent map inheritance.

There is also a bunch of non-trivial code to deal with whether we
synthetically create the child or the parent first, wrt. finding
thread leaders and parent threads.

What I'm trying to say is that there is a clean design based solution
hiding somewhere in here and I'd like to find it :-)