Messages in this thread | | | From | "Leonid Shatz" <> | Subject | RE: [PATCH] fix hrtimer_enqueue_reprogram race | Date | Tue, 5 Feb 2013 14:36:51 +0200 |
| |
> > 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
| |