The kernel can't panic and display an error message, but corrupting itself and deleting valuable data or allowing people to execute arbitrary code (possibly remotely) is okay?

I really have a hard time understanding how anyone could possibly think that's okay.

It sounds like the kernel's quality is so poor that UB is commonplace and even expected at this point. Pretty scary how many systems are relying on this huge pile of broken C code to hopefully only slightly corrupt itself and your system.

I'm not even sure how useful Rust in the kernel is going to be considering they want it to just ignore errors. You can't even have bounds checking on arrays because invalid accesses might be detected at runtime and cause an error, which is totally insane.

panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.

And when Linux is running on your fridge, in your car, or on a headless VM then who is there to read out this "printed output." The great thing about "log and continue" is you can automate collection and fix the underlying bug (or know that the hardware is failing).

Keep in mind that in a kernel panic no hardware is assumed to work, so assumptions like "just write to storage!" isn't an assumption you can make, you're in a panic the IO could have been literally pulled out.

>Keep in mind that in a kernel panic no hardware is assumed to work

So just change that assumption since for these edge cases that is an incorrect assumption.

Printing debug information to the kernel log then immediately triggering a kernel panic is not as useful as it sounds, because that approach will quite often result in that debugging information never reaching a display or any kind of persistent storage.

Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?

Print it to the cloud