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