linux-kernel - [to-be-posted-soon] Multiple handlers per marker

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-next>] [day] [month] [year] [list]

Message-ID: <20071104232442.GA32320@Krystal>
Date:	Sun, 4 Nov 2007 18:24:42 -0500
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	Mike Mason <mmlnx@...ibm.com>
Cc:	ltt-dev@...fik.org, linux-kernel@...r.kernel.org,
	systemtap@...rces.redhat.com
Subject: [to-be-posted-soon] Multiple handlers per marker

* Mathieu Desnoyers (compudj@...stal.dyndns.org) wrote:
> * Mathieu Desnoyers (mathieu.desnoyers@...ymtl.ca) wrote:
> > * Mike Mason (mmlnx@...ibm.com) wrote:
> > > Hi Mathieu,
> > > 
> > > Are you aware of any working being done to allow multiple handlers to be 
> > > attached to a marker?  Something like what kprobes allows.  I've started to 
> > > look into this and don't want to duplicate efforts.
> > > 
> > 
> > Nope, but I know we will have to address this.
> > 
> > Something along the lines of walking an RCU list of function pointers,
> > calling them.
> > 
> > The only downside I see is that we will have to pass a va_list * instead
> > of real va args. The could make the marker site a little bit bigger and
> > will change the probe callback arguments.
> > 
> > What do you think about these ideas ?
> > 
> > If we can find a way to make the common case (only one probe connected)
> > _ultra_ fast, and yet architecture independent, that would be awesome. A
> > simple call is kind of hard to beat though.. So we may have to think
> > about a design with :
> > 
> > - One call at the marker site
> > - if 1 probe is installed :
> >   - If the format string is empty, connect a probe without va args.
> >   - If the format string is not empty, connect a "stage 1" probe that takes
> >     the va args, starts/ends the va_list and calls _one_ function (let's
> >     call it "stage 2" probe), that takes va_list as parameter.
> > - if more than 1 probe is installed :
> >   - The stage 1 probe creates the va_list and passes it to each function
> >     connected, iterated with an RCU list.
> > 
> > What do you think ?
> > 
> > Mathieu
> >
> 
> I'm working on an implementation.
> 

It's ready for testing. Please grab
http://ltt.polymtl.ca/lttng/patch-2.6.24-rc1-git13-lttng-0.10-pre18.tar.bz2
patch name :

markers-support-multiple-probes.patch

It still need to go through patchcheck.pl and some polishing, but it
seems to work fine for me with multiple probes (the sample marker,
sample probe and multiple instances of my lttng probes can
connect/disconnect without problem).

Currently, the "connect/disconnect" and "arm/disarm" operations are
separate. However, they could be merged. Any comment/preference on this?
Being separate, a probe provider can wait until the very last moment
before it activates its markers, with a minimalistic impact on the
system, but it is not such a strong argument.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/