Hello, On Sun, 2 Oct 2016, HePeng wrote: > Hi, > > I am a newbie to IPVS. > I read the code of ipvs in 3.10 kernel, and think the > the implementation of *ip_vs_expire_now* may cause > timer callback runs on two CPUs for a same session. IIRC, timers can not be scheduled on multiple CPUs at the same time. They can be migrated to other CPUs but only if callback is not running. __mod_timer() checks if the callback is running (base->running_timer). If so, it will schedule the timer on the same CPU where the callback is currently running. So, the callback can be called twice but not in parallel. Then, when ip_vs_conn_expire() is called it will call del_timer() to catch such situations. It is specified in the comments. > CPU 0 CPU 1 CPU2 > > > > a timer is detached > from lists, and the > callback fn is going > to be called. > > a packet belongs > to the same session > is processed by this CPU > and the timer is re-activated on > this CPU. Then, the ref of *cp* is released. > > ip_vs_conn_expire_now > is called on this > session, which finds > a pending timer, and > then *mod_timer_pending* > will change the timer > to expire immediately. > read_unlock allows > preemption again. > > the timer expires and > callback runs. call back fn runs > > > Am I right? This seems break the rule that *ip_vs_conn_expire* should only > runs on one CPU at time per conn. This is guaranteed by the timers. But it is our job to not start/leave the timer while final callback frees the conn. > see http://oss.sgi.com/archives/netdev/2003-11/msg00763.html Without checking the code from 2003, more likely the fix above stops calling mod_timer after the final del_timer to prevent starting new callback. And this goal is what is later specified in the comments in 3.10 and latest kernels. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
