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]
Date:   Mon, 12 Sep 2022 10:23:42 -0700
From:   Olof Johansson <olof@...om.net>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Saravana Kannan <saravanak@...gle.com>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Shawn Guo <shawnguo@...nel.org>, Li Yang <leoyang.li@....com>
Subject: Re: [GIT PULL] Driver core changes for 6.0-rc1

Hi,

On Wed, Aug 3, 2022 at 7:16 AM Greg KH <gregkh@...uxfoundation.org> wrote:

> Saravana Kannan (11):
>       PM: domains: Delete usage of driver_deferred_probe_check_state()
>       pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state()
>       net: mdio: Delete usage of driver_deferred_probe_check_state()
>       driver core: Add wait_for_init_devices_probe helper function
>       net: ipconfig: Relax fw_devlink if we need to mount a network rootfs
>       Revert "driver core: Set default deferred_probe_timeout back to 0."
>       driver core: Set fw_devlink.strict=1 by default
>       iommu/of: Delete usage of driver_deferred_probe_check_state()
>       driver core: Delete driver_deferred_probe_check_state()
>       driver core: fw_devlink: Allow firmware to mark devices as best effort
>       of: base: Avoid console probe delay when fw_devlink.strict=1

The last patch in this list regresses my HoneyComb LX2K (ironically
the machine I do maintainer work on). It stops PCIe from probing, but
without a single message indicating why.

The reason seems to be that the iommu-maps property doesn't get
patched up by my (older) u-boot, and thus isn't a valid reference.
System works fine without IOMMU, which is how I've ran it for a couple
of years.

It's also extremely hard to diagnose out of the box because there are
*no error messages*. And there were no warnings leading up to this
strict enforcement.

This "feature" seems to have been done backwards. The checks should
have been running (and not skipped due to the "optional" flag), but
also not causing errors, just warnings. That would have given users a
chance to know that this is something that needs to be fixed.

And when you flip the switch, at least report what failed so that
people don't need to spend a whole night bisecting kernels, please.

Greg, mind reverting just the last one? If I hit this, I presume
others would too.


-Olof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ