> >> 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.
Yep but signal handling code will not be entered because signal
handling is only entered when returning to userspace.
Pavel
-- Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? - 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/