Why does exception in interrupt always lead to Kernel Panic?

If a CPU exception in kernel, such as bad memory access or invalid opcode, happens in the context of servicing a user process (like syscall or page-in), or in a kthread process, then, until panic_on_oops was set, useful information will be dumped and the task will just die. No panic. Sometimes the system remains absolutely usable. Enough for the user to attempt syncing their disks, gracefully terminating programs, and in other ways preparing for the emergency restart. But unfortunately, if the exception happens in atomic context (like interrupt or softirq), the action taken is **always Kernel Panic** (with description "Fatal exception in interrupt") — regardless of any settings or build-time configurations. It is sad. Why it's not possible to simulate a return from interrupt, and keep the system running in hope that some parts will still function? Thanks. I know that I can put an infinite mdelay() in the code path of "exception in interrupt" instead of panic(), to just stall the local CPU instead. But usually not much things can be done after that happens... Even if there are hundred CPUs in machine, they all soon lock up. So not very useful.