zlacker

[parent] [thread] 17 comments
1. tcfhgj+(OP)[view] [source] 2022-10-02 14:53:29
> Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable.

Wouldn't be that sure about that. Getting the wrong answer can be a serious security problem. Not completing the operation... well, it is not good, but that's it.

replies(5): >>2OEH8e+k >>atoav+x >>atty+71 >>remram+xa >>alerig+Pc
2. 2OEH8e+k[view] [source] 2022-10-02 14:55:26
>>tcfhgj+(OP)
True- which is why he says to throw a warning first.
3. atoav+x[view] [source] 2022-10-02 14:56:26
>>tcfhgj+(OP)
I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill.

It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.

replies(2): >>analog+e5 >>fritol+26
4. atty+71[view] [source] 2022-10-02 15:00:29
>>tcfhgj+(OP)
The kernel can’t fail to complete its operations, because then the entire system crashes and no logs are created. Instead, you can finish the operation and check the result.
replies(2): >>charci+V8 >>chlori+fV1
◧◩
5. analog+e5[view] [source] [discussion] 2022-10-02 15:23:06
>>atoav+x
This sounds like the difference between "fault tolerant" and "fail safe".

Fault tolerant - you get a fault, you keep moving.

Fail safe - you fail, and thus all operations are stopped.

replies(2): >>gmueck+vu >>atoav+ld2
◧◩
6. fritol+26[view] [source] [discussion] 2022-10-02 15:27:59
>>atoav+x
Unless it was holding a welding gun and stopped on one spot with the welding flame turned on instead of gracefully turning off the flame and backing away.

Never used Rust before but is there a way to supply some default code to run in such a situation instead of just not carrying out the bad operation?

replies(1): >>shephe+x8
◧◩◪
7. shephe+x8[view] [source] [discussion] 2022-10-02 15:41:48
>>fritol+26
Yes, you can define your own panic handler in Rust.

https://doc.rust-lang.org/nomicon/panic-handler.html

◧◩
8. charci+V8[view] [source] [discussion] 2022-10-02 15:44:21
>>atty+71
panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.
replies(3): >>wtalli+ke >>Someon+bg >>second+Pk
9. remram+xa[view] [source] 2022-10-02 15:52:41
>>tcfhgj+(OP)
Not completing the operation is also a security issue, commonly called denial of service (DoS).
10. alerig+Pc[view] [source] 2022-10-02 16:06:19
>>tcfhgj+(OP)
> Not completing the operation... well, it is not good, but that's it.

Depends on what the operation is. If the operation is flying an airplane or controlling a nuclear reaction, you are sure that not completing the operation and just aborting the program is the worst outcome possible. Beside the error can crash the plane or melt down the nuclear reactor, but may also not have any effect at all, e.g. a buffer overflow overwrites a memory area that is not used for anything important.

Of course these are extreme example (for which Linux is of course out of discussion since it doesn't offer the level of safety guaranteed required), but we can make other examples.

One example could be your own PC. If you use Linux, take a look at the dmesg output and count the number of errors: there are probably a lot of them, for multiple reason. You surely want your system to continue running, and not panic on each of them!

◧◩◪
11. wtalli+ke[view] [source] [discussion] 2022-10-02 16:14:05
>>charci+V8
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.
◧◩◪
12. Someon+bg[view] [source] [discussion] 2022-10-02 16:23:48
>>charci+V8
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.

replies(1): >>charci+4Q
◧◩◪
13. second+Pk[view] [source] [discussion] 2022-10-02 16:45:58
>>charci+V8
Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?
replies(1): >>charci+RP
◧◩◪
14. gmueck+vu[view] [source] [discussion] 2022-10-02 17:39:40
>>analog+e5
Failing may require triggering some actions actively. Going inert is not the right way in many cases. Some system absolutely require best efforts in the face of failure. A fire alarm in an otherwise secure and locked down facility may have to trigger the opening of door locks, for example.
◧◩◪◨
15. charci+RP[view] [source] [discussion] 2022-10-02 19:56:40
>>second+Pk
Print it to the cloud
◧◩◪◨
16. charci+4Q[view] [source] [discussion] 2022-10-02 19:57:43
>>Someon+bg
>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.

◧◩
17. chlori+fV1[view] [source] [discussion] 2022-10-03 05:26:15
>>atty+71
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.

◧◩◪
18. atoav+ld2[view] [source] [discussion] 2022-10-03 08:30:16
>>analog+e5
I mean the Rust appeal is actually that it foeces you to handle Errors. Whether you then fail or not is your decision. What Rust usually does not do is just fail.

This is good for when the things you are using could error, e.g. when you use an arbitrary unicode string as a filename you might get an error because depending on the OS there might be characters that you cannot use as filenames that are valid unicode (or the other way around, possible filenames that are not valid unicode).

In most programming languages this is something you need to know to catch it. In Rust this is an Error that you can or cannot handle. But you can't forget to deal with it.

[go to top]