Timeline for Why does exception in interrupt always lead to Kernel Panic?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 31, 2024 at 0:35 | comment | added | waltinator | Interrupt mode saves the interrupted task's context. When interrupt mode gets interrupted, where would the context (along with the extra "interrupt mode" context) be stored? How would the system return after handling the interrupt's fault? Return to the faulty code? Return to the calling user? Where would it find the user's context? | |
| Oct 26, 2024 at 20:52 | comment | added | Gilles 'SO- stop being evil' | That explains why faults in kernel mode should cause a panic. But the question here is, given that most faults in kernel mode actually do not cause a panic in Linux, why do faults in interrupt contexts still cause a panic? | |
| Oct 26, 2024 at 20:01 | comment | added | Elisa K. K. | It doesn't answer the question. I know that the system cannot be relied on after a crash. But if that crash happens in non-interrupt context (STILL, IN KERNEL!!!) then my system is not halted: only Oops is triggered. And if the crash happens IN INTERRUPT, the system is ALWAYS HALTED IMMEDIATELY. This design was the topic of the question. NOT the fact that a crashed system can't be relied on. | |
| Oct 26, 2024 at 18:40 | history | edited | ilkkachu | CC BY-SA 4.0 | I think we can do without jabs like that |
| Oct 26, 2024 at 18:08 | history | answered | waltinator | CC BY-SA 4.0 |