linux-kernel - Re: Dynamic tracepoints in 4.11.8-rt5

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

Date:   Wed, 12 Jul 2017 11:42:53 -0500
From:   Tom Zanussi <tom.zanussi@...ux.intel.com>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        rostedt <rostedt@...dmis.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Michael Jeanson <mjeanson@...icios.com>
Subject: Re: Dynamic tracepoints in 4.11.8-rt5

Hi Mathieu,

On Wed, 2017-07-12 at 15:56 +0000, Mathieu Desnoyers wrote:
> Hi Tom,
> 
> I notice this commit appears in linux-rt-devel 4.11.8-rt5
> (and it is not in upstream Linux):
> 
> 003100371 tracing: Add support for dynamic tracepoints
> 
> It adds a "bool dynamic" argument to tracepoint_probe_unregister.
> 
> I'm trying to figure out why this change is introduced as a new API
> "dynamic_tracepoint_probe_register()" and by adding a boolean
> to tracepoint_probe_unregister().
> 
> Allowing the user of register API to mixup between dynamic
> and non-dynamic boolean values for the same tracepoint instance
> seems fragile.
> 
> Given that the "dynamic" nature of this new kind of tracepoint
> appears to be associated with the tracepoint instance
> (struct tracepoint), why can't we simply add a "bool dynamic"
> field to struct tracepoint, so we can deal with this internally
> within tracepoint.c without exposing this detail in the register
> API ?
> 

Yeah, I think that should work - I'm working on an update to these
patches and will make that change.

Thanks,

Tom 

> This would also take care of currently diverging module APIs for the
> GPL-exported symbol tracepoint_unregister() between Linux upstream
> and linux-rt.
> 
> Thanks,
> 
> Mathieu
>