The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

[marios]

This would've never happened if the whole kernel and Xorg stack were written in rust.

LoL. I was thinking about creating a throw-away account just to write this. And then LoL at the braindead rustafarians defending this ridiculous claim (the smarter ones will just ignore it, they know that now language can fix stupidity).

[kozman]

So, in laymans terms, what does removing this erroneous code do exactly? Is there any perf benefit or it just prevents something that should run to not run?

[Ironmask]

So, in laymans terms, what does removing this erroneous code do exactly? Is there any perf benefit or it just prevents something that should run to not run?

It was a hack, it fixed an older version of Xorg that used atomics incorrectly. All this potentially fixes is any daemons starting with "X" that tried to use atomics, which, at this point, there is no list of. So far, both the hack and removing it are inconsequential. There probably is no performance change at all, unless this somehow affected some random DRM software starting with "X" that wasn't xorg.
It's mostly just to clean up the source code.

[emblemparade]

What a nice blend of 1) well-informed people who know the code and know the architecture and what they are talking about, and 2) random commentators looking to vent (unsolicited) regarding topics that are entirely tangential to the original Phoronix article.

Welcome to the Phoronix forums! Consistent quality since 2004.

[sinepgib]

Misbehaving code in a kernel simply crashes the kernel.

Again, ideally. I did write a bug in a custom Linux driver once that corrupted memory and it did not crash the system until much later than when the bug manifested. I was allocating one page less than I thought due to a lame attempt to be clever at math, so my driver ended up writing out of bounds corrupting the poor innocent soul that asked for the next page.
That wouldn't have happened in a microkernel because either that page was mapped by my process and it didn't (directly) affect other drivers or kernel tasks or it wasn't and the driver receives a segfault at the very moment of access, deterministically. What policy to follow when that happens would be probably defined on the basis of how critical the process is, of course. Crashing the OS gracefully or restarting.
Obviously, even in the first scenario there's no "no harm guarantee". For example, if the driver did corrupt itself now it would send unreliable results to processes asking it for data, so there could be a chain reaction. But that's still a reduction in the ways it can harm the user and specially their data.

A misbehaving usermode driver could keep being respawned over and over, corrupting more and more data.

If you choose to restart it, yes. But as you later noted, some critical services may be taken as a cue to graceful shutdown if they crash.

The whole point of critical OS code, whether userspace or kernelspace, is to kill the entire OS before anything else can happen.

Exactly. And which scenario makes this easier? Driver can corrupt the kernel page table or driver tries to write outside of its allowed addresses and simply crashes without affecting the rest of the system?

For some reason, people seem to think a microkernel has some sort of supernatural ability to keep an OS running when theres a critical bug in a driver or if the hardware is faulty.

On one hand, absolutely, some people seem to believe microkernels have stronger guarantees than they have. On the other hand, that's not at all what I suggest. It's just another mitigation that reduces blast radius. It's not a silver bullet.

No, it just means the kernelmode address space doesn't get clobbered.

Kernel mode and other drivers. It's not a minor thing that my GPU driver can't corrupt my VFS drivers IMO. One of them has much greater chances of borking my files than the other.

[sinepgib]

What a nice blend of 1) well-informed people who know the code and know the architecture and what they are talking about, and 2) random commentators looking to vent (unsolicited) regarding topics that are entirely tangential to the original Phoronix article.

Welcome to the Phoronix forums! Consistent quality since 2004.

Since we're all funny and sarcastic, let's also mention the passive aggressive observations that add nothing useful to either of the topics in play

[mercster]

I'm not a C dev

Shoulda stopped there, bro. :-)

[ayumu]

The trouble with most microkernels is the IPC overhead. Pass a message, wait for the scheduler to switch cpu control to the other process, pass a message, wait for the scheduler, etc. Making most implementations significantly slower than a monolithic kernel.

AFAICT, the only succesfull microkernel OS that solved that particular problem is QNX, which tightly integrated message passing with cpu scheduling, thereby reducing unnecessary cpu cycles switching between processes. Pass a message, if the receiving process is waiting for it, give waiting process control over the cpu. Cuts out a lot of back and forth.

Have other microkernel OSes copied this behaviour? The patents should have expired by now, as QNX was initially released in 1982.

Look into Jochen Liedtke's research, and microkerneldude.org (in chronological order) as the natural continuation of that.

[ayumu]

To this hole microkernel thing most of the things where allready pointed out.

1. support from the hardware oem is needed for drivers, why code a new driver for something unknown if you have a working system with linux/windows
2. the modular approach, well linux has that vfs/block/mm/sheduler/driver, how long does it count as micro kernel, and when is it a full os, if you just have the kernel and no driver no filesystem no block layer no memory no pcie no gpu support that leaves you with just a BIOS and you can do nothing.
3. lets say you include drivers in the microkernel and each layer can reset from errors, you need to comunicate that an error accured to the kernel, that a module needs to be reset, and when a module is reset, it needs to reset all modules that have dependencies vfs->fs->block->nvme, in the case that an corruption took place in the vfs layer cache/buffer for block devices you need to restart 4 modules, and on top of that also reinitialize the pcie bus for the nvme drive, so the pcie registers are clear and in a sane state, to do that you need access to low level hardware registers and the knowledge for that driver wich again comes from OEM´s, you need a datasheet for that, and a NDA, oh my samsung nvme does this stuf on pci register xx and it should be reset to yy with a driver reset.

SO now you have the same problem linux has, you simply cant code a opensource os like that without the right stuff so whats the solution ?

Like linux and windows do you throw a bluescreen and simply reboot, cause the hardware blob knows how to do.

This microkernel aproach only works in highly special embedded systems with limited hardware and in an controled enviroment , like maybe miltary grade hardware, powerplants etc. where you know my chips from 1979 still work with it.

Your focus seems to be fault-tolerance. Look into Minix3, it has a lot of papers on the subject.

[furtadopires]

Shoulda stopped there, bro. :-)

Because god forbids I having a legit on topic doubt, right?

"Shoulda" stopped at user creation form junior user