back to article Intel, AMD engineers rush to save Linux 6.13 after dodgy Microsoft code change

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 …

  1. Yorick Hunt Silver badge
    Mushroom

    Surprise?

    Evidently Microsoft are exporting their Windows prowess into other parts of the world.

    1. Anonymous Custard Silver badge
      Alien

      Re: Surprise?

      All your kernels are belong to us...

      1. Anonymous Coward
        Anonymous Coward

        Re: Surprise?

        So, was it the author of PulseAudio?

        1. Ropewash

          Re: Surprise?

          Poettering does work for Microsoft, so not entirely impossible.

          1. Will Godfrey Silver badge
            Coat

            Re: Surprise?

            What Poettering does begins with a 'w' and ends with a 'k' but the other letters are not 'o' and 'r'.

  2. gnwiii

    Intel x86_64 is part of the problem

    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.

    1. Tom Chiverton 1 Silver badge

      Re: Intel x86_64 is part of the problem

      It is surprising when it skips all review and checks and just lands and ships though.

      Did we lean nothing from xz ?

      1. drankinatty

        Re: Intel x86_64 is part of the problem

        Let us hope the commit wasn't signed by Jia Tan....

    2. bill 27

      Re: Intel x86_64 is part of the problem

      Not to be to picky about it...But it sounds like Windows also "has a problem with the complexity of the x86_64 hardware ecosystem".

      1. williamyf Bronze badge

        Re: Intel x86_64 is part of the problem

        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

        1. An_Old_Dog Silver badge

          Re: Intel x86_64 is part of the problem

          "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.

    3. Anonymous Coward
      Anonymous Coward

      Re: Intel x86_64 is part of the problem

      And, surely, this is why testing exists...

      1. TReko Silver badge

        Re: Intel x86_64 is part of the problem

        Yes, but some MBA at Microsoft fired most of their human testers almost a decade ago to save money.

        Now their end users who do the testing, every patch Tuesday.

        1. Hans 1

          Re: Intel x86_64 is part of the problem

          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 ...

  3. fishman

    Few people use the raw Kernel.

    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.

  4. wolfetone Silver badge
    Coat

    Well none of the Microsoft guys are going to be getting the guitar pedal.

    1. David 132 Silver badge

      A sad trombone, more like.

      1. Anonymous Coward
        Anonymous Coward

        Allo, allo, je vois que tu are trying to write a comment - voudrais- tu some help ?

        "trombone' in French is colloquially used to mean paper clip .... apologies also due to the late Miles Kington

        1. Roland6 Silver badge

          Adds a whole new dimension to Clippy…

  5. Snowy Silver badge
    Facepalm

    Extra checks please!!!

    On Microsoft submissions given "Microsoft is notable for dubious quality control standards regarding releases of its flagship operating system, Windows."

    1. druck Silver badge

      Re: Extra checks please!!!

      Or just don't allow anyone tainted by SatNad's growth cult anywhere near Linux.

  6. dangerous race
    Mushroom

    Considering how Microsoft engineers bork the Microsoft Windows OS, why on earth isn't code from MS engineers peer reviewed and then reviewed again? Jesus H Christ, no code from MS should be taken at face value. MS has form.

    1. klh

      No code ever should be merged without review, I wonder how that even happened? I thought Linux had a pretty strict review mechanism.

      1. Jonathon Green

        My guess would be that it was reviewed, but not by the right people…

        1. PhilBuk

          By Boeing?

          1. Anonymous Coward
            Anonymous Coward

            When it comes to Windows, Boeing have previous when it comes to dropped frames

        2. AdamWill

          it *was* reviewed, but...

          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 )

      2. Rattus

        To you and everyone else who has commented on there needing more testing and code review, there is only one response I can think of...

        "Thank you for volunteering"

        seriously, please consider it.

        /Rattus

    2. williamyf Bronze badge

      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

      1. Anonymous Coward
        Anonymous Coward

        ".... the people developing linux kernel patches at microsoft"

        Embrace, extend, extinguish -people, you mean.

        MS has only one goal and that's to sabotage Linux, by whatever means. Pöttering is one of the biggest tools, but intentionally breaking the kernel is a good second.

        1. John Brown (no body) Silver badge

          "Pöttering is one of the biggest tools"

          True :-)

  7. Jou (Mxyzptlk) Silver badge

    They are not locked out as yet?

    Considering the abysmal quality of 24h2 it is not surprise some of it leaked over to Linux.

    **sigh** and I still have no alternative, including in my private area, to replace. Simply does not make sense

    1. Roland6 Silver badge

      Re: They are not locked out as yet?

      Additionally, they can’t say the reason for skipping Windows testing is because of all the effort they are putting into Open Source…

  8. Anonymous Coward
    Anonymous Coward

    FAFO

    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...

    1. This post has been deleted by its author

  9. Mage Silver badge
    Windows

    So...

    Incompetence rather than sabotage.

    1. ecofeco Silver badge

      Re: So...

      Yes. Typical Microsoft.

    2. m4r35n357 Silver badge

      Re: So...

      Sabotage by incompetence

      1. Anonymous Coward
        Anonymous Coward

        Re: So...

        "Sabotage by incompetence"

        Remember Nokia? Same thing. *Not* an accident.

  10. Kev99 Silver badge

    You sure it was an "accident" the mictosoft code caused big problems in the Linux kernel?

    1. IGotOut Silver badge

      Given the huge amounts of vide MS submit, I think it's pretty safe to say it was a cockup

  11. rostedt

    This has nothing to do with Microsoft or Intel or AMD

    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.

    1. diodesign (Written by Reg staff) Silver badge

      Nothing to do with clicks, either

      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.

      1. rostedt

        Re: Nothing to do with clicks, either

        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.

        1. diodesign (Written by Reg staff) Silver badge

          "He had all this time to review it. Why didn't he?"

          Good question! Maybe we should look into and describe how the kernel development process works in an article this year.

          C.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like