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: <20100125145745.GE24418@ghostprotocols.net>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ