Re: Rejected patch.

Linus Torvalds (torvalds@transmeta.com)
Wed, 3 Dec 1997 06:10:27 -0800 (PST)


On Wed, 3 Dec 1997, Rogier Wolff wrote:
>
> This patch got rejected because I'd been messing with that code myself.
>
> {
> if (in_interrupt())
> printk("Aiee, killing interrupt handler\n");
> + if (current == task[0])
> + panic("Attempted to kill the idle task!");
> fake_volatile:
> current->flags |= PF_EXITING;
> + acct_process(code);
> del_timer(&current->real_timer);
> sem_exit();
> kerneld_exit();
>
>
> The question is: When we're in an interrupt, or "trying to kill the
> idle task" and we get an "oops" and this happens, the question is, why
> do we bother killing an innocent process anyway? Shouldn't the do_exit
> function just return? The "thread" that caused the Oops might need to
> be "shot", in this case an interrupt hander. Does killing the
> userprocess help in this case?

The problem is that if an interrupt did something bad, we still have to
get _some_ kind of sane state from somewhere. We can't just return to the
interrupt handler that did the bad thing (it will keep on happening), so
no, we can't just return.

So the way we handle it is to tell the user that something really bad
happened, and then try to kill the current context. No, it's not really
the current context that did anything bad, but the point is that that way
we can at least try to clean up after us - even if it means killing a
innocent process.

[ Stop the presses: "Linux kills innocent children" ]

Fundamentally, this is a "don't do that, then" issue. Interrupts must
_never_ do anything which can trap, and if they do, we really have no way
to clean up after them. The above is not so much catching it as telling
people that we have a problem.

Linus