linux-kernel - Re: [PATCH v1] dynamic_debug: add support for logs destination

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:   Tue, 3 Oct 2023 15:58:10 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     jim.cromie@...il.com
Cc:     Łukasz Bartosik <lb@...ihalf.com>,
        Jason Baron <jbaron@...mai.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Douglas Anderson <dianders@...omium.org>,
        Guenter Roeck <groeck@...gle.com>,
        Yaniv Tzoreff <yanivt@...gle.com>,
        Benson Leung <bleung@...gle.com>, linux-kernel@...r.kernel.org,
        upstream@...ihalf.com,
        Vincent Whitchurch <vincent.whitchurch@...s.com>
Subject: Re: [PATCH v1] dynamic_debug: add support for logs destination

On Mon, 2 Oct 2023 14:49:20 -0600
jim.cromie@...il.com wrote:

> hi Lukasz,
> 
> sorry my kernel-time has been in my own trees.
> 
> What I dont understand is why +T is insufficient.
> 
> IIUC, tracefs is intended for production use.
> thats why each event can be enabled / disabled
> - to select and minimize whats traced, and not impact the system
> 
> and +T  can forward all pr_debugs to trace,
> (by 1-few trace events defined similarly to others)
> or very few, giving yet another selection mechanism
> to choose or eliminate specific pr-debugs and reduce traffic to
> interesting stuff.
> 
> Once your debug is in the trace-buf,
> shouldnt user-space be deciding what to do with it ?
> a smart daemon could leverage tracefs to good effect.
> 
> IMO the main value of +T is that it allows feeding existing pr_debugs
> into the place where other trace-data is already integrated and managed.
> 
> At this point, I dont see any extra destination handling as prudent.
> 


I'm fine with either approach. I kind of like the creation of the instance,
as that allows the user to keep this debug separate from other tracing
going on. We are starting to have multiple applications using the tracing
buffer (although most are using instances, which is why I'm trying to make
them lighter weight with the eventfs code).

-- Steve