linux-kernel - Re: Linux regressions report for mainline [2023-04-16]

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: <20230420192156.GY19619@suse.cz>
Date:   Thu, 20 Apr 2023 21:21:56 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Linux regressions mailing list <regressions@...ts.linux.dev>
Cc:     Neal Gompa <neal@...pa.dev>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        David Sterba <dsterba@...e.com>, linux-kernel@...r.kernel.org,
        Rafael Wysocki <rafael@...nel.org>, Chris Mason <clm@...a.com>,
        Boris Burkov <boris@....io>
Subject: Re: Linux regressions report for mainline [2023-04-16]

On Wed, Apr 19, 2023 at 07:03:31AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 18.04.23 23:32, Neal Gompa wrote:
> > 
> > I'm the guy that sort of kickstarted this whole thing a year ago.
> >>From my perspective in Fedora-land, we've been running automatic
> > weekly fstrim on every Fedora system for three years now[1] and
> > have not received any complaints about SSDs pushing daises from
> > that.
> > 
> > When we started discussing btrfs discard=async within Fedora
> > two years ago[2], I started soliciting feedback and information
> > from the Btrfs developers I was regularly working with at the time.
> > 
> > Last year, I had a face-to-face with Chris Mason and we discussed
> > the idea in depth and decided to go for this, based on both Fedora's
> > data with consumer disks and Facebook's data with their datacenters.
> > 
> > The only real surprise we had was the so-called "discard storm",
> > which Boris Burkov made adjustments to resolve a couple weeks ago[3].
> > [...]
> > [3]: https://lore.kernel.org/linux-btrfs/cover.1680723651.git.boris@bur.io/T/#t
> 
> Wait, what? Argh. Sorry, if I had seen that patch, I wouldn't have
> brought this up in my report at all. I missed it, as I wasn't CCed; and
> regzbot missed it, because the patch uses a odd format for the lore link
> (but not totally uncommon, will change regzbot to ensure that doesn't
> happen again).

I'd need pay more attention when the regression tracking process is
involved in case there are more patch versions floating around. People
usually don't "CC enough" so that you have the regzbot in place helps
to track the state.

> Ciao, Thorsten
> 
> P.S.: /me meanwhile yet again wonders if we should tell people to add a
> "CC: <regressions@...ts.linux.dev>" on patches fixing regressions. Then
> in this case I would have become aware of the patch. And it makes it
> obvious for anybody handling patches that the patch is fixing a
> regression. But whatever, might not be worth it.

I'm not sure if it would fit how regzbot workflow works, but syzbot
provides links with the reports and then changes the state when the
patch is committed containing the links. I don't see anything similar in
the process/handling-regression document. If the "Link: <report>" is
sufficient then it should work already but there's no guarantee that the
submitted patches would contain that. I add links to the committed
versions but then you'd need to scan at least linux-next. In any case
with the regzbot it's fixable.