On 10/18, Andy Lutomirski wrote: > > Oleg, the code in kernel/signal.c: > > preempt_disable(); > read_unlock(&tasklist_lock); > preempt_enable_no_resched(); > freezable_schedule(); > > looks bogus. I don't get what it's trying to achieve with > preempt_disable(), and I also don't see why no_resched does anything. > Sure, it prevents a reschedule triggered during read_unlock() from > causing a reschedule,
Yes. Lets suppose we remove preempt_disable/enable. Debugger was already woken up, if it runs on the same CPU quite possibly it will preemt the tracee. After that debugger will spin in wait_task_inactive(), until it is in turn preempted or calls schedule_timeout(1), so that the tracee (current) can finally call __schedule(preempt = F) and call deactivate_task() to become inactive. > but it doesn't prevent an interrupt immediately > after the preempt_enable_no_resched() call from scheduling. Yes, but this is less likely. Oleg.
