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]

Message-ID: <CAJfuBxyJyFbFEhRxrtxJ_RazaTODV6Gg64b1aiNEzt6_iE4=Og@mail.gmail.com>
Date:   Tue, 3 Oct 2023 14:53:47 -0600
From:   jim.cromie@...il.com
To:     Steven Rostedt <rostedt@...dmis.org>
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 Tue, Oct 3, 2023 at 1:57 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 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
>


Ok Im starting to grasp that multiple instances are good
(and wondering how I didnt notice)

What doesnt thrill me is the new _ddebug field, it enlarges the footprint.

can you make it go away ?
I have some thoughts ..