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: <d1b7b62d-bec8-e290-d12c-0b641ab382dd@leemhuis.info>
Date:   Wed, 19 Apr 2023 07:03:31 +0200
From:   "Linux regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Neal Gompa <neal@...pa.dev>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Sterba <dsterba@...e.com>, David Sterba <dsterba@...e.cz>,
        linux-kernel@...r.kernel.org, Rafael Wysocki <rafael@...nel.org>,
        Chris Mason <clm@...a.com>, Boris Burkov <boris@....io>,
        regressions@...ts.linux.dev
Subject: Re: Linux regressions report for mainline [2023-04-16]

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).

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.