Kernel 4.14.87 compiled

I was attempting to do a frugal install on the Mele PCG35 Apo mini-PC, with the boot-partition in the internal drive, and the working-partition on a plugin SD-card. However, the kernel does not recognise the Realtek card-reader at early bootup, as the drivers for it are modules. So, compiling the latest 4.14.*, with those drivers builtin. These are the changes since 4.14.81:

Device Drivers
  Multifunction device drivers
    <*> Realtek USB card reader                   CONFIG_MFD_RTXS_USB
  <*> MMC/SD/SDIO card support
    <*> Realtek USB SD/MMC card interface driver  CONFIG_MMC_REALTEK_USB

This was enabled, disabled it:

Processor type and features
 < > Avoid speculative indirect branches in kernel CONFIG_RETPOLINE

...that last one, of course, is controversial. However, I have never configured a kernel with hyperthreading enabled, except that it now is. That is, I always had CONFIG_SMP enabled, but not CONFIG_SCHED_SMT -- however, after compiling this kernel, I discovered that CONFIG_SCHED_SMT has become enabled -- huh, that is sneaky, I always use the .config file from the previous compile, so somewhere recently, the kernel developers have chosen to over-rule me.

Looked, CONFIG_SCHED_SMT was not enabled in the 4.14.81 compile. So they have done it in a more recent kernel. Cr*p, now will have to recompile it. 

Note, way back in the early days when I was first compiling the kernel for multi-core CPUs, SMT (hyperthreading), which simulates more than one core for each actual core, was causing file corruption. So, disabled it, and never trusted it after that. 

EDIT 2018-12-10
OK, I found the retpoline patch was introduced in 4.14.82, and using the .config from 4.14.81, was able to configure with retpoline disabled, and also SMT disabled. Fine, so using that kernel now.

Took another look at the 4.14.87 kernel, wondering why SMT was forced enabled. I found out why:

Processor type and features
  [ ] SMT (hyperthreading) scheduler support

...is missing!!! Yep, not there. Has it been moved? Hunted around, couldn't find it. So, for now, staying with 4.14.82. 

EDIT 2018-12-16
Kernel 4.14.88 came out, and I discovered CONFIG_SCHED_SMT is still forced on, so looked back through the kernel changelog, and found that it is deliberate. I have sent an email to the guy to contributed the patch, and cc'ed all of those who signed-off on it. This is the email:

Mr Gleixner,
I was upset when I compiled 4.14.87 found that SCHED_SMT had been forced on. At the time, I just reported it to my blog, and posted a question about it to a couple of forums, and stayed with an earlier kernel.

However, when 4.14.88 came out, and still the same situation, alarm bells went off, and I looked through the kernel changelog. Found it, 4.14.86:

"x86/Kconfig: Select SCHED_SMT if SMP enabled"

Then:

"CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to
    have it configurable. ..."

...that is a lie. It would be correct to state that is true of the distros you use, and presumably also for all of you guys who signed off on it.

Puppy Linux is an example of a distro that has mostly not had SCHED_SMT enabled. Ditto for most of the forks of Puppy. Two distros that I currently maintain, Quirky and EasyOS (easyos.org) have SMP enabled but not SCHED_SMT.

The difference between them is important, they should remain independently settable. I am so surprised that all of you guys went along with forcing it on.

For the record, my blog post:

http://bkhome.org/news/201812/kernel-41487-compiled.html

Regards,
Barry Kauler

The kernel changelog is here:

https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.86  

If you would like to provide some input, there is a forum thread here:

http://murga-linux.com/puppy/viewtopic.php?t=114921 

EDIT 2018-12-17
I had another feedback, one of the kernel developers has informed me that the retpoline security threat is not just when CONFIG_SCHED_SMT is enabled, it may also be a threat when disabled.

That changes things. It seems that my understanding was too simplistic.

So, might just give in, and go along with what the kernel developers have decided. Don't have a choice anyway.

It is disconcerting though, when a kernel configure option suddenly disappears, and the explanation doesn't definitively justify it's removal.

I still have suspicions about enabling SCHED_SMT, from way back in the "early days" when I experienced file corruption, but it seems whatever that problem was, it has long ago been fixed.

Thus ends my little session of annoying the kernel developers! 

Tags: easy