XFS bug in Linux kernel 6.3.3 coincides with SGI code comeback

SGI may be no more but people are still using its code – and some more of that code may be about to enjoy a revival. Although Silicon Graphics was delisted back in 2005, and its name taken over by Rackable in 2009, much of its code is still very much around, in active use, and attracting interest. In December, we reported that …

[jake]

"Well, if you're on 6.2, you may want to stay there for now."

6.2 has reached EOL. You're better off sticking with 6.1, which EOLs in December 2026. In fact, I can make a case that the vast majority of people should be using 5.15 (or perhaps 5.10) at the present moment in time.

For the most part, you should never be using bleeding edge Linux kernels unless you're a developer. It's asking for trouble.

If anybody cares, I use 5.10 for most production stuff, and 4.19 in several places. TheyJustWork[tm]

[Scott 26]

Hat tip to the Sir Pterry reference.....

[Alistair]

jake:

Most (even bleeding edge) active releases are running 6.2. I have a gentoo image running 6.3.3, but no xfs there, its just to verify a build I help with. And the fix is already available.

I do hope you are keeping those 4.19's patched up, there were some ugly issues for which backports were issued.

[jake]

"Most (even bleeding edge) active releases are running 6.2."

6.2 is EOL. It is no longer being maintained as of today.

"I have a gentoo image running 6.3.3, but no xfs there, its just to verify a build I help with."

If you are a developer who needs that kind of thing, more power to you. The more eyes on the system the better, IMO. I've got 6.4-rc4 running on a couple of dev boxes for similar reasons. But it's hardly necessary or prudent to write, for example, ElReg articles on a deadline using it. There are better kernels that are more than adequate for day to day work.

"And the fix is already available."

I never said otherwise. The point is that most folks had no need to run afoul of the bug in the first place.

"I do hope you are keeping those 4.19's patched up, there were some ugly issues for which backports were issued."

4.19 is in so-called SLTS, and will be properly maintained until at least the end of 2028. See: 4.19-cip for more. Also 4.4-cip and 5.10-cip. The web site cip-project.org has plenty of information on this, including a recent announcement here. And of course The Linux Foundation is onboard, you can get started reading up on it here.

[Anonymous Coward]

"This use of G.N.U. – no, not that GNU..."

You mean its a gnother gnu ?

[Anonymous Coward]

SGI kit with NetBSD

Best wishes to anyone taking a shot at reviving or otherwise recreating an IRIX -- still one of my favorite Unix OS's ever.

In the meantime it's worth a reminder mention, that if you still have an Indy or O2 et al sitting loved but unused, and aren't willing to let it go, you can still run NetBSD on the thing today. It's not IRIX, but if you're at all like me then it'll feel like good old Unix to you in the ways that matter. Same with your purple and green Indigo's, I'm told, but I only had NetBSD on O2 and Indy before donating them to other hobbyists.

http://wiki.netbsd.org/ports/sgimips/

[CowHorseFrog]

i amazed that Linus allows such poor variable naming standards. One comment in one of the links mentions that the mistake was a one letter difference in two vars, and looking at the names of the vars they are acronyms of some kind. I dont understand the value of being so economical on these names when its so obvious that this economy also means its very easy to make a typo and reference the wrong var.

[FIA]

It's historic code imported from SGI, with its roots in the 90s.

It's also quite important that it not go wrong. (as this article shows).

I'd not sign off a change like this in any code, I'm of the opinion working and tested code shouldn't be changed without a good reason, and I'm not sure a variable name is good enough with critical code like this.

The problem in this case wasn't the variable name, it was the contents of the variable were used to hold a different value in a specific case, which was used by the higher up code to indicate a particular condition had occurred. The refactored code had (correctly) split this out into it's own parameter, but hadn't accounted for the previous use case.

This is quite a common bug, and can be very hard to track down. It can also be very hard to avoid too, as often these things are added retrospectively to avoid a large re-factor in sections of the code. When 'Do it correctly' and 'Do it within the allocated timescales' meet each other like that, doing it correctly really needs a forceful flag waver as otherwise the cheaper option will win out.

The cheaper option generally always wins out.

[CowHorseFrog]

> The problem in this case wasn't the variable name, it was the contents of the variable were used to hold a different value in a specific case, which was used by the higher up code to indicate a particular condition had occurred.

It doesnt matter if it was an enum of magic values and not var names. You are arguing about semantics and avoiding again the real problem, economy in these values resulted in a typo or mistake in selecting some value.

> When 'Do it correctly' and 'Do it within the allocated timescales' meet each other like that, doing it correctly really needs a forceful flag waver as otherwise the cheaper option will win out.

Article doesnt mention this ...

> The refactored code had (correctly) split this out into it's own parameter, but hadn't accounted for the previous use case.

This sounds completely different to the summary of the article, im not sure why.

[rcxb]

How many OSes did HP own?

SGI, as in The Company Formerly Known As Rackable, has been part of HP Enterprise since 2016.

I must have missed that news at the time. It's a knee-slapper though. Just how many OSes does HP own?

IRIX, HP-UX, Tru64 (Digital Unix, OSF/1), OpenVMS, NonStop, MPE/IX, Domain/OS, webOS, Palm OS. Not to mention QuickPlay and HyperSpace. Did I miss any?

Don't get me wrong, it's a tiny fraction as many as IBM has had their fingers in over the years:

https://en.wikipedia.org/wiki/List_of_IBM_products#Operating_systems

[Liam Proven]

Re: How many OSes did HP own?

[Author here]

> I must have missed that news at the time.

That's why I try to work this stuff in! It takes a bit more digging but I try to set stuff in context.

> IRIX, HP-UX, Tru64 (Digital Unix, OSF/1), OpenVMS, NonStop, MPE/IX, Domain/OS, webOS, Palm OS. Not to mention QuickPlay and HyperSpace. Did I miss any?

Hang on, no, there are several there that are nothing to do with HP/HPE.

* Tru64 / Digital Unix -- fair, yes

... but...

* OSF/1 -- the Open Group. Don't mistake an implementation for the parent product.

* OpenVMS -- spun off; belongs to VMS Software Inc. I've written about them quite extensively.

* webOS, Palm OS -- never did; belonged to PalmSource Inc. Now owned by Access, along with BeOS.

* QuickPlay -- Cyberlink corp, Taiwan.

* HyperSpace -- Phoenix Inc.

[Bebu]

The source still lurks in some if the darker corners of the internet.

I stumbled across the Irix OS source on a dodgy abandonware site a few years ago while looking for the boot floppy image for my legitimate Solaris 2.4 x86_64 - I had the original 3.5" floppy but no floppy disk drive. With the Irix source there was an odd collection of pirated old Unix OS source code. Notably missing was QNX which was sort of open source for a short time.

Only of interest to a historian I would imagine. OpenSolaris/IllumOS would be a better choice for studying a modern (Sys V.4 derived) Unix and comparing it with the contemporary BSD and Linux kernels.