[arinlen]

> I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is.

You should read the email thread, as Linhas explains in clear terms.

Take for instance Linus's insightful followup post:

https://lkml.org/lkml/2022/9/19/1250

[ChrisSD]

What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?

[throw827474737]

Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field).

So I can understand where Linus comes from.

[gmueckl]

Yes. You could still hard reset after the error is reported if you wanted to. And if system availability matters, a hardware watchdog would handle the case where the error handling doesn't finish.

[mlindner]

Limping along is what the salesman and the business people want as failures look bad.

Engineers should want the immediate stop, because that's safer, especially in safety critical situations.

[wtallis]

The kernel is not the whole system. The kernel needs to offer the "limping along" option so that the other parts of the system can implement whatever graceful failure method is appropriate for that system. There's no one size fits all solution for the kernel to pick.

[niscocity35]

What are you talking about? Should planes stop flying when they encounter an error?

Safety critical systems will try to recover to a working state as much as possible. It is designed with redundancy that if one path fails, it can use path 2 or path 3 towards a safe usable state.

[warinukraine]

You sound like you code websites or something.

Real engineers, like say the people who code the machines that fly in mars, don't want "oops that's unexpected, ruin the entire mission because that's safer". Same for the Linux kernel.

[Someone1234]

This question is answered in Linus' emails fully and better than I'm going to do.

But to restate briefly, the answer varies wildly between kernel and user programs, because a user program failing hard on corrupt state is still able to report that failure/bug, whereas a kernel panic is a difficult to report problem (and breaks a bunch of automated reporting tooling).

So in answer: Read the discussion.

[ChrisSD]

You seem to have misunderstood me. The distinction I'm making is not between kernel panic or undefined behaviour. The distinction is between undefined behaviour and defined behaviour. That defined behaviour can be anything, even including "limping on" somehow.

[yencabulator]

What is better for a desktop user:

1) needing to reload a wifi driver to reinitialize hardware (with a tiny probability of memory corruption) OR choosing to reboot as soon as convenient (with a tiny probability of corrupting the latest saved files)

2) to lose unsaved files for sure and not even know what caused the crash

[notacoward]

Why focus exclusively on the desktop, or over-generalize from it to other uses? What is appropriate for them is not necessarily so for the many millions of machines in server rooms and data centers. Also, you present a false dichotomy. "Lose unsaved files for sure" is not the case for many systems, and "not even know" is not necessarily the case. Logging during shutdown is a real thing, as is saving a crash dump for retrieval after reboot. Both have been standard at my last several projects and companies.

As I've said over and over, both approaches - "limp along" and "reboot before causing harm" - need to remain options, for different scenarios. Anyone who treats the one use case they're familiar with as the only one which should drive policy for everyone is doing the community a disservice.

[yencabulator]

Yes, both need to remain options. Rust-in-kernel needs to be able to support both. That's like half of Linus's ranting there.

The other half is that kernel has a lot of rules of what is safe to be done where, and Rust has to be able to follow those rules, or not be used in those contexts. This is the GFP_ATOMIC part.

[Jweb_Guru]

The latter, because the "tiny probability of memory corruption" can easily become a CVE.

[P5fRxh5kUvp2th]

We have a term for this.

FUD

[Jweb_Guru]

Linux has numerous CVEs, and a large percentage stem from memory corruption. That's not FUD, I'm afraid.

[scoutt]

It's FUD. And not only that. The fear of constantly being attacked by an external entity is also paranoic.