Re: ip_vs_conn_expire_now may cause timer callback runs on two CPUs for a same session

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	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



[Index of Archives]     [Linux Filesystem Devel]     [Linux NFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]     [X.Org]

  Powered by Linux