[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1501081014460.24664@vincent-weaver-1.umelst.maine.edu>
Date: Thu, 8 Jan 2015 10:22:37 -0500 (EST)
From: Vince Weaver <vincent.weaver@...ne.edu>
To: linux-kernel@...r.kernel.org
cc: Peter Zijlstra <peterz@...radead.org>,
Paul Mackerras <paulus@...ba.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: perf: PERF_FLAG_FD_OUTPUT has been broken since 2.6.35
Hello,
I was working on improving the manpage by working out how the
perf_event_open() PERF_FLAG_FD_OUTPUT flag works.
It turns out it doesn't.
In kernel/events/core.c when opening a file this is done:
if (output_event) {
err = perf_event_set_output(event, output_event);
if (err)
goto err_context;
}
and perf_event_set_output() does:
if (output_event->cpu == -1 && output_event->ctx != event->ctx) {
goto out;
}
But event->ctx is always NULL; it does not get set to ctx until
after the call to perf_event_set_output().
It looks like this was broken back in 2.6.35 days with the change:
commit ac9721f3f54b27a16c7e1afb2481e7ee95a70318
Author: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Date: Thu May 27 12:54:41 2010 +0200
perf_events: Fix races and clean up perf_event and perf_mmap_data interaction
So is this worth fixing seeing as apparently no one uses this feature?
As an aside, added error reporting is *really* needed as I had to sprinkle
all of events/core.c with printk() calls to even begin to understand why
I was getting the EINVAL result.
Vince
--
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