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:   Fri, 7 Oct 2022 11:45:27 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Lee Jones <lee@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Backlight for v6.1

On Fri, Oct 7, 2022 at 6:16 AM Lee Jones <lee@...nel.org> wrote:
>
> PR satisfying this dependency was submitted the following day:

.. you ignored the whole "another driver hit v6.0 without ever getting
the dependency".

So this whole thing with "dead driver because the config option it
depended on didn't even exist" wasn't some little temporary thing.
It's literally there in a released kernel, which has a whole driver in
it that cannot actually even be enabled.

And now that I *did* get the MFD update, I notice that the build
coverage of *that* is pitiful too.

In particular, there was a silent semantic conflict in the Crystal
Cove (intel PMIC) driver with the i2c changes. I noticed it because
there were other things going on, and I went and looked.

But most notably I *didn't* notice it due to any build coverage,
because the Kconfig for that thing seems designed to hide the driver.
It does have

        depends on (X86 && ACPI) || COMPILE_TEST

so that it *looks* like it should get compile test coverage even
outside of x86, but in reality,  even on x86 it's actually really hard
to test, because it also has

        depends on I2C_DESIGNWARE_PLATFORM=y

so if you do a regular "allmodconfig" build, that driver doesn't
actually get any build testing at all, because while that platform is
indeed enabled, it's only a module.

So I caught this particular issue, but I really think that code that
cannot be enabled at all even for build testing - or code that is
quite hard to enable either intentionally or by mistake - is a
problem. And right now MFD was involved in both of the issues I've
noticed this merge window.

That's not a great look.

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ