On Mon, 8 Jul 2002 20:13:31 +0200,
Pavel Machek <pavel@ucw.cz> wrote:
>Keith Owens wrote
>> BTW, freeze_processes() silently ignores zombie processes. The test is
>> not obvious, it is hidden in the INTERESTING macro which has an
>> embedded 'continue' to break out of the loop. Easy to miss.
>
>Is there problems? Zombie processes are basically dead, not
>interesting, processes.
I have had reports of module threads being shut down by the cleanup
routine, the module was removed then the zombie threads were reaped and
got an oops because the module code that spawned them no longer
existed. It is not clear why this is a problem, I will follow up with
the reporter.
>> freeze_processes()
>> signal_wake_up() - sets TIF_SIGPENDING for other task
>> kick_if_running()
>> resched_task() - calls preempt_disable() for this cpu
>> smp_send_reschedule()
>> smp_reschedule_interrupt() - now on another cpu
>> ret_from_intr
>> resume_kernel - on other cpu
>>
>> With CONFIG_PREEMPT, a process running on another cpu without a lock
>> when freeze_processes() is called should immediately end up in
>> schedule. I don't see anything in that code path that disables
>> preemption on other cpus. If I am right, then a second cpu could be in
>> this window when freeze_processes is called
>>
>> if (xxx->func)
>> xxx->func()
>
>okay, so we have
>
> if (xxx->func)
> interrupt
> schedule()
>
>but schedule at this point is certainly not going to enter signal
>handling code
With preempt it will. The interrupt drops back through ret_from_intr
-> resume_kernel. The preempt count is 0, preemption has only been
disabled on the sending cpu, not the receiving cpu. need_resched is
entered immediately.
-
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/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:14 EST