Messages in this thread | | | Date | Tue, 5 May 2015 15:30:54 +0200 | From | Jiri Bohac <> | Subject | running hrtimer_start on an already active hrtimer? |
| |
Hi,
I came across a strange bug (in a very old kernel) that triggers the BUG_ON(timer->state != HRTIMER_STATE_CALLBACK); in __run_hrtimer().
The code runs hrtimer_start() on an already started hrtimer. Looking at the description of hrtimer_start() it looks like something that is allowed: /** * hrtimer_start - (re)start an hrtimer on the current CPU ... * Returns: * 0 on success * 1 when the timer was active
Is this really supposed to work?
I think it's not immune to this race condition:
CPU0 CPU1 __run_hrtimer() __remove_hrtimer(...HRTIMER_STATE_CALLBACK) //clears HRTIMER_STATE_ENQUEUED ... raw_spin_unlock(&cpu_base->lock); restart = fn(timer); hrtimer_start() __hrtimer_start_range_ns() //remove_hrtimer() does nothing because // HRTIMER_STATE_ENQUEUED is not set enqueue_hrtimer() raw_spin_lock(&cpu_base->lock); ... BUG_ON(timer->state != HRTIMER_STATE_CALLBACK); // state has HRTIMER_STATE_ENQUEUED set
Should __hrtimer_start_range_ns() do something like hrtimer_cancel - i.e. explicitly check for ... HRTIMER_STATE_CALLBACK?
Thanks,
-- Jiri Bohac <jbohac@suse.cz> SUSE Labs, SUSE CZ
| |