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

[L_A_G]

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.

[Wojcian]

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.

[Guest]

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.

[Terrablit]

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.

[AsuMagic]

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.

[aht0]

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.

[Terrablit]

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:

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.

[xnor]

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.

[F.Ultra]

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.

[pal666]

I seriously doubt that Intel, being primarily a hardware vendor

intel for many years is holding spot of topmost kernel contributor