linux-kernel - Re: [PATCH 12/12] Revert "perf record: Intercept all 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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jan 2010 12:57:45 -0200
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH 12/12] Revert "perf record: Intercept all events"

Em Mon, Jan 25, 2010 at 11:47:40PM +0900, Hitoshi Mitake escreveu:
> On Mon, Jan 25, 2010 at 11:23, Arnaldo Carvalho de Melo
> <acme@...radead.org> wrote:
> > Em Fri, Jan 22, 2010 at 10:39:13PM +0900, Hitoshi Mitake escreveu:
> >> This reverts commit f5a2c3dce03621b55f84496f58adc2d1a87ca16f.
> >>
> >> This patch is required for making "perf lock rec" work.
> >> The commit f5a2c3dce0 changes write_event() of builtin-record.c .
> >> And changed write_event() sometimes doesn't stop with perf lock rec.
> >>
> >> I'm researching what makes write_event() loop infinity,
> >> and noticed that there are some events with event_t->header.size == 0.
> >> But the detail of the problem,
> >> like kind of these events, isn't clear...
> >>
> >> If you know something related to this problem,
> >> could you tell me, Arnaldo?
> >
> > Well, this will have to wait for somebody to remove the need for
> > intercepting those events, reverting this patch fixes your tool while
> > breaking others that then won't catch all the events.
> 
> Yes, this patch is too egoistic thing and temporary solution.
> I have to consider and modify 'perf lock'.

Hey, don't get me wrong, the situation is fragile, either way something
will get broken and that isn't your fault, its just that we need some
sensible and non racy way to inject the buildids at 'perf record' time.

The way I did it, long ago, intercepting events in 'perf record' to
build a DSO list to then at 'perf record' exit to insert a table at the
perf.data file header looks too intrusive now, so we need some other way
that doesn't have this problem and its not racy.
 
> > I'll get 'perf regtest' out with some initial tests then try to get some
> > proposal for injecting the buildid, if found in a DSO, via
> > PERF_RECORD_MMAP, lets see how this goes...
> 
> What does "DSO" mean? Sorry, I'm not good at English...

As Peter said, anything that that is on an executable MMAP.
 
> >
> > Best Regards,
> >
> > - Arnaldo
> >
> > BTW: I took longer to send a response to this question addressed to me
> > because I wasn't on the CC list :-)
> 
> Oh, sorry... I wonder why I didn't add you to Cc or To :(
> It is completely my mistake, and thanks for your reply!

:-) Best Regards,

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