Thomas Gleixner wrote: > > It exists. It triggers on preempt-RT and I can trigger it on vanilla SMP > by waiting for the timer expiry in release_task() before the > __exit_signal() call. That's reasonable, as it can happen that way by > chance too. It requires that the timer expires on a different CPU, but I > don't see a reason why this should not happen.
Ok, exit_itimers()->itimer_delete() called when the last thread exits or does exec. kernel/posix-timers.c:common_timer_del() calls del_timer_sync(), after that nobody can access this timer, so we don't need to lock timer->it_lock at all in this case. No lock - no deadlock. But I know nothing about kernel/posix-cpu-timers.c, I doubt it will work for posix_cpu_timer_del(). I don't have time to study posix-cpu-timers now. However, I see that __exit_signal() calls posix_cpu_timers_exit_xxx(), so may be it can work? 380 int posix_cpu_timer_del(struct k_itimer *timer) 381 { 382 struct task_struct *p = timer->it.cpu.task; 383 384 if (timer->it.cpu.firing) 385 return TIMER_RETRY; 386 387 if (unlikely(p == NULL)) 388 return 0; 389 390 if (!list_empty(&timer->it.cpu.entry)) { 391 read_lock(&tasklist_lock); Surely, it should be impossible to happen when process exists, otherwise it would deadlock immediately, we did write_lock(tasklist). Thomas, do you know something about posix-cpu-timers.c? Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/