linux-kernel - Re: [PATCH 14/14] ringbuffer/selftest: Add basic selftest to test chaning subbuf order

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] [day] [month] [year] [list]

Message-ID: <20231210104436.00d94363@gandalf.local.home>
Date:   Sun, 10 Dec 2023 10:44:36 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Tzvetomir Stoyanov <tz.stoyanov@...il.com>,
        Vincent Donnefort <vdonnefort@...gle.com>,
        Kent Overstreet <kent.overstreet@...il.com>
Subject: Re: [PATCH 14/14] ringbuffer/selftest: Add basic selftest to test
 chaning subbuf order

On Sun, 10 Dec 2023 09:26:13 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> This test has no clue if the record was truncated or not.
> 
> It basically repeats the string
> 
> "1234567890" until it fills the subbuffer size and pads with
> XXXX as needed as trace marker payload, but the grep looks for the
> "1234567890" pattern only.
> 
> The test should be extended to validate whether the trace marker
> payload was truncated or not, otherwise it is of limited value.

It can be, but for now it's just testing to make sure it doesn't crash. I
ran out of time, and if someone else wants to extend this, go ahead.
Currently, my testing has been just manual observations. I threw this in
just to have some kind of smoke test applied.

I agree with the API changes, and will update that. But given that this has
been two years and never applied, is because nobody has the time to work on
this. The reason I'm pushing for this now, is because Kent hit the limit in
his work. Knowing that he would not have hit this limit if these patches
were applied, I feel more urgency on getting them in. But this is all on my
own time, not part of my Employer (hence why I'm working on the weekend).

-- Steve