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]

Date:	Fri, 23 Aug 2013 12:07:47 +0200
From:	Robert Richter <rric@...nel.org>
To:	Vince Weaver <vince@...ter.net>
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,
	Vince Weaver <vincent.weaver@...ne.edu>
Subject: Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to
 control persistency

On 22.08.13 14:18:06, Vince Weaver wrote:
> On Thu, 22 Aug 2013, Robert Richter wrote:
> > This is for Linux man-pages:
> 
> Thanks, though you're missing out by not learning all about troff 
> formatting.

Thanks for documenting perf_event_open(), it's a great help. The troff
thing I may learn in case I write a patch for man-pages. ;)

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

You just *open* an existing persistent event and may access buffers
with mmap(). After opening it you also may attach the event to the
process holding the fd with the ioctl. Then, the event is no longer
persistent and removed after all users finished using the event.
Without doing the attach-ioctl the event stays persistent in the
system.

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

The instance opening the event should also be responsible for removing
it. But there could be a perf tool for controlling persistent events
(create, list, remove, etc).

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

Ah, yes, indeed:

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


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

Thanks for review, Vince.

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