Announcement

Collapse
No announcement yet.

Linux's Performance-Boosting FSGSBASE Support Dropped For Now Over Serious Bugs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by AsuMagic View Post
    Please provide a single example that proves your point for anything intel open source.
    Where did I say that it had to do with open source? There's really no excuse to behave as badly or worse than Monsanto.

    As for what I'm referring to is how they used frivolous lawsuits against competitors like Cyrix and AMD in the 1990s to cost them money and drive away their customers, how they extorted and bribed hardware vendors not to use AMD chips in the mid 2000s, how they're trying to avoid paying the fines for that and more recently how they've returned to the same practices to prevent AMD from particularly breaking their dominance in the server market.
    "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

    Comment


    • #12
      Originally posted by AsuMagic View Post
      Sounds like the one to blame is the maintainer who merged this, honestly.
      When Linus rants about code quality, he's generally flaming the maintainers at least as much as the ones who wrote the code. Just saying.
      But yeah, better go into conspiracies (EMHARGGD WAT IF INTEL PURPOSEFULI PUT A BAD DEVELOPR FOR LINUX TO SABOTAEG???) and personally insult people (because this is known to make you a better person).
      Nice try lameboy:

      https://lkml.org/lkml/2019/3/26/719


      You have a track record of not caring much about either of these, but I
      very much care for good reasons. I've been bitten by glued on and half
      baked patches from Intel in the past 10 years so many times, that I'm
      simply refusing to take anything which is not properly structured and
      documented.

      .......................


      Especially not when it is touching sensitive areas like this and also has
      an impact on the user space ABI.

      Care to look at the real history of this:

      11/2015: First patch-set posted by you, which was rejected on technical grounds

      So this so important feature was in limbo for 20 months until Luto picked it
      up again. That's surely the fault of the x86 maintainers, right?

      07/2017: Discussion about ABI considerations initiated by Andy Lutomirksi.

      And it takes another 8 month until patches come around:

      03/19/2018: V1 from Chang. Reviewed within days

      2 month gap caused by Intel:

      05/31/2018: V2 Request from Andy to split the set

      06/04/2018: Base-V1 The first chunk of changes.

      06/06/2018: Base-V2 Slight modifications

      06/07/2018: Base-V3 Slight modifications. Review on 08/18

      06/20/2018: Base-V4 Review on 06/22

      06/27/2018: Base-V5

      2 month gap caused by busy maintainers. You know what they were busy with
      at that time, right? Chasing subtle bugs in the so perfect L1TF patches
      which were thrown over the fence by you and dealing with the Intel induced
      speculation crap to have a consistent and maintainable mitigation including
      proper documentation.

      08/23/2018: Base-V5 Resend. Review on 9/14

      09/18/2018: Base-V6. Merged 10/08

      10/23/2018: Full-V3. Review immediate

      10/24/2018: Regression detected caused by Base-V6

      The so perfect base patch set caused a regression and it takes more than a
      month to fix it properly:

      10/30/2018: Fix-V1. Broken
      10/31/2018: Fix-V2. Broken
      11/01/2018: Fix-V3. Broken
      11/14/2018: Fix-V4. Broken
      11/15/2018: Fix-V5. Broken
      11/26/2018: Fix-V6. Finally

      2 months to address the Full-V3 feedback:

      01/16/2019: Full-V4. Change request

      02/01/2019: Full-V5. Review immediate

      02/13/2019: Full-V6.

      1 month gap caused by busy maintainers. Ash on my main...

      03/15/2019: Full-V6 resend

      So just to put this straight:

      Out of 40 month since the first post in 11/2015:

      20 months nothing happened from Intel side
      8 months consumed to produce the next set
      1 month to fix a regression
      2 months consumed to react on review feedback
      ----------------------------------------------
      31 months

      versus:

      2 months maintainers dealing with Intel crap
      1 month maintainers being busy

      The rest is the usual review/re-post ping pong delay which sums up, but
      from the larger gaps more than 75% are Intel induced and 7% maintainer
      induced.
      It's a response of the kernel maintainer to some Intel employee. It exactly shows the attitude of f*cking Intel morons. I don't know if it's conspiracy, but it proves Intel is full of bullshit and it's far from being professional. They put their users on risk all the time.

      Comment


      • #13
        I'm assuming that bug mentioned is rooted in buggy Intel hardware, which wouldn't surprise me at all. After all, Intel has been quite consistent when it comes to making their hardware buggy.

        Comment


        • #14
          Originally posted by Wojcian View Post

          Nice try lameboy:

          https://lkml.org/lkml/2019/3/26/719



          It's a response of the kernel maintainer to some Intel employee. It exactly shows the attitude of f*cking Intel morons. I don't know if it's conspiracy, but it proves Intel is full of bullshit and it's far from being professional. They put their users on risk all the time.
          Holy shit, that post from Thomas Gleixner (the maintainer who reverted these patches) to Andi Kleen is brutal. There's a final bit you didn't quote where he points out that he's the last x86 maintainer willing to deal with him, and that his patience is running thin with his antics.

          It's also interesting when Kleen replies and completely ignores the bit where Gleixner shuts them down over the timeline. They recognized it's a lost cause, I think, but certainly didn't acknowledge that they were wrong and that the complaint was unfounded. Might be some truth to the premise that maintainers aren't keen to Kleen if they argue a lot and never admit fault. It's possible that Kleen just wanted to stop poking the bear, but given that they're still arguing about something else, I think it's more that they knew it wouldn't go anywhere, so they dropped it silently.

          Comment


          • #15
            Originally posted by Wojcian View Post

            Nice try lameboy:

            https://lkml.org/lkml/2019/3/26/719



            It's a response of the kernel maintainer to some Intel employee. It exactly shows the attitude of f*cking Intel morons. I don't know if it's conspiracy, but it proves Intel is full of bullshit and it's far from being professional. They put their users on risk all the time.
            I didn't mean that the code didn't have issues or that the Intel dev shouldn't have payed more attention.
            I am saying that all matters is that "blatantly never tested code" was merged by that guy. This could have reached far further. The fact that the developer has been supposedly annoying in any way does not help with that (quite the contrary in fact).
            If he didn't even bother checking if those patches worked, what kind of reviewing does this even get? This easily could have been a regression actually landing in Linux.

            Comment


            • #16
              Originally posted by L_A_G View Post
              I seriously doubt that Intel, being primarily a hardware vendor, has the kind of people who would understand what's going on here in upper management.
              Intel has something like 15 000 developers. You can bet there are also thousands managing them.. It might be issue of manager(s) nagging and nagging like old wives after 20 years of marriage "to produce results and get on with the next project". You bet you are going to make ton on mistakes, when you have "manager" looking over your shoulder non-stop and whining.
              Last edited by aht0; 05 July 2019, 04:33 PM.

              Comment


              • #17
                Originally posted by AsuMagic View Post

                I didn't mean that the code didn't have issues or that the Intel dev shouldn't have payed more attention.
                I am saying that all matters is that "blatantly never tested code" was merged by that guy. This could have reached far further. The fact that the developer has been supposedly annoying in any way does not help with that (quite the contrary in fact).
                If he didn't even bother checking if those patches worked, what kind of reviewing does this even get? This easily could have been a regression actually landing in Linux.
                The code compiled and the patches "worked" superficially. Go look at the initial quote:

                Originally posted by Thomas Gleixner
                The FSGSBASE series turned out to have serious bugs and there is still an open issue which is not fully understood yet. The confidence in those changes has become close to zero especially as the test cases which have been shipped with that series were obviously never run before sending the final series out to LKML.
                The patch series caused bugs, so they started digging deeper and found that the test case provided with the patch series didn't work, so it hadn't been run.

                The onus is on individual developers to test their own code. Other people have to sign the patches, but in a huge organization like Intel, much of that process can happen in-house.

                Kernel developers are supposed to review the patches and provide feedback. Usually it's someone who's familiar with that portion of code - not necessarily the person in charge of that section of the kernel. And when it's Intel processor stuff, it's easy to assume they're the resident experts. Even after a code review, you can still miss complex issues.

                Maintainers go the extra mile when they suspect something wrong. But it's not bad that the local maintainer pulled it. Especially since he didn't pass it upstream to Linus. If anything, it shows the group tested the patches pulled before claiming they were ready. You've got to pull it locally before you can run it. And compiling and running every patch you're handed is a real quick way to lose all your time.

                Comment


                • #18
                  Superior software is one of Intel's pillars of success. They brag that they have more software engineers than AMD has employees.

                  There's no smiley to express how I feel about this.

                  Comment


                  • #19
                    Originally posted by L_A_G View Post

                    I seriously doubt that Intel, being primarily a hardware vendor, has the kind of people who would understand what's going on here in upper management. Instead of software people their board is bound to be a mix of hardware people and the MBA types that run pretty much all big corporations these days. More probably than not they'll just think that Linus and the other lead kernel maintainers are just being difficult because they hate the company or something even without the muppets in question trying to explain it to them as such.

                    Not that there aren't valid reasons to hate Intel as many of the business practices they've employed over the years are akin to the practices Monsanto has used to push out it's competitors and exploit farmers. Because of the easily drawn parallels I personally consider the to essentially be the Monsanto of the semiconductor industry.
                    Please don't drag Monsanto down to Intels levels here. That is just parroting the anti-GMO trolls propaganda.

                    Comment


                    • #20
                      Originally posted by L_A_G View Post
                      I seriously doubt that Intel, being primarily a hardware vendor
                      intel for many years is holding spot of topmost kernel contributor

                      Comment

                      Working...
                      X