RE: [PATCH] fix hrtimer_enqueue_reprogram race

[Leonid Shatz]

> > There are already locks used inside hrtimer code, so why should users
> > of the hrtimer add another layer of locks and get involved in the
> > intricacy of which cases are protected by internal hrtimer lock and
> > which are not?
> 
> Groan. The hrtimer locks are there to protect the internal data structures
of
> the hrtimer code and to ensure that hrtimer functions are proper protected
> against concurrent running callbacks. But that does not give you any kind
of
> protection versus multiple users of your hrtimer resource.
> 

I was not raising the issue of protecting the logic of hrtimer use cases -
this was not the scope of the entire issue. The issue was that internal
hrtimer locks were getting screwed and it was not reasonable to add external
layer of locks to protect internal hrtimer locks (I mean before this patch).
The fix should provide protection for internal locks and I think we both
agree on that.

Leonid

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/