linux-kernel - Re: the wake-on-lan regression from 6.2 (was: 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] [day] [month] [year] [list]

Date:   Mon, 24 Apr 2023 16:24:41 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux regressions mailing list <regressions@...ts.linux.dev>,
        David Sterba <dsterba@...e.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: the wake-on-lan regression from 6.2 (was: Re: Linux regressions
 report for mainline [2023-04-16])

On Fri, Apr 21, 2023 at 10:45 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Fri, Apr 21, 2023 at 12:22 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > It will get fixed, most likely by reverting the offending commit and
> > most likely during the 6.4 merge window.
>
> No.
>
> It's now reverted in my tree.

Thanks for taking care of this and sorry for the trouble.

I was traveling Fri - Sun and I wouldn't have been able to push the
revert myself before today.

> We're not doing *another* release with this known-broken garbage. It's
> been pending for much too long already.
>
> Known-broken commits either
>
>  (a) get a timely fix that doesn't have other questions
>
> or
>
>  (b) get reverted
>
> Not this kind of "this is broken, has been known to be broken for a
> long time, people have bisected it, and we're just sitting here
> wondering what to do".
>
> > Note that ACPICA is involved, so the analogous revert needs to be
> > submitted there and I'm traveling right now.
>
> No, we're not waiting for "it's broken in the ACPICA tree" and using
> that as an excuse to have a broken kernel.
>
> If the ACPICA tree can't get their act together in two months, that's
> their problem. It does not mean that users should need to suffer known
> issues.

OK, in the future I'll deal with problematic commits coming from
ACPICA more timely without waiting for upstream.