[2/2] perf: Userspace software event and ioctl

Message ID 1411050873-9310-3-git-send-email-pawel.moll@arm.com
State New
Headers show

Commit Message

Pawel Moll Sept. 18, 2014, 2:34 p.m.
This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
which can be generated by user with PERF_EVENT_IOC_ENTRY
ioctl command, which injects an event of said type into
the perf buffer.

The ioctl takes a pointer to struct perf_event_userspace
as an argument. The structure begins with a 64-bit
integer type value, which determines meaning of the
following content (size/data pair). Type 0 are defined
as zero-terminated strings, other types are defined by
userspace (the perf tool will contain a list of
known values with reference implementation of data
content parsers).

Possible use cases for this feature:

- "perf_printf" like mechanism to add logging messages
  to one's perf session; an example implementation:

	int perf_printf(int perf_fd, const char *fmt, ...)
	{
	        struct perf_event_userspace *event;
	        int size;
	        va_list ap;
	        int err;

	        va_start(ap, fmt);

	        size = vsnprintf(NULL, 0, fmt, ap) + 1;
	        event = malloc(sizeof(*event) + size);
	        if (!event) {
	                va_end(ap);
	                return -1;
	        }

	        event->type = 0;
	        event->size = size;
	        vsnprintf(event->data, size, fmt, ap);

	        va_end(ap);

	        err = ioctl(perf_fd, PERF_EVENT_IOC_USERSPACE, event);

	        free(event);

	        return err < 0 ? err : size - 1;
	}

- "perf_printf" used by for perf trace tool,
  where certain traced process' calls are intercepted
  (eg. using LD_PRELOAD) and treated as logging
  requests, with it output redirected into the
  perf buffer

- synchronisation of performance data generated in
  user space with the perf stream coming from the kernel.
  For example, the marker can be inserted by a JIT engine
  after it generated portion of the code, but before the
  code is executed for the first time, allowing the
  post-processor to pick the correct debugging
  information.

- other example is a system profiling tool taking data
  from other sources than just perf, which generates a marker
  at the beginning at at the end of the session
  (also possibly periodically during the session) to
  synchronise kernel timestamps with clock values
  obtained in userspace (gtod or raw_monotonic).

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
 include/linux/perf_event.h      |  8 +++++
 include/uapi/linux/perf_event.h | 34 ++++++++++++++++++++-
 kernel/events/core.c            | 68 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 109 insertions(+), 1 deletion(-)

Comments

Pawel Moll Sept. 23, 2014, 5:02 p.m. | #1
On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote:
> This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
> which can be generated by user with PERF_EVENT_IOC_ENTRY
> ioctl command, which injects an event of said type into
> the perf buffer.

It occurred to me last night that currently perf doesn't handle "write"
syscall at all, while this seems like the most natural way of
"injecting" userspace events into perf buffer.

An ioctl would still be needed to set a type of the following events,
something like:

	ioctl(SET_TYPE, 0x42);
	write(perf_fd, binaryblob, size);
	ioctl(SET_TYPE, 0);
	dprintf(perf_fd, "String");

which is fine for use cases when the type doesn't change often, but
would double the amount of syscalls when every single event is of a
different type. Perhaps there still should be a "generating ioctl"
taking both type and data/size in one go?

Anyway, I'll post a series showing this solution in a second.

As always, feedback is more than welcome.

Pawel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Ingo Molnar Sept. 24, 2014, 7:49 a.m. | #2
* Pawel Moll <pawel.moll@arm.com> wrote:

> On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote:
> > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
> > which can be generated by user with PERF_EVENT_IOC_ENTRY
> > ioctl command, which injects an event of said type into
> > the perf buffer.
> 
> It occurred to me last night that currently perf doesn't handle "write"
> syscall at all, while this seems like the most natural way of
> "injecting" userspace events into perf buffer.
> 
> An ioctl would still be needed to set a type of the following events,
> something like:
> 
> 	ioctl(SET_TYPE, 0x42);
> 	write(perf_fd, binaryblob, size);
> 	ioctl(SET_TYPE, 0);
> 	dprintf(perf_fd, "String");
> 
> which is fine for use cases when the type doesn't change often, 
> but would double the amount of syscalls when every single event 
> is of a different type. Perhaps there still should be a 
> "generating ioctl" taking both type and data/size in one go?

Absolutely, there should be a single syscall.

I'd even argue it should be a new prctl(): that way we could both 
generate user events for specific perf fds, but also into any 
currently active context (that allows just generation/injection 
of user events). In the latter case we might have no fd to work 
off from.

And that is actually the really exciting usecase of your patches: 
we could generate user events via simple commands, and any 
external profiler/trace would be able to see them.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pawel Moll Sept. 25, 2014, 5:20 p.m. | #3
On Wed, 2014-09-24 at 08:49 +0100, Ingo Molnar wrote:
> * Pawel Moll <pawel.moll@arm.com> wrote:
> 
> > On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote:
> > > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
> > > which can be generated by user with PERF_EVENT_IOC_ENTRY
> > > ioctl command, which injects an event of said type into
> > > the perf buffer.
> > 
> > It occurred to me last night that currently perf doesn't handle "write"
> > syscall at all, while this seems like the most natural way of
> > "injecting" userspace events into perf buffer.
> > 
> > An ioctl would still be needed to set a type of the following events,
> > something like:
> > 
> > 	ioctl(SET_TYPE, 0x42);
> > 	write(perf_fd, binaryblob, size);
> > 	ioctl(SET_TYPE, 0);
> > 	dprintf(perf_fd, "String");
> > 
> > which is fine for use cases when the type doesn't change often, 
> > but would double the amount of syscalls when every single event 
> > is of a different type. Perhaps there still should be a 
> > "generating ioctl" taking both type and data/size in one go?
> 
> Absolutely, there should be a single syscall.

Yeah, it's my gut feeling as well. I just wonder if we still want to
keep write() handler for operations on perf fds? This seems natural -
takes data buffer and its size. The only issue is the type.

> I'd even argue it should be a new prctl(): that way we could both 
> generate user events for specific perf fds, but also into any 
> currently active context (that allows just generation/injection 
> of user events). In the latter case we might have no fd to work 
> off from.

When Arnaldo suggested that the "user events" could be used by perf
trace, it was exactly my first thought. I just didn't have answer how to
present it to the user (an extra syscall didn't seem like a good idea),
but prctl seems interesting, something like this?

	prctl(PR_TRACE_UEVENT, type, size, data, 0);

How would we select tasks that can write to a given buffer? Maybe an
ioctl() on a perf fd? Something like this?

	ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
	ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);

It could set/clear a flag in pid's task_struct (but probably not in the
"normal" flags, as they are only supposed to be set by owner and in
ptrace/fork case) and a pointer to the task in perf_event(_context).

Or maybe some variation on ptrace would be more in place? This would
also solve issue of permission checking (if the profiling tool can
ptrace the process, it can also enable/disable its uevent generation
capability).

Paweł


Or maybe it should go through ptrace?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Ingo Molnar Sept. 25, 2014, 6:33 p.m. | #4
* Pawel Moll <pawel.moll@arm.com> wrote:

> On Wed, 2014-09-24 at 08:49 +0100, Ingo Molnar wrote:
> > * Pawel Moll <pawel.moll@arm.com> wrote:
> > 
> > > On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote:
> > > > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
> > > > which can be generated by user with PERF_EVENT_IOC_ENTRY
> > > > ioctl command, which injects an event of said type into
> > > > the perf buffer.
> > > 
> > > It occurred to me last night that currently perf doesn't handle "write"
> > > syscall at all, while this seems like the most natural way of
> > > "injecting" userspace events into perf buffer.
> > > 
> > > An ioctl would still be needed to set a type of the following events,
> > > something like:
> > > 
> > > 	ioctl(SET_TYPE, 0x42);
> > > 	write(perf_fd, binaryblob, size);
> > > 	ioctl(SET_TYPE, 0);
> > > 	dprintf(perf_fd, "String");
> > > 
> > > which is fine for use cases when the type doesn't change often, 
> > > but would double the amount of syscalls when every single event 
> > > is of a different type. Perhaps there still should be a 
> > > "generating ioctl" taking both type and data/size in one go?
> > 
> > Absolutely, there should be a single syscall.
> 
> Yeah, it's my gut feeling as well. I just wonder if we still want to
> keep write() handler for operations on perf fds? This seems natural -
> takes data buffer and its size. The only issue is the type.
> 
> > I'd even argue it should be a new prctl(): that way we could both 
> > generate user events for specific perf fds, but also into any 
> > currently active context (that allows just generation/injection 
> > of user events). In the latter case we might have no fd to work 
> > off from.
> 
> When Arnaldo suggested that the "user events" could be used by perf
> trace, it was exactly my first thought. I just didn't have answer how to
> present it to the user (an extra syscall didn't seem like a good idea),
> but prctl seems interesting, something like this?
> 
> 	prctl(PR_TRACE_UEVENT, type, size, data, 0);

Exactly!

> How would we select tasks that can write to a given buffer? Maybe an
> ioctl() on a perf fd? Something like this?
> 
> 	ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
> 	ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);

No, I think there's a simpler way: this should be a regular 
perf_attr flag, which defaults to '0' (tasks cannot do this), but 
which can be set to 1 if the profiler explicitly allows such 
event injection.

perf-trace might want to set this flag by default.

I.e. whether user-events are allowed is controlled by the 
profiling/tracing context, via the regular perf syscall. It would 
propagate into the perf context, so it would be easy to check at 
event generation time.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pawel Moll Sept. 26, 2014, 10:48 a.m. | #5
On Thu, 2014-09-25 at 19:33 +0100, Ingo Molnar wrote:
> > How would we select tasks that can write to a given buffer? Maybe an
> > ioctl() on a perf fd? Something like this?
> > 
> > 	ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
> > 	ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);
> 
> No, I think there's a simpler way: this should be a regular 
> perf_attr flag, which defaults to '0' (tasks cannot do this), but 
> which can be set to 1 if the profiler explicitly allows such 
> event injection.

As in: allows *all* tasks to inject the data? Are you sure we don't want
more fine-grained control, in particular per task?

If we have two buffers, both created with the "injecting allowed" flag,
do we inject a given uevent into both of them?

> I.e. whether user-events are allowed is controlled by the 
> profiling/tracing context, via the regular perf syscall. It would 
> propagate into the perf context, so it would be easy to check at 
> event generation time.

It would definitely be the profiling/tracing tools that would decide if
the injection is allowed, no question about that. I just feel that it
should be able to select the tasks that can do that, not just flip a big
switch saying "everyone is welcome". Other question is: should a
non-root context be able to receive events from root processes? Wouldn't
it be a security hole (for example, it could be used as a kind of covert
channel)? Maybe we should do what ptrace does? As in: if a task can
ptrace another task, it can also receive uevents from it.

Pawel



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Ingo Molnar Sept. 26, 2014, 11:23 a.m. | #6
* Pawel Moll <pawel.moll@arm.com> wrote:

> On Thu, 2014-09-25 at 19:33 +0100, Ingo Molnar wrote:
> > > How would we select tasks that can write to a given buffer? Maybe an
> > > ioctl() on a perf fd? Something like this?
> > > 
> > > 	ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
> > > 	ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);
> > 
> > No, I think there's a simpler way: this should be a regular 
> > perf_attr flag, which defaults to '0' (tasks cannot do this), 
> > but which can be set to 1 if the profiler explicitly allows 
> > such event injection.
> 
> As in: allows *all* tasks to inject the data? Are you sure we 
> don't want more fine-grained control, in particular per task?

Yeah. If the profiler allows it, then any task that is being 
traced can inject data.

More finegrained control might be useful if there's a 
justification for it, but only if this basic, most useful model 
is implemented. Too finegrained control will just make it 
unusable. So please keep it simple and useful.

> If we have two buffers, both created with the "injecting 
> allowed" flag, do we inject a given uevent into both of them?

Yes, and that semantics is desired: if I run two globally tracing 
apps, independent of each other, both ought to get the events if 
they ask for them.

> > I.e. whether user-events are allowed is controlled by the 
> > profiling/tracing context, via the regular perf syscall. It 
> > would propagate into the perf context, so it would be easy to 
> > check at event generation time.
> 
> It would definitely be the profiling/tracing tools that would 
> decide if the injection is allowed, no question about that. I 
> just feel that it should be able to select the tasks that can 
> do that, not just flip a big switch saying "everyone is 
> welcome". [...]

But that's the point: our main problem right now is too little 
data (not enough apps generating interesting events), not too 
much data.

So lets concentrate on the task of getting events to us as easily 
as possible first. If in the far future we are overwhelmed with 
events, and tools want to do some filtering on them, by all means 
we can implement it - but don't impose it straight away.

> [...] Other question is: should a non-root context be able to 
> receive events from root processes? Wouldn't it be a security 
> hole (for example, it could be used as a kind of covert 
> channel)? Maybe we should do what ptrace does? As in: if a task 
> can ptrace another task, it can also receive uevents from it.

So, by default a non-root context will not be able to 
profile/trace a root owned task already, it cannot generate per 
CPU events for example. So this already handled at event/buffer 
creation time. Plus if a task gains privilege (via suid exec) 
then we already zap its perf context IIRC.

Should be double checked, but the important part is to make it to 
willing tracing apps as easy as possible. Lets worry about the 
'too much data' case later, otherwise we _guarantee_ that this 
interface won't take off and apps, tools and people won't use it, 
ok?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pawel Moll Sept. 26, 2014, 11:26 a.m. | #7
On Fri, 2014-09-26 at 12:23 +0100, Ingo Molnar wrote:
> > As in: allows *all* tasks to inject the data? Are you sure we 
> > don't want more fine-grained control, in particular per task?
> 
> Yeah. If the profiler allows it, then any task that is being 
> traced can inject data.

The "that is being traced" fragment was the key here. I missed the fact
that perf trace already takes a list of pids, so we're not talking about
all tasks in the system. That should work.

Paweł

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Ingo Molnar Sept. 26, 2014, 11:31 a.m. | #8
* Pawel Moll <pawel.moll@arm.com> wrote:

> On Fri, 2014-09-26 at 12:23 +0100, Ingo Molnar wrote:
> > > As in: allows *all* tasks to inject the data? Are you sure we 
> > > don't want more fine-grained control, in particular per task?
> > 
> > Yeah. If the profiler allows it, then any task that is being 
> > traced can inject data.
> 
> The "that is being traced" fragment was the key here. I missed 
> the fact that perf trace already takes a list of pids, so we're 
> not talking about all tasks in the system. That should work.

Yeah, when we generate a user trace event, we should look at the 
currently active perf context's (percpu ones plus task ones), and 
inject into those only.

This way we limit event generation to those buffers that are 
actively interested in this task.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Frederic Weisbecker Sept. 27, 2014, 5:14 p.m. | #9
2014-09-25 20:33 GMT+02:00 Ingo Molnar <mingo@kernel.org>:
>
> * Pawel Moll <pawel.moll@arm.com> wrote:
>
>> On Wed, 2014-09-24 at 08:49 +0100, Ingo Molnar wrote:
>> > * Pawel Moll <pawel.moll@arm.com> wrote:
>> >
>> > > On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote:
>> > > > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
>> > > > which can be generated by user with PERF_EVENT_IOC_ENTRY
>> > > > ioctl command, which injects an event of said type into
>> > > > the perf buffer.
>> > >
>> > > It occurred to me last night that currently perf doesn't handle "write"
>> > > syscall at all, while this seems like the most natural way of
>> > > "injecting" userspace events into perf buffer.
>> > >
>> > > An ioctl would still be needed to set a type of the following events,
>> > > something like:
>> > >
>> > >   ioctl(SET_TYPE, 0x42);
>> > >   write(perf_fd, binaryblob, size);
>> > >   ioctl(SET_TYPE, 0);
>> > >   dprintf(perf_fd, "String");
>> > >
>> > > which is fine for use cases when the type doesn't change often,
>> > > but would double the amount of syscalls when every single event
>> > > is of a different type. Perhaps there still should be a
>> > > "generating ioctl" taking both type and data/size in one go?
>> >
>> > Absolutely, there should be a single syscall.
>>
>> Yeah, it's my gut feeling as well. I just wonder if we still want to
>> keep write() handler for operations on perf fds? This seems natural -
>> takes data buffer and its size. The only issue is the type.
>>
>> > I'd even argue it should be a new prctl(): that way we could both
>> > generate user events for specific perf fds, but also into any
>> > currently active context (that allows just generation/injection
>> > of user events). In the latter case we might have no fd to work
>> > off from.
>>
>> When Arnaldo suggested that the "user events" could be used by perf
>> trace, it was exactly my first thought. I just didn't have answer how to
>> present it to the user (an extra syscall didn't seem like a good idea),
>> but prctl seems interesting, something like this?
>>
>>       prctl(PR_TRACE_UEVENT, type, size, data, 0);
>
> Exactly!
>
>> How would we select tasks that can write to a given buffer? Maybe an
>> ioctl() on a perf fd? Something like this?
>>
>>       ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
>>       ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);
>
> No, I think there's a simpler way: this should be a regular
> perf_attr flag, which defaults to '0' (tasks cannot do this), but
> which can be set to 1 if the profiler explicitly allows such
> event injection.

Maybe we just don't even need any permission at all. Which harm can
that do if this only ever generate events to those interested in the
relevant perf context? It could be a simple tracepoint BTW.

Oh and I really like the fact we don't use a syscall that requires an
fd. The tracee really shouldn't be aware of the tracer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pawel Moll Sept. 29, 2014, 2:52 p.m. | #10
On Sat, 2014-09-27 at 18:14 +0100, Frederic Weisbecker wrote:
> 2014-09-25 20:33 GMT+02:00 Ingo Molnar <mingo@kernel.org>:
> >
> > * Pawel Moll <pawel.moll@arm.com> wrote:
> >
> >> On Wed, 2014-09-24 at 08:49 +0100, Ingo Molnar wrote:
> >> > * Pawel Moll <pawel.moll@arm.com> wrote:
> >> >
> >> > > On Thu, 2014-09-18 at 15:34 +0100, Pawel Moll wrote:
> >> > > > This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
> >> > > > which can be generated by user with PERF_EVENT_IOC_ENTRY
> >> > > > ioctl command, which injects an event of said type into
> >> > > > the perf buffer.
> >> > >
> >> > > It occurred to me last night that currently perf doesn't handle "write"
> >> > > syscall at all, while this seems like the most natural way of
> >> > > "injecting" userspace events into perf buffer.
> >> > >
> >> > > An ioctl would still be needed to set a type of the following events,
> >> > > something like:
> >> > >
> >> > >   ioctl(SET_TYPE, 0x42);
> >> > >   write(perf_fd, binaryblob, size);
> >> > >   ioctl(SET_TYPE, 0);
> >> > >   dprintf(perf_fd, "String");
> >> > >
> >> > > which is fine for use cases when the type doesn't change often,
> >> > > but would double the amount of syscalls when every single event
> >> > > is of a different type. Perhaps there still should be a
> >> > > "generating ioctl" taking both type and data/size in one go?
> >> >
> >> > Absolutely, there should be a single syscall.
> >>
> >> Yeah, it's my gut feeling as well. I just wonder if we still want to
> >> keep write() handler for operations on perf fds? This seems natural -
> >> takes data buffer and its size. The only issue is the type.
> >>
> >> > I'd even argue it should be a new prctl(): that way we could both
> >> > generate user events for specific perf fds, but also into any
> >> > currently active context (that allows just generation/injection
> >> > of user events). In the latter case we might have no fd to work
> >> > off from.
> >>
> >> When Arnaldo suggested that the "user events" could be used by perf
> >> trace, it was exactly my first thought. I just didn't have answer how to
> >> present it to the user (an extra syscall didn't seem like a good idea),
> >> but prctl seems interesting, something like this?
> >>
> >>       prctl(PR_TRACE_UEVENT, type, size, data, 0);
> >
> > Exactly!
> >
> >> How would we select tasks that can write to a given buffer? Maybe an
> >> ioctl() on a perf fd? Something like this?
> >>
> >>       ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
> >>       ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);
> >
> > No, I think there's a simpler way: this should be a regular
> > perf_attr flag, which defaults to '0' (tasks cannot do this), but
> > which can be set to 1 if the profiler explicitly allows such
> > event injection.
> 
> Maybe we just don't even need any permission at all. Which harm can
> that do if this only ever generate events to those interested in the
> relevant perf context? It could be a simple tracepoint BTW.

Yeah, Ingo already pointed it out (that non-root task can't trace root
tasks anyway).

> Oh and I really like the fact we don't use a syscall that requires an
> fd. The tracee really shouldn't be aware of the tracer.

Agreed, I'll look at solution with prctl() this week.

Pawel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Peter Zijlstra Sept. 29, 2014, 3:32 p.m. | #11
On Thu, Sep 18, 2014 at 03:34:33PM +0100, Pawel Moll wrote:
> This patch adds a PERF_COUNT_SW_USERSPACE_EVENT type,
> which can be generated by user with PERF_EVENT_IOC_ENTRY
> ioctl command, which injects an event of said type into
> the perf buffer.
> 
> The ioctl takes a pointer to struct perf_event_userspace
> as an argument. The structure begins with a 64-bit
> integer type value, which determines meaning of the
> following content (size/data pair). Type 0 are defined
> as zero-terminated strings, other types are defined by
> userspace (the perf tool will contain a list of
> known values with reference implementation of data
> content parsers).
> 
> Possible use cases for this feature:
> 
> - "perf_printf" like mechanism to add logging messages
>   to one's perf session; an example implementation:
> 
> 	int perf_printf(int perf_fd, const char *fmt, ...)
> 	{
> 	        struct perf_event_userspace *event;
> 	        int size;
> 	        va_list ap;
> 	        int err;
> 
> 	        va_start(ap, fmt);
> 
> 	        size = vsnprintf(NULL, 0, fmt, ap) + 1;
> 	        event = malloc(sizeof(*event) + size);
> 	        if (!event) {
> 	                va_end(ap);
> 	                return -1;
> 	        }
> 
> 	        event->type = 0;
> 	        event->size = size;
> 	        vsnprintf(event->data, size, fmt, ap);
> 
> 	        va_end(ap);
> 
> 	        err = ioctl(perf_fd, PERF_EVENT_IOC_USERSPACE, event);
> 
> 	        free(event);
> 
> 	        return err < 0 ? err : size - 1;
> 	}
> 
> - "perf_printf" used by for perf trace tool,
>   where certain traced process' calls are intercepted
>   (eg. using LD_PRELOAD) and treated as logging
>   requests, with it output redirected into the
>   perf buffer
> 
> - synchronisation of performance data generated in
>   user space with the perf stream coming from the kernel.
>   For example, the marker can be inserted by a JIT engine
>   after it generated portion of the code, but before the
>   code is executed for the first time, allowing the
>   post-processor to pick the correct debugging
>   information.
> 
> - other example is a system profiling tool taking data
>   from other sources than just perf, which generates a marker
>   at the beginning at at the end of the session
>   (also possibly periodically during the session) to
>   synchronise kernel timestamps with clock values
>   obtained in userspace (gtod or raw_monotonic).


Feel free to use up to 70 chars wide text in Changelogs. Most editors
have support for reflowing text. No need to keep it this narrow.

Also none of the many words above describe
PERF_SAMPLE_USERSPACE_EVENT(), wth is that about?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pawel Moll Sept. 29, 2014, 3:53 p.m. | #12
On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote:
> Also none of the many words above describe
> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about?

Hopefully description of the v2 makes better job in this:

http://thread.gmane.org/gmane.linux.kernel/1793272/focus=4813

where it's already called "UEVENT" and was generated by write().

Before you get into this, though, the most important outcomes of both v1
and v2 discussions:

* Ingo suggested prctl(PR_TRACE_UEVENT, type, size, data, 0) as the way
of generating such events (so the tracee doesn't have to know the fd to
do ioctl); Frederic seems to have the same on his mind.

* Namhyung proposed sticking the userspace-originating events into the
buffer as PERF_RECORD_UEVENT rather then PERF_SAMPLE_UEVENT.

Working on making both happen now.

Pawel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Tomeu Vizoso Nov. 3, 2014, 2:48 p.m. | #13
On 29 September 2014 17:53, Pawel Moll <pawel.moll@arm.com> wrote:
> On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote:
>> Also none of the many words above describe
>> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about?
>
> Hopefully description of the v2 makes better job in this:
>
> http://thread.gmane.org/gmane.linux.kernel/1793272/focus=4813
>
> where it's already called "UEVENT" and was generated by write().
>
> Before you get into this, though, the most important outcomes of both v1
> and v2 discussions:
>
> * Ingo suggested prctl(PR_TRACE_UEVENT, type, size, data, 0) as the way
> of generating such events (so the tracee doesn't have to know the fd to
> do ioctl); Frederic seems to have the same on his mind.
>
> * Namhyung proposed sticking the userspace-originating events into the
> buffer as PERF_RECORD_UEVENT rather then PERF_SAMPLE_UEVENT.
>
> Working on making both happen now.

Hi Pawel,

are you still working on this? Would be happy to lend a hand if that
can speed things up.

Cheers,

Tomeu

> Pawel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Pawel Moll Nov. 3, 2014, 3:04 p.m. | #14
On Mon, 2014-11-03 at 14:48 +0000, Tomeu Vizoso wrote:
> On 29 September 2014 17:53, Pawel Moll <pawel.moll@arm.com> wrote:
> > On Mon, 2014-09-29 at 16:32 +0100, Peter Zijlstra wrote:
> >> Also none of the many words above describe
> >> PERF_SAMPLE_USERSPACE_EVENT(), wth is that about?
> >
> > Hopefully description of the v2 makes better job in this:
> >
> > http://thread.gmane.org/gmane.linux.kernel/1793272/focus=4813
> >
> > where it's already called "UEVENT" and was generated by write().
> >
> > Before you get into this, though, the most important outcomes of both v1
> > and v2 discussions:
> >
> > * Ingo suggested prctl(PR_TRACE_UEVENT, type, size, data, 0) as the way
> > of generating such events (so the tracee doesn't have to know the fd to
> > do ioctl); Frederic seems to have the same on his mind.
> >
> > * Namhyung proposed sticking the userspace-originating events into the
> > buffer as PERF_RECORD_UEVENT rather then PERF_SAMPLE_UEVENT.
> >
> > Working on making both happen now.
> 
> are you still working on this? Would be happy to lend a hand if that
> can speed things up.

By all means! In fact I'm typing commit messages right now and will post
the patches later today. Stay tuned and I'm looking forward to all
suggestions, reviews etc.

Cheers!

Pawel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch hide | download patch | download mbox

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 28b73b2..d904d31 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -64,6 +64,12 @@  struct perf_raw_record {
 	void				*data;
 };
 
+struct perf_userspace_entry {
+	u32				type;
+	u32				size;
+	u8				data[0];
+};
+
 /*
  * branch stack layout:
  *  nr: number of taken branches stored in entries[]
@@ -604,6 +610,8 @@  struct perf_sample_data {
 	u64				txn;
 	/* Raw monotonic timestamp, for userspace time correlation */
 	u64				clock_raw_monotonic;
+	/* Userspace-originating event */
+	struct perf_userspace_entry	*user_entry;
 };
 
 static inline void perf_sample_data_init(struct perf_sample_data *data,
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index e5a75c5..37604ae 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -110,6 +110,7 @@  enum perf_sw_ids {
 	PERF_COUNT_SW_ALIGNMENT_FAULTS		= 7,
 	PERF_COUNT_SW_EMULATION_FAULTS		= 8,
 	PERF_COUNT_SW_DUMMY			= 9,
+	PERF_COUNT_SW_USERSPACE_EVENT		= 10,
 
 	PERF_COUNT_SW_MAX,			/* non-ABI */
 };
@@ -138,8 +139,9 @@  enum perf_event_sample_format {
 	PERF_SAMPLE_IDENTIFIER			= 1U << 16,
 	PERF_SAMPLE_TRANSACTION			= 1U << 17,
 	PERF_SAMPLE_CLOCK_RAW_MONOTONIC		= 1U << 18,
+	PERF_SAMPLE_USERSPACE_EVENT		= 1U << 19,
 
-	PERF_SAMPLE_MAX = 1U << 19,		/* non-ABI */
+	PERF_SAMPLE_MAX = 1U << 20,		/* non-ABI */
 };
 
 /*
@@ -337,6 +339,15 @@  struct perf_event_attr {
 	__u32	__reserved_2;
 };
 
+/*
+ * Userspace-originating event to be generated with PERF_EVENT_IOC_USERSPACE
+ */
+struct perf_event_userspace {
+	__u32	type;
+	__u32	size;
+	__u8	data[0];
+};
+
 #define perf_flags(attr)	(*(&(attr)->read_format + 1))
 
 /*
@@ -350,6 +361,8 @@  struct perf_event_attr {
 #define PERF_EVENT_IOC_SET_OUTPUT	_IO ('$', 5)
 #define PERF_EVENT_IOC_SET_FILTER	_IOW('$', 6, char *)
 #define PERF_EVENT_IOC_ID		_IOR('$', 7, __u64 *)
+#define PERF_EVENT_IOC_USERSPACE	_IOR('$', 8, \
+						struct perf_event_userspace *)
 
 enum perf_event_ioc_flags {
 	PERF_IOC_FLAG_GROUP		= 1U << 0,
@@ -688,6 +701,25 @@  enum perf_event_type {
 	 *	{ u64			data_src; } && PERF_SAMPLE_DATA_SRC
 	 *	{ u64			transaction; } && PERF_SAMPLE_TRANSACTION
 	 *	{ u64			clock_raw_monotonic; } && PERF_SAMPLE_CLOCK_RAW_MONOTONIC
+	 *
+	 *	#
+	 *	# Contents of USERSPACE_EVENT sample data depend on its type.
+	 *	#
+	 *	# Type 0 means that the data is a zero-terminated string that
+	 *	# can be printf-ed in the normal way.
+	 *	#
+	 *	# Meaning of other type values depends on the userspace
+	 *	# and the perf tool code contains a list of those with
+	 *	# reference implementations of parsers.
+	 *	#
+	 *	# Overall size of the sample (including type and size fields)
+	 *	# is always aligned to 8 bytes by adding padding after
+	 *	# the data.
+	 *	#
+	 *	{ u32			type;
+	 *	  u32			size;
+	 *	  char			data[size];
+	 *	  char                  __padding[] } && PERF_SAMPLE_USERSPACE_EVENT
 	 * };
 	 */
 	PERF_RECORD_SAMPLE			= 9,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f6df547..11bf1be 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3655,6 +3655,8 @@  static inline int perf_fget_light(int fd, struct fd *p)
 static int perf_event_set_output(struct perf_event *event,
 				 struct perf_event *output_event);
 static int perf_event_set_filter(struct perf_event *event, void __user *arg);
+static int perf_sw_userspace_entry(struct perf_event *event,
+	       struct perf_event_userspace __user *arg);
 
 static long perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 {
@@ -3709,6 +3711,10 @@  static long perf_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 	case PERF_EVENT_IOC_SET_FILTER:
 		return perf_event_set_filter(event, (void __user *)arg);
 
+	case PERF_EVENT_IOC_USERSPACE:
+		return perf_sw_userspace_entry(event,
+				(struct perf_event_userspace __user *)arg);
+
 	default:
 		return -ENOTTY;
 	}
@@ -3728,6 +3734,7 @@  static long perf_compat_ioctl(struct file *file, unsigned int cmd,
 	switch (_IOC_NR(cmd)) {
 	case _IOC_NR(PERF_EVENT_IOC_SET_FILTER):
 	case _IOC_NR(PERF_EVENT_IOC_ID):
+	case _IOC_NR(PERF_EVENT_IOC_USERSPACE):
 		/* Fix up pointer size (usually 4 -> 8 in 32-on-64-bit case */
 		if (_IOC_SIZE(cmd) == sizeof(compat_uptr_t)) {
 			cmd &= ~IOCSIZE_MASK;
@@ -4727,6 +4734,16 @@  void perf_output_sample(struct perf_output_handle *handle,
 	if (sample_type & PERF_SAMPLE_CLOCK_RAW_MONOTONIC)
 		perf_output_put(handle, data->clock_raw_monotonic);
 
+	if (sample_type & PERF_SAMPLE_USERSPACE_EVENT) {
+		int size = data->user_entry->size;
+		int padding = ALIGN(size, sizeof(u64)) - size;
+
+		perf_output_put(handle, data->user_entry->type);
+		perf_output_put(handle, size);
+		__output_copy(handle, data->user_entry->data, size);
+		perf_output_skip(handle, padding);
+	};
+
 	if (!event->attr.watermark) {
 		int wakeup_events = event->attr.wakeup_events;
 
@@ -4834,6 +4851,24 @@  void perf_prepare_sample(struct perf_event_header *header,
 		data->stack_user_size = stack_size;
 		header->size += size;
 	}
+
+	if (sample_type & PERF_SAMPLE_USERSPACE_EVENT) {
+		int size = data->user_entry->size;
+
+		/*
+		 * Type 0 means zero-terminated string;
+		 * make sure it is terminated
+		 */
+		if (!data->user_entry->type)
+			data->user_entry->data[size - 1] = '\0';
+
+		/*
+		 * The sample consist of 'type' and 'size' u32 fields
+		 * followed with data and padding aligning it to 8 bytes.
+		 */
+		header->size += sizeof(u32) + sizeof(u32) +
+				ALIGN(size, sizeof(u64));
+	}
 }
 
 static void perf_event_output(struct perf_event *event,
@@ -5961,6 +5996,39 @@  static struct pmu perf_swevent = {
 	.event_idx	= perf_swevent_event_idx,
 };
 
+static int perf_sw_userspace_entry(struct perf_event *event,
+	       struct perf_event_userspace __user *arg)
+{
+	u32 size;
+	struct perf_sample_data data;
+	struct pt_regs *regs = current_pt_regs();
+	struct perf_userspace_entry *entry;
+
+	if (!arg)
+		return -EINVAL;
+
+	if (!static_key_false(&perf_swevent_enabled[
+				PERF_COUNT_SW_USERSPACE_EVENT]))
+		return 0;
+
+	BUILD_BUG_ON(sizeof(size) != sizeof(arg->size));
+	if (copy_from_user(&size, &arg->size, sizeof(size)) != 0)
+		return -EFAULT;
+
+	BUILD_BUG_ON(sizeof(*arg) != sizeof(*entry));
+	entry = memdup_user(arg, sizeof(*arg) + size);
+	if (IS_ERR(entry))
+		return PTR_ERR(entry);
+
+	perf_sample_data_init(&data, 0, 0);
+	data.user_entry = entry;
+	perf_event_output(event, &data, regs);
+
+	kfree(entry);
+
+	return 0;
+}
+
 #ifdef CONFIG_EVENT_TRACING
 
 static int perf_tp_filter_match(struct perf_event *event,