|
On Thu, Dec 01, 2005 at 01:03:33PM +0900, Horms wrote:
[snip]
> In any case, not reseting the timeout in ip_vs_conn_expire() is a
> cleanup, so I came up with the following patch for 2.6. The slightly
> longer version for 2.4, which includes backporting the del_timer
> behaviour to ip_vs_conn_expire_now() is in the following message.
... and here it is
[IPVS] Cleanup and persistance timeout reset fix
Backport 2.6's behaviour to delete timers rather than
seting their expriy to 0 in ip_vs_conn_expire_now().
And accordingly, don't reset timers in ip_vs_conn_expire(),
as the old ip_vs_conn_expire_now() behaviour was the only reason this was
done.
It turns out that the current timer reset behaviour in
ip_vs_conn_expire() causes the timeout of persistance templates to be
changed from their user-configured timeout in the situation where they
timeout before their controled connections. This can happen if the user
configures the persistane timeout to less than IP_VS_TCP_S_FIN_WAIT (2
minutes). And although such small persistance timeouts are of
questionable value, its still an unexpected, weird behaviour, without
any benifits.
See:
http://archive.linuxvirtualserver.org/html/lvs-users/2005-11/msg00096.html
Signed-Off-By: Horms <horms@xxxxxxxxxxxx>
diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
index 015c819..2f92d3f 100644
--- a/net/ipv4/ipvs/ip_vs_conn.c
+++ b/net/ipv4/ipvs/ip_vs_conn.c
@@ -1221,11 +1221,6 @@ static void ip_vs_conn_expire(unsigned l
{
struct ip_vs_conn *cp = (struct ip_vs_conn *)data;
- if (cp->timeout_table)
- cp->timeout = cp->timeout_table->timeout[IP_VS_S_TIME_WAIT];
- else
- cp->timeout = vs_timeout_table.timeout[IP_VS_S_TIME_WAIT];
-
/*
* hey, I'm using it
*/
@@ -1280,8 +1275,8 @@ static void ip_vs_conn_expire(unsigned l
void ip_vs_conn_expire_now(struct ip_vs_conn *cp)
{
- cp->timeout = 0;
- mod_timer(&cp->timer, jiffies);
+ if (del_timer(&cp->timer))
+ mod_timer(&cp->timer, jiffies);
}
/*
|
