[pull] master from haproxy:master#392
Merged
pull[bot] merged 7 commits intoerickirt:masterfrom Oct 24, 2025
Merged
Conversation
…ew API A first attempt to fix this issue was already pushed (54b7539 "BUG/MEDIUM: apppet: Improve spinning loop detection with the new API"). But it not was fully accurrate. Indeed, we must check if something was received or sent by the applet before incrementing the call rate. But we must also take care the applet is allowed to receive or send data. That is what is performed in this patch. This patch must be backported as far as 3.0 with the patch above.
This reverts commit 466a603. Due to the last 2 commits, this macro is now unused, and will probably never be used, so let's get rid of that for now.
…nsistency (2nd attempt) This is a second attempt at fixing issues on 32bits systems which would trigger the following BUG_ON() statement: FATAL: bug condition "sizeof(struct shm_stats_file_object) != 544" matched at src/stats-file.c:825 shm_stats_file_object struct size changed, is is part of the exported API: ensure all precautions were taken (ie: shm_stats_file version change) before adjusting this This is a drop-in replacement for d30b88a + 4693ee0, as suggested by Willy. Indeed, on supported platforms unsigned int can be assumed to be 4 bytes long, and long can be assumed to be 8 bytes long. As such, the previous attempt was overkill and added unecessary maintenance complexity which could result in bugs if not used properly. Moreover, it would only partially solve the issue, since on little endian vs big endian architectures, the provisioned memory areas (originating from the same shm stats file) could be read differently by the host. Instead we fix the aligments issues, and this alone helps to ensure struct memory consistency on 64 vs 32bits platforms. It was tested on both i386 and i586. last_change and last_sess counters are now stored as unsigned int, as it helped to fix the alignment issues and they were found to be used as 32bits integers anyway. Thanks to Willy for problem analysis and the patch proposal. No backport needed.
This is one of the rare pleasant surprises of fixing an almost 16-years old bug that remained unnoticed since the feature was implemented. In 1.4-dev7, commit 3bd697e ("[MEDIUM] Add stick table (persistence) management functions and types") introduced stick-tables with multiple key types, including strings, IP addresses and integers. Entries are coded in binary and their binary representation is indexed. A special case was made for strings in order to index them as zero-terminated strings. However, there's one subtlety. While strings indeed have a zero appended, they're still indexed using ebmb_insert(), which means that all the bytes till the configured size are indexed as well. And while these bytes generally come from a temporary storage that often contains zeroes, or that is longer than the configured string length and will result in truncation, it's not always the case and certain traffic patterns with certain configurations manage to occasionally present unpadded strings resulting in apparent duplicate keys appearing in the dump, as shown in GH issue #3161. It seems to be essentially reproducible at boot, and not to be particularly affected by mixed patterns. These keys are in fact not exact duplicates in memory, but everywhere they're used (including during synchronization), they are equal. What's interesting is that when this happens, one key can be presented to a peer with its own data and will be indexed as the only one, possibly replacing contents from the previous key, which might replace them again later once updated in turn. This is visible in the dump of the issue above, where key "localhost:8001" was split into two entries, one with a request count of one and the other with a request count of 499999, and indeed, all peers see only that last value, which overwrote the first one. This fix must be backported to all stable branches. Special kudos to Mark Wort for undelining that one.
The USE_KTLS test is currently being done outside of the USE_OPENSSL guard so disabling USE_OPENSSL still results in build failures on libcs built with support for kernels before 4.17, because we enable KTLS by default on linux. Let's move the KTLS block inside the USE_OPENSSL guard instead. No backport is needed since KTLS is only in 3.3.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )