[lkml]   [2005]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ktimers subsystem
On Wed, 2005-09-21 at 15:28 +0400, Oleg Nesterov wrote:

> This is deadlockable.
> The caller of modify_ktimer()->internal_restart_ktimer() can hold locks
> which would prevent the completion of the ktimer->function().

True. You are right it is a potential source of dead locking. The
initial reason to implement it that way was that I wanted to avoid cross
cpu enqueueing for the high resolution timer case as I thought it would
make cross cpu timer event reprogramming necessary. But this is actually
a non issue, as the reprogramming check can be done after the timer
function has completed on the CPU where the function is running.

The loop is not necessary. I'll fix that up.

> Also, I don't understand why the timer is deleted _before_ checking that
> new_base != NULL. This way you can delete the timer (ret == 1), then goto
> retry, then get ret == 0.

Right. The return value must only be set on the first call to
remove_ktimer, but this is a non issue after removing the loop anyway.

Thanks for pointing this out,


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-21 20:22    [W:0.038 / U:7.788 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site