
Surprise?
Evidently Microsoft are exporting their Windows prowess into other parts of the world.
Intel and AMD engineers have stepped in at the eleventh hour to deal with a code contribution from a Microsoft developer that could have broken Linux 6.13 on some systems. The change, made in the autumn, was a useful improvement at face value. It was a modification to Linux x86_64 to use large read-only execute (ROX) pages for …
Linux has a problem with the complexity of the x86_64 hardware ecosystem. Devs well versed in older Intel CPU’s are aging out. Linux devs generally have current hardware, and are not likely to make understanding older Intel CPUs a priority, so it should not be surprising when someone adds something that breaks linux on older systems. This adds to the Linux dev and distro support workloads.
Microsoft has a problem, in the short term, once Win10 in out of support, they will only have to care about X86-64 8th gen or older ;-)
Redhat also has a problem now, but as soon as RHEL 9 is out of support, they only have to care about X-86-64 v3 ...
Ubuntu only cares about X-86-64 even if the debian base still handles X86-32
Something similar happoens in the ARM camp, hardly any distro of Renown runs ARM v7 anymore.
the only way for these behemoths to solve the Architecture complexity puzzle is to leave behind older versions of said architectures
"The behemoths" will never "solve the complexity puzzle", because they do not care to do so.
Creating clean, orthognal architectures is nowhere on their corporate give--a-fuck-about list.
Their priorities, in no particular order which I know about, are speed, features, and minimization of cost-to-build.
Well, this is the strategy, you have your tests in a pipeline, if code passes, code gets released. Then, obviously, a bunch of bugs emerge, these are fixed and tested by the same dev, what could go wrong? Tests are added for regressions. The fixes cause bugs elsewhere, of course, but code passes the pipeline. Start over ...
Few people use the raw Linux kernel - they get them from their kernel distribution and which has undergone more testing and is not bleeding edge.
Of course, I'm the sort that downloads the kernel sources and compiles them myself - something that I've been doing for 20+ years and never a problem. I get the near bleeding edge kernels - ones that have been out a few weeks and have several revisions done to it.
It went through a ton of review. The version that got merged was version 7.
The complaint is that it got merged in the end without "the x86 people" - i.e. AMD's and Intel's kernel folks, mainly Boris and Peter - explicitly approving it.
(I had fun with this one, because it also caused a weird bug where Fedora installs would hit a kernel bug and hang during bootloader install. Took me two weeks to fully investigate and bisect it. Whee. https://bugzilla.kernel.org/show_bug.cgi?id=219554 )
The people developing linux kernel patches at microsoft probably use Windows only to fill the (macro ladden) expense report and time tracking excel files that are feed intro microsoft Dynamics ERP.
Otherwise, they use Linux IDEs to develop for the Linux kernel in linux, just like every other linux dev out there... maybe using WSL2, but linux, nonetheless
Didn't Linus cave to political pressure and fired/removed all (potentially) Russian maintainers?
When you remove maintainers and it isn't for lack of competence, it is to be expected that the code they reviewed will now be reviewed by less competent replacements or not reviewed at all...
This post has been deleted by its author
I'm friends and work with the Microsoft, Intel and AMD engineers. In fact, we're all friends and know each other very well. I've been working with them on the Linux kernel before they were Microsoft, Intel or AMD engineers. Oh, and yes, I work for Google, so you can say I'm one of the enemy too.
The Microsoft engineer just recently started with Microsoft and has been doing kernel development at IBM before that. In fact, this work he's doing was started while he was at IBM. He was also last year's Linux Plumbers Conference Chair which had the largest attendance in its history. Hardly a threat to the Linux kernel community.
I worked with Intel developer when he and I were at Red Hat.
The AMD developer use to work for SUSE.
We all changed companies, but what we work on in the Linux kernel hasn't changed. It's actually rather insulting to a Linux kernel developer to only be associated as an engineer for the company we work for. We do it for the love of the Linux kernel and open source. We are just very lucky that companies want to hire us to work on what we love to work on. I won't turn away a paycheck to do my hobby!
What happened here was that the code in question was brought in by the memory management subsystem without the proper review of the changes done in the x86 subsystem. This happens from time to time as changes like this are large and complex and getting all the right reviews sometimes gets overlooked. But yeah, that happens. Borislov complains quite a bit when an x86 change gets added without the x86 maintainers ACKs. Unfortunately, that's not a rare event.
Anyway, my point is mentioning Microsoft is just a way to get clicks, and have those that don't know any better come up with conspiracy theores that Microsoft is trying to sabatoge Linux. What is really happening is normal kernel development and this really wasn't a big deal.
Mentioning where a kernel developer works, submitting patches as part of their job, and causing an issue, isn't for clicks, it's reporting on reality IMO. You might not think it's a fairly big deal; we do.
I think this quote from an AMD person sums it up:
"I just love it how this went in without a single x86 maintainer ack, it broke a bunch of things and then it is still there instead of getting reverted. Let's not do this again please."
C.
And that same AMD developer was Cc'd on every version of the patch set. Including the one that introduced the bug back in October. He had all this time to review it. Why didn't he?
Andrew Morton is one of the major kernel developers and maintainer of the memory management subsystem. After a time a patch is ignored by subsystem maintainers, he will pull in the patch and push it off to Linus. That is usually what it takes to get a review.