linux-kernel - Re: [PATCH] tracing: Allow for max buffer data size trace

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:   Sun, 10 Dec 2023 12:59:08 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] tracing: Allow for max buffer data size trace_marker
 writes

On Sun, 10 Dec 2023 12:28:32 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> > Again, it's not a requirement, it's just an enhancement.  
> 
> How does this have anything to do with dispensing from testing the
> new behavior ? If the new behavior has a bug that causes it to
> silently truncate the trace marker payloads, how do you catch it
> with the current tests ?

I'm not disagreeing with you, but honestly, writing tests that can be
submitted, take up time I simply do not have. So it's either I get this
working and manually test it, or not apply it at all. This was a simple
change which is why I added it. The tests will take much longer to
write than the enhancement itself.

If someone wants to submit patches that test this further, I'd be more
than happy to apply them!

It may be several more months before I get the time to work on this any
further, and there's still several other features that are in my queue
to apply, where some of them will be affected by these changes.

Right now I'm just focused on that any of these changes do not cause
regressions in the workflow that others have. The trace_marker usage
that I've ever seen has been simple writes that are never more than a
couple of hundred bytes. The main reason I added this change was to
be able to test the subbuffer change. Otherwise I would never had made
this change.

Adding more tests is on my todo list, and not just for this, but for
other features. I do have a bunch of tests I run locally that are not
upsteam, but they are mostly hacks that require a lot of clean up
before being added to selftests.

-- Steve