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