Messages in this thread | | | Date | Tue, 16 Nov 2004 21:51:51 +0100 (MET) | From | Jan Engelhardt <> | Subject | Re: Work around a lockup? |
| |
>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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |