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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211112120721.3a4827ce@gandalf.local.home>
Date:   Fri, 12 Nov 2021 12:07:21 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Jason Baron <jbaron@...mai.com>
Cc:     Vincent Whitchurch <vincent.whitchurch@...s.com>,
        Jim Cromie <jim.cromie@...il.com>, gregkh@...uxfoundation.org,
        robdclark@...il.com, sean@...rly.run, daniel.vetter@...ll.ch,
        seanpaul@...omium.org, lyude@...hat.com,
        linux-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
        dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org,
        intel-gvt-dev@...ts.freedesktop.org,
        intel-gfx@...ts.freedesktop.org, quic_saipraka@...cinc.com,
        will@...nel.org, catalin.marinas@....com,
        quic_psodagud@...cinc.com, maz@...nel.org, arnd@...db.de,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, mingo@...hat.com
Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with
 it - RFC

On Fri, 12 Nov 2021 10:08:41 -0500
Jason Baron <jbaron@...mai.com> wrote:

> > A key difference between that patchset and this patch (besides that
> > small fact that I used +x instead of +T) was that my patchset allowed
> > the dyndbg trace to be emitted to the main buffer and did not force them
> > to be in an instance-specific buffer.  
> 
> Yes, I agree I'd prefer that we print here to the 'main' buffer - it seems to keep things simpler and easier to combine the output from different
> sources as you mentioned.

I do not want anything to print to the "main buffer" that can not be
filtered or turned off by the tracing infrastructure itself (aka tracefs
file system).

Once we allow that, then the trace file will become useless because
everything will write to the main buffer and fill it with noise.

Events that can be enabled and disabled from tracefs are fine, as they can
be limited. This is why I added that nasty warning if people leave around
trace_printk(), because it does exactly this (write to the main buffer).
It's fine for debugging a custom kernel, but should never be enabled in
something that is shipped, or part of mainline.

-- Steve