Re: Work around a lockup?

[Jan Engelhardt]

>If there is a continuous loop inside the kernel, something outside
>the kernel (you) are never going to get control except from an
>interrupt. The keyboard interrupt is going to let you see what
>is happening, but you won't get any real control because the
>kernel is not a task. If the kernel were a task (like VMS),

(Surprise.) Yes, I can still ping it and initiate a connection (i.e. the queue
accepts it, because someone did listen() on the socket), but that's all. I bet
that's due to the network card generating an interrupt.

>you could (maybe) context-switch out of the kernel. But,
>the kernel is some common code that executes on behalf of
>all the tasks in the context of "current". If the current
>task is stuck inside the kernel code, it has nowhere to go.

Wait, an interrupt can ... well interrupt a task, /even/ if it is in kernel
mode, otherwise jiffies would not get incremented. So, would not it be possible
to call some sort of schedule() when do_timer() (or similar) is run?
Like:
  foreach p in runqueue {
    if(p->location==KERNELSPACE && exceeded-kernelspace-timeslic) {
      switch_to(rq->next); // "never returns"
    }
  }

>When some user task executes outside the kernel, it doesn't
>have the priviliges to loop forever. A context switch will
>occur and the CPU will be shared with others. However, when
>that user task calls some kernel function, perhaps from
>a driver interface, that function has the priviliges to
>keep the CPU forever. If the driver is improperly written,
>it will.

So to summarize what I need: disprivilege a process to keep the CPU forever
when it is in kernel mode.



Jan Engelhardt
-- 
Gesellschaft fÃr Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 GÃttingen, www.gwdg.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/