|
On Thu, Jan 20, 2005 at 09:52:27PM +0100, Kees Hoekzema wrote:
> Hello list,
>
> Seems my debugging was not totally correct; it is not the
> IP_VS_DEST_F_OVERLOAD that causes the problem, but the check
> 'atomic_read(&dest->weight) >= mark->cw'.
>
> So I went on debugging, it seems that the current weight isn't altered when
> a server is updated, so that if the servers drop quite heavily in weight
> (due to a ddos or whatever) than you can run the risk of a connection
> refused because no server is available because the new weights are much
> lower than the old current weight, especially if you lower them drasticly.
>
> I've added 'mark->cw = 0;' to ip_vs_wrr_update_svc(..) to prevent a
> connection refused if you happen to like changing the weights a lot ;).
>
> I'm not entirely sure if this is going to affect the services, but at least
> it wont prevent any clients from connecting ;)
>
> The 'patch' (against a 2.6.10 vanilla kernel):
>
> diff -Naur linux-vanilla-2.6.10/net/ipv4/ipvs/ip_vs_wrr.c
> linux-2.6.10/net/ipv4/ipvs/ip_vs_wrr.c
> --- linux-vanilla-2.6.10/net/ipv4/ipvs/ip_vs_wrr.c 2004-12-24
> 22:33:49.000000000 +0100
> +++ linux-2.6.10/net/ipv4/ipvs/ip_vs_wrr.c 2005-01-20
> 21:43:36.000000000 +0100
> @@ -124,6 +124,7 @@
> struct ip_vs_wrr_mark *mark = svc->sched_data;
>
> mark->cl = &svc->destinations;
> + mark->cw = 0;
> mark->mw = ip_vs_wrr_max_weight(svc);
> mark->di = ip_vs_wrr_gcd_weight(svc);
> return 0;
Hi,
sorry for being slow here. Yes that does seem to be a bug. Yes, I think
your fix is correct. Especiall when you compare what you now have in
ip_vs_wrr_update_svc as opposed to what is alredy in ip_vs_wrr_init_svc.
I will post a patch that tires to merge that shortly - actually I have
the patch, but I am waiting for it to build and want to check other
schedulers too.
--
Horms
|
