linux-kernel - Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it

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: <20211119175428.2ab95873@rorschach.local.home>
Date:   Fri, 19 Nov 2021 17:54:28 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     jim.cromie@...il.com
Cc:     Jason Baron <jbaron@...mai.com>,
        Pekka Paalanen <ppaalanen@...il.com>,
        Sean Paul <seanpaul@...omium.org>, Sean Paul <sean@...rly.run>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>,
        quic_saipraka@...cinc.com,
        Catalin Marinas <catalin.marinas@....com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Will Deacon <will@...nel.org>, maz@...nel.org,
        amd-gfx mailing list <amd-gfx@...ts.freedesktop.org>,
        Ingo Molnar <mingo@...hat.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Arnd Bergmann <arnd@...db.de>, linux-arm-msm@...r.kernel.org,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        intel-gvt-dev@...ts.freedesktop.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>, quic_psodagud@...cinc.com,
        mathieu.desnoyers@...icios.com
Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with
 it - RFC

On Fri, 19 Nov 2021 15:46:31 -0700
jim.cromie@...il.com wrote:


> > So I could see us supporting subsystem specific trace buffer output
> > via dynamic debug here. We could add new dev_debug() variants that
> > allow say a trace buffer to be supplied. So in that way subsystems
> > could 'opt-out' of having their data put into the global trace buffer.
> > And perhaps some subsystems we would want to allow output to both
> > buffers? The subsystem specific one and the global one?
> >  
> 
>  * trace_array_printk - Print a message to a specific instance
>  * @tr: The instance trace_array descriptor
>  * @ip: The instruction pointer that this is called from.
>  * @fmt: The format to print (printf format)
>  *
> 
> what happens when @tr == NULL ?

It does nothing, but perhaps crash the kernel.

> It could allow up-flow of events to the global instance

Absolutely not!

Then it's just a reimplementation of trace_printk(). Which I refuse to
have.

Nothing should just dump to the main instance. Once we allow that, then
everyone will be dumping there and you will no longer be able to trace
anything because it will be filled with noise.

What is allowed is an event that acts like a trace_printk() but is an
event, which you can turn off (have default off), and even pick which
instance to go to.

> 
> > Thanks,
> >
> > -Jason
> >
> >  
> 
> So I wonder, is there any conceptual utility to this ?
> 
> echo 1 > instances/foo/filter_up  # enable event upflow (or query-time merging?)
> 
> Maybe enabling this causes other files (the ones missing from
> instances/foo) to magically appear
> so all those filtering capacities also appear.


I've been busy doing other things so I haven't been keeping up with
this thread (which I need to go back and read). Perhaps it was already
stated, but I don't know why you want that.

trace-cmd can read several instances (including the top level one) and
interleave them nicely, if that is what you are looking for. So can
KernelShark.

-- Steve