On Wed, Aug 15, 2018 at 12:26 PM Guenter Roeck <linux@xxxxxxxxxxxx> 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
