linux-kernel - Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to control persistency

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: <alpine.DEB.2.02.1308221404090.26486@pianoman.cluster.toy>
Date:	Thu, 22 Aug 2013 14:18:06 -0400 (EDT)
From:	Vince Weaver <vince@...ter.net>
To:	Robert Richter <rric@...nel.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...hat.com>,
	linux-kernel@...r.kernel.org,
	Robert Richter <robert.richter@...aro.org>,
	Vince Weaver <vincent.weaver@...ne.edu>
Subject: Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to
 control persistency

On Thu, 22 Aug 2013, Robert Richter wrote:

> From: Robert Richter <robert.richter@...aro.org>
> 
> Implementing ioctl functions to control persistent events. There are
> functions to detach or attach an event to or from a process. The
> PERF_EVENT_IOC_DETACH ioctl call makes an event persistent. After
> closing the event's fd it runs then in the background of the system
> without the need of a controlling process. The perf_event_open()
> syscall can be used to reopen the event by any process. The
> PERF_EVENT_IOC_ATTACH ioctl attaches the event again so that it is
> removed after closing the event's fd.


> PERF_EVENT_IOC_ATTACH (Since Linux 3.xx)
> PERF_EVENT_IOC_DETACH (Since Linux 3.xx)

I think these aren't very good names for the ioctls.  Maybe something
like
  PERF_EVENT_IOC_MAKE_PERSISTENT
  PERF_EVENT_IOC_UNPERSIST
I know that last one's not a real word but I can't think of what the 
proper term would be.  Maybe
  PERF_EVENT_IOC_RELEASE_PERSISTENT
  PERF_EVENT_IOC_RECLAIM_PERSISTENT

> This is for Linux man-pages:

Thanks, though you're missing out by not learning all about troff 
formatting.

>     type ...
> 
>         PERF_TYPE_PERSISTENT (Since Linux 3.xx)
> 
>             This indicates a persistent event. There is a unique
>             identifier for each persistent event that needs to be
>             specified in the event's attribute config field.
>             Persistent events are listed under:
> 
>               /sys/bus/event_source/devices/persistent/

Wait, so the first time you create a persistent event you do *not*
set type PERF_TYPE_PERSISTENT?  You only do that if you're
"attaching" to an exisiting event?  You might want to clarify that.

>     persistent: (Since Linux 3.xx)
> 
>         Put event into persistent state after opening. After closing
>         the event's fd the event is persistent in the system and
>         continues to run.

will there be some sort of tool that will let you kill runaway persistent 
events?  Or will you have to manually perf_event_open() / iotcl() them
by hand somehow?

>         PERF_EVENT_IOC_DETACH (Since Linux 3.xx)
> 
>             Detach the event specified by the file descriptor from the
>             process and make it persistent in the system. After
>             closing the fd the event will continue to run. An unique
>             identifier for the persistent event is returned or an
>             error otherwise. The following allows to connect to the
>             event again:

You might want to re-order things so it's clear you get the unique ID
at ioctl time and not after the close happens.

>         PERF_EVENT_IOC_ATTACH (Since Linux 3.xx)
> 
>             Attach the event specified by the file descriptor to the
>             current process. The event is no longer persistent in the
>             system and will be removed after all users disconnected
>             from the event. Thus, if there are no other users the
>             event will be closed too after closing its file
>             descriptor, the event then no longer exists.

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/