Linux kernel supremo Linus Torvalds has taken the rare step of reverting a kernel release candidate – after it went sour.
All looked sunny enough on Sunday evening, when he set Linux 4.18-rc7 free to roam: “Unless something odd happens, this should be the last rc for 4.18,” the chief penguinista wrote. Something odd did, indeed, happen, and after nearly two days of discussion on the Linux Kernel Mailing List, Torvalds made the decision to revert:
I think I'll do an rc8 with the revert, just so that we'll have some time to figure this out. It's only Tuesday, but I already have 90 commits since rc7, so this isn't the only issue we're having.
I _prefer_ just the regular cadence of releases, but when I have a reason to delay, I'll delay.
El Reg took a backwards walk through the mailing list to work out what went wrong – or rather, what primarily went wrong, since there are so many commits since the previous release candidate.
One large headache involves
ashmem, an application-level virtual memory area type introduced to the Linux kernel to solve a problem arising from Android's security paranoia.
Android lacks a writable tmpfs temporarily file system, to prevent malicious applications doing naughty or messy stuff in
ashmem was created to let apps “obtain memory that can be shared with peer processes without creating resource leaks.” In other words,
ashmem can be used by programs to share information without having to go through a temporary file system, and only when there is no big pressure for free memory.
Then it emerged that the open-source flavor of Android would suffer a “userspace crash with v4.18-rc7”, and not on rc6, due to changes to the memory management code involving
vma->vm_ops = &dummy_vm_ops from
vma_init() stopped the crashes.
That confirmation led to this longish post from Torvalds, in which he considered pulling rc7. Here's the key part of Torvalds' thinking:
Honestly, by now we just need to revert that commit.
It's not even clear that it was a good idea to begin with. The rest of the commits were cleanups, this one was driven by a incorrect VM_BUG_ON() that triggered, and that checked "vma_is_anonymous(vma)" without any explanations of wht it should matter.
I think the biggest problem with vma_is_anonymous() may be its name, not what it does.
What the code historically *did* (and what vma_is_anonymous() checks) is not "is this anonymous", but rather "does this have any special operations associated with it".
In the end, it wasn't just this
vma_is_anonymous() issue giving Linus cause to pause, and so now there's going to be another release candidate before Linux 4.18 lands. ®