Linux-kernel mailing list archive 1997-48,: Re: Rejected patch.

# Re: Rejected patch.

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Thu, 4 Dec 1997 10:32:25 +0100 (MET)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: System Administrator: "Max file size ?"
- Previous message: Philip Blundell: "Re: ISSUE: lp0/lp1 incompatibility"

Linus Torvalds wrote:
>
>
>
> 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.

Well, I like the way that Linux continues after an Oops very much.
It usually kills off the tar process trying the new tape drive or the
insmod that is trying to insert the new module.

The reason I had been messing with that code was that it didn't work
the Linux-way: it hit "killing interrupt handler" a few hundred times
until it had killed off all processes and that was the end of it. In
the end the Oops-info on the screen was totally invalid.

I want:
-- The system to remain running whenever possible.
-- The oops-info to be valid.

Wouldn't it be possible to return to the point where the interrupt
interrupted? That might be a special case here after the
"if (in_interrupt())", but that would be fine with me. An interrupt
should get blacklisted (disabled) if it does this more than a few
times....

Roger.

    --
    ** R.E.Wolff@BitWizard.nl ** +31-15-2137555 ** http://www.BitWizard.nl/ **
    Florida -- A 39 year old construction worker woke up this morning when a
    109-car freight train drove over him. According to the police the man was
    drunk. The man himself claims he slipped while walking the dog. 080897

- Next message: System Administrator: "Max file size ?"
- Previous message: Philip Blundell: "Re: ISSUE: lp0/lp1 incompatibility"