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

From: Jiri Olsa <jolsa@...hat.com>
Date: Tue, 23 Oct 2018 08:34:52 +0200

> I'm not sure about using the misc field bit defined/used by userland,
> in case there's some new one comming in future for fork event..
> 
> but the only other way I can think of now is adding new 'user' event
> for that, but that ended up as a bigger change (attached)
> 
> I think if we make some 'big enough' comment about the bit usage,
> your change is better.. will you post or should I?

There might be something else we can do to implement this, and I think
making a whole new event for what is an application internal problem
is overkill.

What is kind of silly about how all of the synthetic events work is
that we throw away a lot of information by tossing the events over to
the generic event processing engine of the perf tool.

So we generate the events knowing the thread, context, PID, cpu, etc.
and then we lose all of that information, and the event processing
engine has to look all of it up again.

This is also, BTW, the reason we have dependencies on synthetic event
emission ordering.  F.e. this comes up wrt. COMM and FORK events.

I understand that this design allows the perf tool types to define a
private function to dispatch the events, as is appropriate for what
the tool is doing.

But the side effect of this design is that it means it is hard to pass
internal state around, outside of the event object itself.

Anyways, I'll look into this and see if there is a better way to
implement this.

Thanks!