Messages in this thread | | | Date | Mon, 4 Feb 2013 11:12:56 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: hrtimer possible issue |
| |
On Sun, 3 Feb 2013, Izik Eidus wrote:
> Hi, > > it seems like hrtimer_enqueue_reprogram contain a race which could result in > timer.base switch during unlock/lock sequence. > > See the code at __hrtimer_start_range_ns where it calls > hrtimer_enqueue_reprogram. The later is releasing lock protecting the timer > base for a short time and timer base switch can occur from a different CPU > thread. Later when __hrtimer_start_range_ns calls unlock_hrtimer_base, a base > switch could have happened and this causes the bug > > Try to start the same hrtimer from two different threads in kernel running > each one on a different CPU. Eventually one of the calls will cause timer base > switch while another thread is not expecting it. > > This can happen in virtualized environment where one thread can be delayed by > lower hypervisor, and due to time delay a different CPU is taking care of > missed timer start and runs the timer start logic on its own.
Nice analysis.
> This simple patch (just to give example of a fix) refactor this function to > get rid of unneeded lock which immediately was followed by the unlock (with > possible undesired base switch). > > (Both the bug and the fixed were found/patched by Leonid Shatz)
The patch got mangled by your mail client and it is missing the proper Signed-off-by annotation in the patch description. See Documentation/SubmittingPatches.
Can you please resend ?
Thanks,
tglx
| |