[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <84ae20740711191625x399a3099ma29de2ee7933281e@mail.gmail.com>
Date: Mon, 19 Nov 2007 16:25:16 -0800
From: "Sam Jansen" <sjansen@...gle.com>
To: netdev@...r.kernel.org
Subject: Problem with sysctl_tcp_congestion_control function
sysctl_tcp_congestion_control seems to have a bug that prevents it from
actually calling the tcp_set_default_congestion_control function. This is not
so apparent because it does not return an error and generally the /proc
interface is used to configure the default TCP congestion control algorithm.
This is present in 2.6.18 onwards and probably earlier, though I have not
inspected 2.6.15--2.6.17.
sysctl_tcp_congestion_control calls sysctl_string and expects a successful
return code of 0. In such a case it actually sets the congestion control
algorithm with tcp_set_default_congestion_control. Otherwise, it returns the
value returned by sysctl_string. This was correct in 2.6.14, as sysctl_string
returned 0 on success. However, sysctl_string was updated to return 1 on
success around about 2.6.15 and sysctl_tcp_congestion_control was not updated.
Even though sysctl_tcp_congestion_control returns 1, do_sysctl_strategy
converts this return code to '0', so the caller never notices the error.
A sample program that shows this behaviour is attached. It is hardcoded to set
the congestion control algorithm to reno. Running it multiple times shows that
it succeeds, yet does not modify the default TCP congestion control algorithm.
e.g.,
$ make sysctl
$ sudo /tmp/sysctl; sudo /tmp/sysctl
old value='bic', new value should be='reno'
old value='bic', new value should be='reno'
A simple patch is also attached that modifies the if statement in
sysctl_tcp_congestion_control.
View attachment "sysctl.c" of type "text/x-csrc" (842 bytes)
View attachment "tcp_congestion_control.patch" of type "text/x-patch" (432 bytes)
Powered by blists - more mailing lists