linux-kernel - Re: [PATCH v5 31/32] tracing: Convert to printbuf

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]

Date:   Mon, 8 Aug 2022 11:15:31 -0400
From:   Kent Overstreet <kent.overstreet@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        linux-kernel@...r.kernel.org, pmladek@...e.com,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v5 31/32] tracing: Convert to printbuf

On 8/8/22 09:37, Steven Rostedt wrote:
> On Sun, 7 Aug 2022 23:32:01 -0400
> Kent Overstreet <kent.overstreet@...il.com> wrote:
> 
>>> Please remove the two tracing patches and the deletion of the seq_buf from
>>> the series.
>>
>> Well, that's not really an option, as Christoph already (rightly)
>> pointed out.
> 
> These are the last patches of the series. There's no dependency on them.
> You should be able to simply drop them. If others find that these patches
> are worth their while then by all means, let them have them.
> 
>>
>> If you've got actual engineering concerns that you'd care to articulate
>> I'd (still) like to try to work with you - otherwise, I don't think this
>> is something I can accommodate you on.
> 
> Here's my technical reason. These are non trivial changes that are replacing
> code that has been stable for 8 years that the tracing infrastructure
> highly depends on. I do not have the time to sit down and review this code
> as it is not a priority. My time is extremely limited (as my wife keeps
> complaining to me about, as I'm not spending enough time with the family).
> 
> This change is likely to cause subtle regressions for no benefit to the
> tracing subsystem. Hence, when it comes to risk vs reward, I see none.

It sounds like you're saying you don't have time to maintain your 
subsystem..? Is there anyone else actively co-maintaining tracing? Part 
of our jobs is bringing new people in and training them (and not 
providing a hostile work environment so they'll want to), maybe 
something to think about.

I'm also not seeing the likelihood of subtle regressions - this isn't my 
first kernel refactoring and not _nearly_ the biggest or the most 
invasive. There's definitely some stuff in the tracing code code that is 
a bit on the unorthodox side, but nothing too crazy. The code's been in 
my tree for ages where I use tracing on a daily basis, and it passes 
your test suite (and there was just one bug that made it through to be 
caught by the tests, as I mentioned in the cover letter).

Anyways, if you've got specific, actionable concerns, I'll be happy to 
take a look. Otherwise... ¯\_(ツ)_/¯

Cheers