linux-kernel - Re: [PATCH 4.9 000/107] 4.9.120-stable review

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:   Wed, 15 Aug 2018 12:42:27 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     s.gottschall@...wrt.com, Sven Joachim <svenjoac@....de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Shuah Khan <shuah@...nel.org>, patches@...nelci.org,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        lkft-triage@...ts.linaro.org, stable <stable@...r.kernel.org>
Subject: Re: [PATCH 4.9 000/107] 4.9.120-stable review

On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck <linux@...ck-us.net> wrote:
>
> Also seen in mainline. Meaning my non-SMP test builds are broken. Hmm.

Grr. I think it's due mainly due to commit 447ae3166702 ("x86: Don't
include linux/irq.h from asm/hardirq.h"), which exposes a number of
files that had some dodgy include file dependenencies, and just
randomly happened to get it right because of that odd include that
caused problems.

That commit itself is definitely the right thing to do, but yes, we
clearly had a lot of cases of things getting core header files
included purely by luck.

And because this was all done under embargo, we didn't get the kind of
test robot coverage we usually get.

Part of it can also be due to subtle merge issues - even if the
original branch got good coverage, later changes sometimes ended up
adding things like that.

For example, my merge of the L1TF code found that in the meantime,
arch/x86/kernel/kvmclock.c had added a call to kzalloc(), which used
to work just fine, but with the header cleanup it turned out that
kvmclock.c had never included <linux/slab.h>, so now it didn't build
right.

And that was just the one I noticed because of my limited build tests.

And yes, every single developer has CONFIG_SMP in their config, but
perhaps equally importantly, I suspect CONFIG_SMP ends up getting more
header files included almost by mistake, so it can _continue_ to hide
these kinds of incomplete header file includes that just happen to
work.

> Anyway, care to send a proper patch ? I am sure Linus will be more
> than happy to apply it.

I think "happy" is too strong a word for my state of mind with all
this, but yes, I'll apply it, and you'll get the glory of fixing some
configuration that clearly didn't get properly tested.

In the meantime, maybe I should just do a "make allmodconfig" and then
disable SMP and see if that shows anything for me.

              Linus