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-next>] [day] [month] [year] [list]
Date:   Wed, 21 Sep 2022 08:53:39 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Joerg Roedel <joro@...tes.org>,
        Lu Baolu <baolu.lu@...ux.intel.com>, iommu@...ts.linux.dev,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Sasha Levin <sashal@...nel.org>
Subject: Getting the regression

Hi Greg! As you likely heard already, 5.19.9 introduced a regression
that breaks Thunderbolt and USB-C docks (and apparently Wifi in some
cases as well) on quite a few (many?) modern systems. It's one of those
problems where I think "hey, we ideally should fix this in stable as
fast as possible" we briefly talked about last week on the LPC hallways.
That made me wonder how to actually archive that in this particular case
while keeping all involved parties happy and not skipping any CI testing
queues considered important.

FWIW, here are a few few reports about the issue (I assume there are
some for Arch Linux and openSUSE Tumbleweed as well, but didn't check).

https://lore.kernel.org/linux-iommu/485A6EA5-6D58-42EA-B298-8571E97422DE@getmailspring.com/
https://bugzilla.kernel.org/show_bug.cgi?id=216497
https://bugzilla.redhat.com/show_bug.cgi?id=2128458
https://bugzilla.redhat.com/show_bug.cgi?id=2127753

A revert of the culprit (9cd4f1434479f ("iommu/vt-d: Fix possible
recursive locking in intel_iommu_init()"); in 5.19.y it's 	9516acba29e3)
for mainline is here:
https://lore.kernel.org/lkml/20220920081701.3453504-1-baolu.lu@linux.intel.com/

A few hours ago the revert was queued to get send to Joerg:
https://lore.kernel.org/linux-iommu/20220921024054.3570256-1-baolu.lu@linux.intel.com/

I fear it could easily take another week to get this fixed in stable
depending on how fast the patch makes it to mainline and the timing of
the next 5.19.y release and its -rc phase. That to me sounds like way
too long for a problem like this that apparently plagues quite a few
people.

That made me wonder: would you in cases like this be willing to start
the -rc phase for a interim 5.19.y release with just that revert while
it's still heading towards mainline? Then the CI systems that test
stable -rcs could chew on things already; and the new stable release
could go out right after the revert landed in mainline (unless the
testing finds any problems, of course).

Ciao, Thorsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ