[lvs-users] LVS changes in Linux 2.6.32 and 2.6.33

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>, Joseph Mack NA3T <jmack@xxxxxxxx>
Subject: [lvs-users] LVS changes in Linux 2.6.32 and 2.6.33
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Thu, 25 Feb 2010 11:45:25 +1100

In an effort to keep people up to date about changes
to LVS I am trying to write a summary of changes each
time a new kernel is released.

Unfortunately I forgot to do this for the 2.6.32 release,
so this report covers changes included in both 2.6.32 and 2.6.33.

In 2.6.33 (released on the 24th February 2010):

* Bug-fix:
  - Zero usvc and udest.
    This fixes persistent fwmark services which were broken
    if configured using the NF interface which was introduced in 2.6.28-rc3
    and is the default with ivpsadm 1.25.

* Clean-ups:
  - Use bounds changing in ioctls
    This changes the style of code that handles configuration from user
    space in order to satisfy tools that check for possible overruns.
    LVS does not appear to have suffered any such overruns.
  - Use common implementation of greatest common divider (gcd).
    This changes portion of the sysctl (proc) and nefilter
    handling code, to use common kernel.

In 2.6.32 (released on the 2nd December 2009):

* Enhancement:
  - Synchronise connection close.
    This allows connection entries on the standby linux-director
    to be updated when a connection closes and thus expire earlier
    than they otherwise would have.

* Clean-up:
  - Use atomic operations atomically in sysctl hander.
    Some of the code that handles configuration of LVS was
    incorrect, but this does not seem to have manifested in any problems.


The following commands were used to generate data for this report:

$ git clone git://
$ cd linux-2.6
$ git log v2.6.32..v2.6.33 --grep=ipvs --no-merges

commit 04bcef2a83f40c6db24222b27a52892cba39dffb
Author: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Date:   Mon Jan 4 16:37:12 2010 +0100

    ipvs: Add boundary check on ioctl arguments
    The ipvs code has a nifty system for doing the size of ioctl command
    copies; it defines an array with values into which it indexes the cmd
    to find the right length.
    Unfortunately, the ipvs code forgot to check if the cmd was in the
    range that the array provides, allowing for an index outside of the
    array, which then gives a "garbage" result into the length, which
    then gets used for copying into a stack buffer.
    Fix this by adding sanity checks on these as well as the copy size.
    [ horms@xxxxxxxxxxxx: adjusted limit to IP_VS_SO_GET_MAX ]
    Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
    Acked-by: Julian Anastasov <ja@xxxxxx>
    Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
    Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>

commit ae24e578de02b87cce3dc59248c29b2ecb071e9e
Author: Florian Fainelli <florian@xxxxxxxxxxx>
Date:   Tue Dec 22 09:42:06 2009 +0100

    ipvs: ip_vs_wrr.c: use lib/gcd.c
    Remove the private version of the greatest common divider to use
    lib/gcd.c, the latter also implementing the a < b case.
    [akpm@xxxxxxxxxxxxxxxxxxxx: repair neighboring whitespace because the diff 
looked odd]
    Signed-off-by: Florian Fainelli <florian@xxxxxxxxxxx>
    Cc: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx>
    Cc: Takashi Iwai <tiwai@xxxxxxx>
    Acked-by: Simon Horman <horms@xxxxxxxxxxxx>
    Cc: Julius Volz <juliusv@xxxxxxxxxx>
    Cc: David S. Miller <davem@xxxxxxxxxxxxx>
    Cc: Patrick McHardy <kaber@xxxxxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>

commit 258c889362aa95d0ab534b38ce8c15d3009705b1
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date:   Tue Dec 15 17:01:25 2009 +0100

    ipvs: zero usvc and udest
    Make sure that any otherwise uninitialised fields of usvc are zero.
    This has been obvserved to cause a problem whereby the port of
    fwmark services may end up as a non-zero value which causes
    scheduling of a destination server to fail for persisitent services.
    As observed by Deon van der Merwe <dvdm@xxxxxxxxxxxx>.
    This fix suggested by Julian Anastasov <ja@xxxxxx>.
    For good measure also zero udest.
    Cc: Deon van der Merwe <dvdm@xxxxxxxxxxxx>
    Acked-by: Julian Anastasov <ja@xxxxxx>
    Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
    Cc: stable@xxxxxxxxxx
    Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>

commit 9abfe315de96aa5c9878b2f627542bc54901c6e9
Author: Xiaotian Feng <dfeng@xxxxxxxxxx>
Date:   Mon Dec 14 16:38:21 2009 +0100

    ipvs: fix synchronization on connection close
    commit 9d3a0de makes slaves expire as they would do on the master
    with much shorter timeouts. But it introduces another problem:
    When we close a connection, on master server the connection became
    CLOSE_WAIT/TIME_WAIT, it was synced to slaves, but if master is
    finished within it's timeouts (CLOSE), it will not be synced to
    slaves. Then slaves will be kept on CLOSE_WAIT/TIME_WAIT until
    timeout reaches. Thus we should also sync with CLOSE.
    Cc: Wensong Zhang <wensong@xxxxxxxxxxxx>
    Cc: Simon Horman <horms@xxxxxxxxxxxx>
    Cc: Julian Anastasov <ja@xxxxxx>
    Cc: David S. Miller <davem@xxxxxxxxxxxxx>
    Signed-off-by: Xiaotian Feng <dfeng@xxxxxxxxxx>
    Acked-by: Simon Horman <horms@xxxxxxxxxxxx>
    Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>

commit 1e66dafc75f40a08b2addb82779987b269b4ca23
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date:   Mon Aug 31 14:18:48 2009 +0200

    ipvs: Use atomic operations atomicly
    A pointed out by Shin Hong, IPVS doesn't always use atomic operations
    in an atomic manner. While this seems unlikely to be manifest in
    strange behaviour, it seems appropriate to clean this up.
    Cc: shin hong <hongshin@xxxxxxxxx>
    Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
    Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>

Please read the documentation before posting - it's available at: mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to

<Prev in Thread] Current Thread [Next in Thread>