linux-kernel - Re: Linux regressions report for mainline [2023-10-29]

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: <CAAhV-H4DXYm+nEV8zrfMMPvqstHV+FsQaFB8s1_rNu_ENC-q7g@mail.gmail.com>
Date:   Mon, 30 Oct 2023 10:18:14 +0800
From:   Huacai Chen <chenhuacai@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Regzbot (on behalf of Thorsten Leemhuis)" 
        <regressions@...mhuis.info>,
        Javier Martinez Canillas <javierm@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>
Subject: Re: Linux regressions report for mainline [2023-10-29]

Hi, Linus,

On Mon, Oct 30, 2023 at 1:19 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, 29 Oct 2023 at 03:52, Regzbot (on behalf of Thorsten Leemhuis)
> <regressions@...mhuis.info> wrote:
> >
> >                          One of the remaining ones is new:
> > module loading trouble on some laptops. Not nice, but likely nothing
> > many users will encounter. The quota compilation oddity problem from
> > Andy is also still around (unless it was fixed without me noticing); and
> > a memleak, too.
>
> The quota thing remains unexplained, and honestly seems like a timing
> issue that just happens to hit Andy. Very strange, but I suspect that
> without more reports (that may or may not ever happen), we're stuck.
>
> > * There was another report about a blank screen during boot on a Lenovo
> > laptop because simpledrm (that users apparently had enabled without
> > problems beforehand) started to support those machines due to
> > 60aebc9559492c ("drivers/firmware: Move sysfb_init() from
> > device_initcall to subsys_initcall_sync"). I suggested a revert, but the
> > developers disagree (to quote: "From my point of view, this is not a
> > regression, 60aebc9559492c doesn't cause a problem, but exposes a
> > problem.")
>
> Honestly, "exposes a problem" is pretty much the *definition* of a
> regression. So that excuse is particularly bad.
>
> The whole point of "regression" is "things that used to work no longer work".
>
> And no, "there's another bug that needs to be fixed" is _not_ the
> answer - not unless you have that fix in hand.
>
> That said, this already went into 6.5, so I'm not going to revert it
> now just before the 6.6 release. That would be more dangerous than
> just letting things be. But yes, a revert is likely the right thing to
> do, unless people have figured out what is wrong with simplefb.

We are investigating and hope the simpledrm problem can be fixed in
some days [1], and the blank screen seems not a very harmful problem
(maybe I'm wrong but I think most of people are using GUI now). So,
can we keep the commit 60aebc9559492c at this time?

[1] https://lore.kernel.org/dri-devel/CAAhV-H7UTnTWQeT_qo7VgBczaZo37zjosREr16H8DsLi21XPqQ@mail.gmail.com/T/#t

Huacai

>
>                  Linus