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,
tglx
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |