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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130827122242.GA5855@x1.alien8.de>
Date:	Tue, 27 Aug 2013 14:22:42 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Robert Richter <rric@...nel.org>
Cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to
 control persistency

On Tue, Aug 27, 2013 at 01:54:22PM +0200, Robert Richter wrote:
> I got another idea for this, what about UNCLAIM and CLAIM? It is
> exactly, what it is. A process unclaims an event telling it doesn't
> care anymore.  Another process comes and claims the event, meaning the
> process wants the event no longer to be shared with others and being
> released after closing.

This still doesn't pan out because with claiming the event, you state
that the event is *owned* by this process but with persistent events
we want to be able to state that they can have multiple users and thus
multiple buffer consumers, concurrently.

> > > 3. ioctl DETACH from it so that it is "forked in the background" so to
> > > speak, very similar to a background job in the shell.
> 
> With 'detach' we move the event into the 'background' so that it is
> still available after opening.

Ok, maybe ATTACH/DETACH is not the perfect naming for this after all.
Maybe when we want to state the fact that the event is going to continue
existing after closing the buffer consumer, we want to do ioctl(event,
DONT_DESTROY) and when we want to actually get rid of it, one of the
process does ioctl(event, DESTROY).

Which reminds me, what do we do when one process destroys the event but
there are other consumers accessing it concurrently? Refcounting?

Thanks.

-- 
Regards/Gruss,
Boris.
--
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/