From: Thomas Heil Date: Thu, 5 Sep 2013 22:42:31 +0000 (+0000) Subject: package: haproxy - add backported patches from 1.5dev X-Git-Url: http://git.cdn.openwrt.org/?a=commitdiff_plain;h=17a0cdfdd55bf484f948ed51b9b5adf758d2f154;p=openwrt%2Fsvn-archive%2Fpackages.git package: haproxy - add backported patches from 1.5dev SVN-Revision: 37909 --- diff --git a/net/haproxy/Makefile b/net/haproxy/Makefile index 85c655568..3fea8b4f8 100644 --- a/net/haproxy/Makefile +++ b/net/haproxy/Makefile @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=haproxy PKG_VERSION:=1.4.24 -PKG_RELEASE:=02 +PKG_RELEASE:=09 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://haproxy.1wt.eu/download/1.4/src diff --git a/net/haproxy/patches/0003-MEDIUM-session-disable-lingering-on-the-server-when-.patch b/net/haproxy/patches/0003-MEDIUM-session-disable-lingering-on-the-server-when-.patch new file mode 100644 index 000000000..56bdbe7c9 --- /dev/null +++ b/net/haproxy/patches/0003-MEDIUM-session-disable-lingering-on-the-server-when-.patch @@ -0,0 +1,36 @@ +From d45840bd28f5cf604d320ab9ff308ba7ba8c0b28 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Fri, 21 Jun 2013 08:20:19 +0200 +Subject: [PATCH 3/9] MEDIUM: session: disable lingering on the server when the + client aborts + +When abortonclose is used and an error is detected on the client side, +better force an RST to the server. That way we propagate to the server +the same vision we got from the client, and we ensure that we won't keep +TIME_WAITs. + +(cherry picked from commit 8615c2af67dc2be07bdb246ed13130fe7d32e3d1) +--- + src/session.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/src/session.c b/src/session.c +index 21ecb9f..9ed932c 100644 +--- a/src/session.c ++++ b/src/session.c +@@ -1370,8 +1370,11 @@ resync_stream_interface: + buffer_shutw_now(s->req); + + /* shutdown(write) pending */ +- if (unlikely((s->req->flags & (BF_SHUTW|BF_SHUTW_NOW|BF_OUT_EMPTY)) == (BF_SHUTW_NOW|BF_OUT_EMPTY))) ++ if (unlikely((s->req->flags & (BF_SHUTW|BF_SHUTW_NOW|BF_OUT_EMPTY)) == (BF_SHUTW_NOW|BF_OUT_EMPTY))) { ++ if (s->req->flags & BF_READ_ERROR) ++ s->req->cons->flags |= SI_FL_NOLINGER; + s->req->cons->shutw(s->req->cons); ++ } + + /* shutdown(write) done on server side, we must stop the client too */ + if (unlikely((s->req->flags & (BF_SHUTW|BF_SHUTR|BF_SHUTR_NOW)) == BF_SHUTW && +-- +1.8.1.5 + diff --git a/net/haproxy/patches/0004-BUG-MINOR-deinit-free-fdinfo-while-doing-cleanup.patch b/net/haproxy/patches/0004-BUG-MINOR-deinit-free-fdinfo-while-doing-cleanup.patch new file mode 100644 index 000000000..b153b32a0 --- /dev/null +++ b/net/haproxy/patches/0004-BUG-MINOR-deinit-free-fdinfo-while-doing-cleanup.patch @@ -0,0 +1,29 @@ +From 25d0a14ada411dc73b55b55d5b27599ccd2fa4a2 Mon Sep 17 00:00:00 2001 +From: Godbach +Date: Wed, 26 Jun 2013 16:49:51 +0800 +Subject: [PATCH 4/9] BUG/MINOR: deinit: free fdinfo while doing cleanup + +Both fdinfo and fdtab are allocated memory in init() while haproxy is starting, +but only fdtab is freed in deinit(), fdinfo should also be freed. + +Signed-off-by: Godbach +(cherry picked from commit 4cc1b0d4ef283b5ace5249483ec7eb3b1fc5d193) +--- + src/haproxy.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/haproxy.c b/src/haproxy.c +index 7a09e3f..c163743 100644 +--- a/src/haproxy.c ++++ b/src/haproxy.c +@@ -941,6 +941,7 @@ void deinit(void) + free(global.pidfile); global.pidfile = NULL; + free(global.node); global.node = NULL; + free(global.desc); global.desc = NULL; ++ free(fdinfo); fdinfo = NULL; + free(fdtab); fdtab = NULL; + free(oldpids); oldpids = NULL; + +-- +1.8.1.5 + diff --git a/net/haproxy/patches/0005-BUG-MEDIUM-server-set-the-macro-for-server-s-max-wei.patch b/net/haproxy/patches/0005-BUG-MEDIUM-server-set-the-macro-for-server-s-max-wei.patch new file mode 100644 index 000000000..4c7536663 --- /dev/null +++ b/net/haproxy/patches/0005-BUG-MEDIUM-server-set-the-macro-for-server-s-max-wei.patch @@ -0,0 +1,110 @@ +From ee591233efd57d625fea9057a975281fb8f4d358 Mon Sep 17 00:00:00 2001 +From: Godbach +Date: Mon, 22 Jul 2013 07:44:53 +0800 +Subject: [PATCH 5/9] BUG/MEDIUM: server: set the macro for server's max weight + SRV_UWGHT_MAX to SRV_UWGHT_RANGE + +The max weight of server is 256 now, but SRV_UWGHT_MAX is still 255. As a result, +FWRR will not work well when server's weight is 256. The description is as below: + +There are some macros related to server's weight in include/types/server.h: + #define SRV_UWGHT_RANGE 256 + #define SRV_UWGHT_MAX (SRV_UWGHT_RANGE - 1) + #define SRV_EWGHT_MAX (SRV_UWGHT_MAX * BE_WEIGHT_SCALE) + +Since weight of server can be reach to 256 and BE_WEIGHT_SCALE equals to 16, +the max eweight of server should be 256*16 = 4096, it will exceed SRV_EWGHT_MAX +which equals to SRV_UWGHT_MAX*BE_WEIGHT_SCALE = 255*16 = 4080. When a server +with weight 256 is insterted into FWRR tree during initialization, the key value +of this server should be SRV_EWGHT_MAX - s->eweight = 4080 - 4096 = -16 which +is closed to UINT_MAX in unsigned type, so the server with highest weight will +be not elected as the first server to process request. + +In addition, it is a better choice to compare with SRV_UWGHT_MAX than a magic +number 256 while doing check for the weight. The max number of servers for +round-robin algorithm is also updated. + +Signed-off-by: Godbach +(cherry picked from commit a34bdc0ea402ea5be1e9d7f80eaddec772b94393) +--- + doc/configuration.txt | 2 +- + include/types/backend.h | 4 ++-- + include/types/server.h | 2 +- + src/cfgparse.c | 6 +++--- + src/lb_fwrr.c | 2 +- + 5 files changed, 8 insertions(+), 8 deletions(-) + +diff --git a/doc/configuration.txt b/doc/configuration.txt +index 6e0add7..a008cd7 100644 +--- a/doc/configuration.txt ++++ b/doc/configuration.txt +@@ -1141,7 +1141,7 @@ balance url_param [check_post []] + processing time remains equally distributed. This algorithm + is dynamic, which means that server weights may be adjusted + on the fly for slow starts for instance. It is limited by +- design to 4128 active servers per backend. Note that in some ++ design to 4095 active servers per backend. Note that in some + large farms, when a server becomes up after having been down + for a very short time, it may sometimes take a few hundreds + requests for it to be re-integrated into the farm and start +diff --git a/include/types/backend.h b/include/types/backend.h +index dc4786e..1067125 100644 +--- a/include/types/backend.h ++++ b/include/types/backend.h +@@ -102,8 +102,8 @@ + * weight modulation even with small weights (eg: 1). It should not be too high + * though because it limits the number of servers in FWRR mode in order to + * prevent any integer overflow. The max number of servers per backend is +- * limited to about 2^32/255^2/scale ~= 66051/scale. A scale of 16 looks like +- * a good value, as it allows more than 4000 servers per backend while leaving ++ * limited to about (2^32-1)/256^2/scale ~= 65535.9999/scale. A scale of 16 ++ * looks like a good value, as it allows 4095 servers per backend while leaving + * modulation steps of about 6% for servers with the lowest weight (1). + */ + #define BE_WEIGHT_SCALE 16 +diff --git a/include/types/server.h b/include/types/server.h +index 14e4d1f..9fbd290 100644 +--- a/include/types/server.h ++++ b/include/types/server.h +@@ -69,7 +69,7 @@ + + /* various constants */ + #define SRV_UWGHT_RANGE 256 +-#define SRV_UWGHT_MAX (SRV_UWGHT_RANGE - 1) ++#define SRV_UWGHT_MAX (SRV_UWGHT_RANGE) + #define SRV_EWGHT_RANGE (SRV_UWGHT_RANGE * BE_WEIGHT_SCALE) + #define SRV_EWGHT_MAX (SRV_UWGHT_MAX * BE_WEIGHT_SCALE) + +diff --git a/src/cfgparse.c b/src/cfgparse.c +index 345b415..7d349b3 100644 +--- a/src/cfgparse.c ++++ b/src/cfgparse.c +@@ -3639,9 +3639,9 @@ stats_error_parsing: + else if (!strcmp(args[cur_arg], "weight")) { + int w; + w = atol(args[cur_arg + 1]); +- if (w < 0 || w > 256) { +- Alert("parsing [%s:%d] : weight of server %s is not within 0 and 256 (%d).\n", +- file, linenum, newsrv->id, w); ++ if (w < 0 || w > SRV_UWGHT_MAX) { ++ Alert("parsing [%s:%d] : weight of server %s is not within 0 and %d (%d).\n", ++ file, linenum, newsrv->id, SRV_UWGHT_MAX, w); + err_code |= ERR_ALERT | ERR_FATAL; + goto out; + } +diff --git a/src/lb_fwrr.c b/src/lb_fwrr.c +index d92b6eb..7f5c8a9 100644 +--- a/src/lb_fwrr.c ++++ b/src/lb_fwrr.c +@@ -343,7 +343,7 @@ static void fwrr_queue_srv(struct server *s) + * lower the scale, the rougher the weights modulation, and the + * higher the scale, the lower the number of servers without + * overflow. With this formula, the result is always positive, +- * so we can use eb3é_insert(). ++ * so we can use eb32_insert(). + */ + s->lb_node.key = SRV_UWGHT_RANGE * s->npos + + (unsigned)(SRV_EWGHT_MAX + s->rweight - s->eweight) / BE_WEIGHT_SCALE; +-- +1.8.1.5 + diff --git a/net/haproxy/patches/0006-BUG-MINOR-use-the-same-check-condition-for-server-as.patch b/net/haproxy/patches/0006-BUG-MINOR-use-the-same-check-condition-for-server-as.patch new file mode 100644 index 000000000..00e058e7e --- /dev/null +++ b/net/haproxy/patches/0006-BUG-MINOR-use-the-same-check-condition-for-server-as.patch @@ -0,0 +1,41 @@ +From 3bd693057420af0cd04132fdfb7c59e56aa90421 Mon Sep 17 00:00:00 2001 +From: Godbach +Date: Wed, 7 Aug 2013 09:48:23 +0800 +Subject: [PATCH 6/9] BUG/MINOR: use the same check condition for server as + other algorithms + +Such load balance algorithms as roundrobin, leastconn and first will check the +server after being selected with the following condition: + if (!s->maxconn || (!s->nbpend && s->served < srv_dynamic_maxconn(s))) + +But static-rr uses the different one in map_get_server_rr() as below: + if (!srv->maxconn || srv->cur_sess < srv_dynamic_maxconn(srv)) +After viewing this difference, it is a better choice for static-rr to use the +same check condition as other algorithms. + +This change will only affect static-rr. Though all hash algorithms with type +map-based will use the same server map as static-rr, they call another function +map_get_server_hash() to get server. + +Signed-off-by: Godbach +(cherry picked from commit 8f9fd2f0a0893761afeb6800c7b62a51d782af0e) +--- + src/lb_map.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/lb_map.c b/src/lb_map.c +index 49805ad..9858249 100644 +--- a/src/lb_map.c ++++ b/src/lb_map.c +@@ -229,7 +229,7 @@ struct server *map_get_server_rr(struct proxy *px, struct server *srvtoavoid) + avoididx = 0; /* shut a gcc warning */ + do { + srv = px->lbprm.map.srv[newidx++]; +- if (!srv->maxconn || srv->cur_sess < srv_dynamic_maxconn(srv)) { ++ if (!srv->maxconn || (!srv->nbpend && srv->served < srv_dynamic_maxconn(srv))) { + /* make sure it is not the server we are try to exclude... */ + if (srv != srvtoavoid) { + px->lbprm.map.rr_idx = newidx; +-- +1.8.1.5 + diff --git a/net/haproxy/patches/0007-MINOR-config-warn-when-a-server-with-no-specific-por.patch b/net/haproxy/patches/0007-MINOR-config-warn-when-a-server-with-no-specific-por.patch new file mode 100644 index 000000000..194da64e8 --- /dev/null +++ b/net/haproxy/patches/0007-MINOR-config-warn-when-a-server-with-no-specific-por.patch @@ -0,0 +1,36 @@ +From 8c1b1be9e4f11a8474f64dcb85d507a57b6cfe9f Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Tue, 13 Aug 2013 17:19:08 +0200 +Subject: [PATCH 7/9] MINOR: config: warn when a server with no specific port + uses rdp-cookie + +Mathew Levett reported an issue which is a bit nasty and hard to track +down. RDP cookies contain both the IP and the port, and haproxy matches +them exactly. So if a server has no port specified (or a remapped port), +it will never match a port specified in a cookie. Better warn the user +when this is detected. +(cherry picked from commit 82ffa39bfd34e5680cb65cc0b7ef625c0a274856) +--- + src/cfgparse.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/src/cfgparse.c b/src/cfgparse.c +index 7d349b3..cecec03 100644 +--- a/src/cfgparse.c ++++ b/src/cfgparse.c +@@ -5638,6 +5638,12 @@ out_uri_auth_compat: + err_code |= ERR_WARN; + } + ++ if ((newsrv->state & SRV_MAPPORTS) && (curproxy->options2 & PR_O2_RDPC_PRST)) { ++ Warning("config : %s '%s' : RDP cookie persistence will not work for server '%s' because it lacks an explicit port number.\n", ++ proxy_type_str(curproxy), curproxy->id, newsrv->id); ++ err_code |= ERR_WARN; ++ } ++ + #if defined(CONFIG_HAP_CTTPROXY) || defined(CONFIG_HAP_LINUX_TPROXY) + if (curproxy->mode != PR_MODE_HTTP && newsrv->bind_hdr_occ) { + newsrv->bind_hdr_occ = 0; +-- +1.8.1.5 + diff --git a/net/haproxy/patches/0008-MEDIUM-increase-chunk-size-limit-to-2GB-1.patch b/net/haproxy/patches/0008-MEDIUM-increase-chunk-size-limit-to-2GB-1.patch new file mode 100644 index 000000000..794255e6c --- /dev/null +++ b/net/haproxy/patches/0008-MEDIUM-increase-chunk-size-limit-to-2GB-1.patch @@ -0,0 +1,31 @@ +From 92518a563b9c1f9117e1dec2cc2a8ae95b1643d6 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Fri, 24 Feb 2012 19:20:12 +0100 +Subject: [PATCH 8/9] MEDIUM: increase chunk-size limit to 2GB-1 + +Since commit 115acb97, chunk size was limited to 256MB. There is no reason for +such a limit and the comment on the code suggests a missing zero. However, +increasing the limit past 2 GB causes trouble due to some 32-bit subtracts +in various computations becoming negative (eg: buffer_max_len). So let's limit +the chunk size to 2 GB - 1 max. +(cherry picked from commit 431946e9617572d2813bd5a8f5a51ce36f841ea3) +--- + src/proto_http.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/proto_http.c b/src/proto_http.c +index 22a7737..7fd1fe6 100644 +--- a/src/proto_http.c ++++ b/src/proto_http.c +@@ -2112,7 +2112,7 @@ int http_parse_chunk_size(struct buffer *buf, struct http_msg *msg) + break; + if (++ptr >= end) + ptr = buf->data; +- if (chunk & 0xF000000) /* overflow will occur */ ++ if (chunk & 0xF8000000) /* integer overflow will occur if result >= 2GB */ + goto error; + chunk = (chunk << 4) + c; + } +-- +1.8.1.5 + diff --git a/net/haproxy/patches/0009-DOC-add-a-mention-about-the-limited-chunk-size.patch b/net/haproxy/patches/0009-DOC-add-a-mention-about-the-limited-chunk-size.patch new file mode 100644 index 000000000..d645e7b32 --- /dev/null +++ b/net/haproxy/patches/0009-DOC-add-a-mention-about-the-limited-chunk-size.patch @@ -0,0 +1,28 @@ +From fdeb2171b83ab4fd5db36f1c45d57e2100529076 Mon Sep 17 00:00:00 2001 +From: Willy Tarreau +Date: Sat, 31 Aug 2013 08:16:26 +0200 +Subject: [PATCH 9/9] DOC: add a mention about the limited chunk size + +We now indicate that PD flags can be returned for chunk sizes >= 2GB. +(cherry picked from commit f3a3e1389e40434da9e1fc295be6ff5a8037effb) +--- + doc/configuration.txt | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/doc/configuration.txt b/doc/configuration.txt +index a008cd7..56438dd 100644 +--- a/doc/configuration.txt ++++ b/doc/configuration.txt +@@ -8044,7 +8044,8 @@ easier finding and understanding. + PD The proxy blocked an incorrectly formatted chunked encoded message in + a request or a response, after the server has emitted its headers. In + most cases, this will indicate an invalid message from the server to +- the client. ++ the client. Haproxy supports chunk sizes of up to 2GB - 1 (2147483647 ++ bytes). Any larger size will be considered as an error. + + PH The proxy blocked the server's response, because it was invalid, + incomplete, dangerous (cache control), or matched a security filter. +-- +1.8.1.5 +