Max Kellermann wrote: > do_alarm_run() determines the next_alarm time. there is however a > condition where this result comes wrong, because of "unsafe" side > effects of list_for_each_entry_safe(). Example: imagine there are two > alarms: A is due now, and B is due in 5 minutes. > > When do_alarm_run() runs alarm A, list_for_each_entry_safe() remembers > B as the alarm for the next loop iteration. > > Now A re-schedules itself in 1 minute. It is again the first entry in > the alarm_list queue, but list_for_each_entry_safe() will not handle > it in this loop. > > Instead, do_alarm_run() sees B and returns "5 minutes" as the > next_alarm time. > > Solve this by breaking from the loop when a late event is detected, > and letting get_next_alarm() do all the work. Good point. I noticed this while rewriting the alarm scheduler, in the rewrite it should handle this case correctly. -- "Los honestos son inadaptados sociales" -- Les Luthiers - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
